At the main maths camp this year, we had five different topic areas that we structured the camp around. All of them used computers in a big way, except one: Programming. The justification for this was that we had really nice, user-friendly programs for illustrating ideas in statistics, geometry, and so on, but actually throwing the students into a programming environment would almost certainly be too overwhelming. A significant number of the students had never touched a computer before, and really taking them into a code environment seemed a bit of a stretch for people still figuring out the idea of a right-click.
That’s not to say that good computer tools don’t exist; just that we haven’t managed to review them yet. (MIT’s Scratch, for example, looks well worth checking out.) Furthermore, given the time-scale we were working on, I think there was a lot of value in separating the programming concepts from the physical object of the computer. This makes the concepts available in a larger context than the computer, which, as a maths camp, we were eager to do. The idea of setting some basic rules from which we can extrapolate is a basic idea of mathematics. Getting across the idea of the need for precision was also of key importance.
We decided to focus on some of the basic underlying ideas of programming. The concepts we identified as essential were:
- Exactly following a set of instructions,
- Using a limited set of instructions to carry out complex operations,
- Basic if/then statements, and
- Loops.
Over four talks, we mainly focused on the first three.
First Talk: We introduced the idea of following instructions exactly, even if the outcome isn’t what’s intended. We had four people playing ‘robots’ who performed exactly the tasks asked of them. In this case, pouring water from a bottle into a cup. When we say ‘pour,’ the robots pour, and when we say ‘stop,’ they stop. After some comedy involving some very wet floors, we got the basic idea across.
Second Talk: This was actually an activity session, which we’ve been calling the Robot Game. The essential idea was to put a grid on the floor; one person plays the part of a robot, trying to pick up an object (say, some keys) and put it in the same square as a target object (say, a metal cup). One square is designated as the starting square, from which the robot always begins, facing in a given direction. The instructions available are Go Forward, Turn Right, Pick Up, and Put Down. Picking Up applies to an object in the square in front of the robot; likewise, Put Down puts the object down int he square in front of the robot.
We then place some puzzles, and have the students figure out instructions to get the keys into the cup. We get one student to volunteer to play the robot for each puzzle; this gets across quite directly the idea of exactly following instructions! The students importantly write down the instruction sets, and then we execute them with the robot.
The first puzzle is very simple; move forward, pick up the keys, move forward a couple times, then place them in the cup. The second requires turning right to place the keys in the cup; at this point, they’ve used all of the available instructions.
The third puzzle requires turning left to place the keys in the cup. But, like Derek Zoolander, the robot doesn’t know how to turn left. (Three rights, of course, will do in a pinch.) And then we start putting in obstacles, requiring writing a long sequence of precise instructions to make it through the maze. This just reinforces the basic idea, and gets across the notion of higher precision.
In a way, this is very similar to the exercises we did when I worked with COSMOS in the robotics lab. There, we would set a number of basic tasks for the students, who would then program their Lego Mindstorms to navigate an obstacle course and so on. The tasks were a bit harder, since one had to contend with the inaccuracies in the sensors and motor systems; the grid for the Robot Game is pretty simple by comparison. The game is also similar to the beginning stages of learning the Logo programming language, which many, many kids have cut their programming teeth with over the years.
The Third Talk didn’t go quite as well, admittedly. For this, we introduced tic-tac-toe (which isn’t a well-known game amongst Kenyan students), and then discussed assembling move trees and using these to form a strategy to play the game. This ended up being rather too much for a one-hour period, as it turned out. We ran the session twice, once with students who hadn’t seen tic-tac-toe before, and once with students who had played tic-tac-toe in the morning session. With less immediately new information to soak up, the session went a bit better with the second group. The key idea I hoped to get across was efficient organization of information in order to organize thought. But it’s something that needs more than a one-hour session, I think, or perhaps a more straightforward way to get to the point.
The Fourth talk was run by Emily Hobbs and Jeff Goodman, and focused on creating a program to play Nim. As with the robot game, the students were given a limited syntax to work with: in this case some key-words like ‘if’ and ‘then’, along with things like ‘count the stack.’ This would probably work well directly after the robot game: it immediately builds on the notion of programming through limited instructions, and now uses words instead of pictographs, with a little bit of syntax. (Since ‘then if count’ doesn’t really make sense, for example.) By all accounts, this session went quite well!
In retrospect,we found this to be a very reasonable way to introduce the students to some of the basic concepts of computer programming. Along the way, they get the idea of following exact instruction sets: Through things like the robot game, really get inside the head of the computer, so to speak, and see why things sometimes behave as they were programmed to, rather than how we expect them to. We’ve recreated the robot game in a number of mini-maths camps since, and it’s been an extremely effective way to get the students involved.
Looking back over the full set of talks and activities, I’d say the place that most needed improvement were the data structure portion. It will be good to brainstorm some other activities to get across the idea of a data structure… One target that we didn’t get to so much was loops; it’s another area where it would be good to come up with some really good activities to get across the basic notion. Computation has a few different parts: following algorithms is one, manipulating and storing information is another, and communication is a third. We’ve done a decent job getting started on algorithms, and, on some level, it would make a lot of sense to wrap communication into the cryptography-oriented activities we devised.
Ok, probably enough for now!
Inventing Situations. 