Guido and Kirby Urner are two of the 20 or so participants currently taking part in the Shuttleworth Summit. To put it simply, the objective of that summit is to find a curriculum that will fit mathematics, where a child will have mathematical tools to solve problems, and to acquire their analytical skills, and while making efficient use of technological tools. During the discussion, it has been suggested that a possible way might be to start kids with Logo, then maybe move on to Squeak, then Python. I would argue that a programming environment like rur-ple might be more suitable and sufficient to replace both Logo and Squeak, while being used to introduce Python. Many of my thoughts on this have been influenced by a paper on mini-languages. (I encourage everyone to read this paper.) I should also acknowledge that the basic idea behind rur-ple is not my own, but rather Richard Pattis with his "Karel the Robot", which is mentioned in that paper.
I am going to present an admittedly one-sided view in order to invite some discussion. The reality is that Logo and Squeak have been used very successfully with learner of all ages - something I will conveniently ignore in my argumentation! Furthermore, because I want to use this post to try and provide some feedback to Kirby that he can perhaps use while he is at the summit, the depth of some of the arguments presented will definitely be less than satisfactory.
Let me jump straight into the discussion by first arguing Logo might be too complicated as a first step, for at least two reasons. In decreasing order of importance, they are: 1. Advanced geometry; 2. Too many (complicated) commands. Furthermore, I would argue that Logo is limited in its ability to introduce problems requiring analytical skills.
First, Logo (and similar turtle graphics environment) uses general two-dimensional motion. The mathematical concepts that are needed/introduced include length and angles (measured in degrees). While integer values are used, units of length are too small to be easily measurable on the screen. By contrast, rur-ple uses restricted two-dimensional motion, as combinations of either vertical or horizontal motions. The basic stepsize is easily measurable on the screen. While rur-ple is designed to introduced coordinates (which are, arguably, a fairly advanced mathematical concept), programs can be written without making any reference to this concept. Furthermore, even without writing an actual program, one can guide the robot, making it move and turn by using the keyboard; this can be useful in visually determining the order in which instructions must be written.
Note that, in a future version of rur-ple (after I complete version 1.0) will include a second environment which will be essentially a "turtle graphics" environment, like that of Logo.
Second, Logo generally include the following commands (written in non-abbreviated form): forward #, backward #, right #, left #, pen_up, pen_down, restart (cs), as well as a repeat instruction. Note that the symbol "#" refers to a numerical variable. By contrast, rur-ple's basic commands are: move(), turn_left(), pick_beeper(), put_beeper(), and turn_off(). Rur-ple also includes a repeat() instruction. One can easily make a correspondance between Logo and rur-ple's commands and see that Logo includes two extra commands (backward and right) that can be emulated by appropriate combinations of other commands. Granted, the previous argument is a bit weak... However, note that 4 of Logo's basic commands require the use of an additional numerical arguments. This may seem trivial ... but for an absolute beginner, such a combination, like "forward 5" is an advanced concept as compared with a simple instruction like move(). While it is currently not designed this way, rur-ple could (and probably should) be easily modified so that the basic instruction move() could take an optional argument, like move(5), which would more closely match Logo's syntax. This is most likely how the future "turtle" environment for rur-ple will be designed.
Another conceptual hurdle present with Logo is the concept of "pen_up" and "pen_down". Again, for the readers of this blog, it probably seems very simple. However, I understand that this is something that has to be explained to learners (especially the younger ones), as it does not have an immediate analogy in their experience. I would argue that a more natural set of commands would be something like "start_drawing()" and "stop_drawing()". This could then later be expanded to something like "start_drawing(color=red)" and "start_drawing(color=red, thickness=2)". Another future expansion of rur-ple would be in a third environment, this time a 3-dimensional one (perhaps using Vpython).
I have mentioned that Logo is perhaps too limited in its ability to introduce problems requiring analytical skills. This is because Logo's traditional environment is an empty one. By contrast, rur-ple introduce a world in which obstacles (walls) can be present. One can then ask the user to solve various programs, from a simple "climbing a step" to finding a way out of a maze. This is done by introducing, one keyword at a time, Python's syntax. In fact, because the full power of Python is available, one can even easily use rur-ple to program a visual solution to the Tower of Hanoi problem!
This brings me to my final, and perhaps most important point. If one is to design a curriculum making use of technological tools to introduce mathematical and analytical skills, the focus should be on coming up with a coherent and progressive set of problems to be given to the students. The main idea should be to use the technological tools to solve the problems and learn about them, rather than using the problems to learn about the technological tools. I have to admit that rur-ple's lessons so far have been written in the second way: problems are introduced as a motivation to learn about computer programming (i.e. a technological tool). Perhaps the result of the Shuttleworth Summit will influence future lessons that will be included with rur-ple!