The role of shopping trolley-equipped virtual robots in programming pedagogy

Now there’s a conference paper title waiting to happen! :D

Seriously, though, I’m quite excited about a new approach I’ve been experimenting with in NoobLab. It stemmed from an idea I had while at the HEA STEM conference recently, that I tentatively named “braindead Logo”.

Most of you who have experience of teaching programming (or who were taught it back in the glorious days of Research Machines 380Zs in schools) will remember Logo – a basic language where you give instructions to a “turtle” (essentially a motorised pen) in order to draw things on paper. So

forward 50
right 90
forward 50
right 90
forward 50
right 90
forward 50

would draw a square.

This was a great pedagogic tool not only because it introduced programming in a visual, engaging way, but also because it established some of the key problem-solving skills of programming. Students would attempt to create increasingly complex shapes and patterns, and in doing so, begin “thinking like a programmer”, i.e. breaking the problem down into steps.

My thinking was that wanted to embed the acquisition of the “thinking like a programmer” skill at a deeper level, and I’d do that by crippling Logo by removing the ability to specify units – so you couldn’t do forward 50, only forward (which would move the turtle one step forward). To do anything interesting, you’d have to use some kind of iteration, a loop – hence “braindead Logo”. At the same time we could also stealthily sneak in some “real” code – for example, we’d we’d use C/Java style syntax for the for loop, so when students progressed much of it would seem familiar. I’d also further “break” Logo by making the turtle only turn one way (with apologies to Derek Zoolander) so that an early exercise would be for the student to consider how to get the turtle facing the other way.

Turns out that someone had already been thinking this way back in the Logo era itself! In 1981 Richard E. Pattis, a professor at Carnegie Mellon University published the book Karel the Robot: A Gentle Introduction to the Art of Programming. Essentially, this was braindead logo! The language was geared around moving a “robot” around a “set of streets”. You could instruct the robot to move, change direction, pick something up and so on, but the language had no ability to specify distance, and they’d even taken the Zoolander approach to turning!

The original Karel made use of an almost COBOL-esque, verbose language with code that looked like


but more recent efforts have modified the language to teach OO programming, and at Stanford we even have Karel the Robot Learns Java!

My effort involves a shopping-trolley equipped robot that I’ve called Carol (as a nod to the previous work):

There were some aspects to Karel that I thought were a little “off” or needlessly obscure – the concept of picking up things called “beepers”, for instance – so what I have is conceptually similar rather than simply creating an exact implementation of an existing Karel-based project within the NoobLab environment.

In these new NoobLab exercises, students move Carol around a grid and she can pick things up (numbers) to put in her trolley. To get her to do anything more than once, you either have to repeat yourself or wrap your commands in a loop. Carol has been made, by design, something of a temperamental sod. She is inclined to give up if the slightest thing goes wrong – so, for example, if you try to pick up an object when there is none in the current square, or if you try to walk her into a wall, she tells you she’s giving up and why – and then stops dead. The student might not realise it, but what they’ve just learned there is the fact that a program can throw an error!

We also sneak in other “real” things – for example, note how it’s move() rather than just move – so we establish that functions/methods always have brackets after them, although we don’t get drawn into that.

I find this sort of approach really exciting – I believe that many of the problems in programming pedagogy are to do with students being unable to visualise or put a problem into context. On a recent Java module, a student who was retaking said to me that their problem in their first attempt was not Java, but the fact that half of the things they were asked to program were incomprehensible to them! It turns out that many of the practical tasks set by the previous tutor were mathematical in nature. In my view this is poor pedagogy. An ex-mathematician might believe that writing a program to create a Fibonacci sequence is a simple, trivial demonstration of programming competence, but a student who has no idea what a Fibonacci sequence even is faces an immediate disadvantage. If they are struggling to comprehend a programming concept, forcing them to learn another new unrelated concept just to be able to understand the exercise parameters can be the straw that breaks the proverbial camel’s back. Carol, Karel and similar exercises in programming avoid this by making practical exercises comprehensible to all.