## Thursday, April 13, 2006

### Thoughts on the Shuttleworth Summit

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!

Anonymous said...

You are confusing Logo with turtle graphics. Turtle graphics is an application library, like, say, bignums or readline, that could be implemented in any language; I've seen turtle graphics implementations in Pascal, in Java, and in Smalltalk, for example.

Logo is a general-purpose programming language, a dialect of Lisp, different from most other dialects in its notation, its use of dynamic scope, and its careful attention to things like the exact text of error messages that aren't seen as important in most programming language designs.

Logo is not limited to graphics. See this page, for example, for a Pascal compiler written in Logo, a translator from regular expressions to finite state machines written in Logo, and a Logo version of Dan Bobrow's STUDENT program that solves algebra word problems.

In this post you jump back and forth, so it's hard to know whether you are mainly interested in choosing a programming language or in choosing a graphics library.

If you're interested in building a graphics library, e.g. because you want a bigger step size than one pixel, you can do that in Logo or any other language.

My own feeling is that you'd better have a *really* good reason for any proposal (yours or the one to which you're responding) that requires kids to learn more than one programming language. If you start in Logo, you should stick with Logo. If you want to use Python, but you think Python is too hard for little kids, you should ask yourself why *anyone* should have to use a too-hard language. If you *don't* think Python is too hard, use it from the beginning.

André Roberge said...

Indeed, you are right about me confusing Logo with turtle graphics. The discussions I had seen about using Logo as a teaching language were always in the context of turtle graphics.

I agree with your feelings about requiring kids to learn more than one programming language. And I don't think that Python is too hard to learn - but that a special environment (like turtle graphics or others) is required to get them to be interested in learning.

Anonymous said...

Python is not designed with beginners and children in mind. It is designed with long-time python users in mind only. What is 3/5 in python? Still 0 instead of 0.6. That is still not fixed by default and won't be for many more years. Research also showed Guido the problems with case-sensitivity and he agreed, but still no change to the language, nor is any planned. There are problems with the interactive interpreter but nothing was done about them. There has not been a single change made to the language in the past 15 years for the sake of beginners.
Visual Basic .NET (or mbas in mono) is a better choice for beginners and students than python (not to mention many times faster too since it is statically typed), but that is not saying much for either.
Python is NOT the right choice for education.

ToonTalk said...

I think there is great value in getting arithmetic right. It doesn't seem that either Python or Rur-ple does. As anonymous points out 3/5 shouldn't be 0. But I read in http://rur-ple.sourceforge.net/en/interpreter.htm that for Rur-ple:

7.3 % 3
1.2999999999999998

This last result is almost equal to 1.3 which is what we might have expected. The difference between 1.3 and 1.2999999999999998 is tiny ... and is caused by the way computers work with decimal fractions. I will explain how this comes about in a later lesson, when you know more about computer programming in general. Just note that, in practice, such small difference between the "exact" result and that given by Python should not matter.

---------

I disagree. I watched 12-years old explore the sum 1/2 + 1/4 + 1/8 + ... With 64-bit floating point approximations the sum becomes exactly 1.0 after about 55 iterations. While I'm not a Python programmer I understand it has an interface to the GNU Multiple Precision library that gives exact results for rational arithmetic. Why not use GMP?

Regarding the comments about kids understanding turtle geometry there has been nearly 40 years of research that shows they are fine with primitives like RIGHT and FORWARD. They can relate these commands to the way their bodies move in the world. No so for Cartesian coordinates.

Anonymous said...

I just found this article, so I don't know if anyone will see my comment...

I have taught basic logo to my 7yo, and he had no problem whatsoever understanding the basic commands, including pen-up and pen-down. It's a matter of telling the right story to get the concept across. The more vivid and creative the story, the better the child's understanding will be.

For example, there's a turtle, and you can tell it to move around. But you have to say how many steps it taks. It's a small turtle so it takes small steps. It's carrying a pen on its tail, so if you want it to draw a line, you have to tell it to put the pen down, and if you don't want to draw a line, you have to tell it to pick the pen up. When you want to turn you tell it how much. If you tell it 360 it will turn completely around. When it turns, it doesn't take any steps.

Then you demonstrate the concepts using the child's body, to make sure they understand what the commands mean, and then you have a brief practice - forward 10, forward 100, right 30, right 120. And give the child some free time.

That's the first lesson, and it took about an hour, and he really enjoyed it. No conceptual problems whatsoever. With a good vivid story, and demonstrations, I'm sure even a 5yo could understand this (maybe in 2 lessons, if the attention span isn't there).

And yes, Logo is a real, complete language. You can use coordinates if you want to, equations, or any other normal programming construct. Most teachers are not trained in the complete language, which is probably why people think it's a "toy" language. Plus, because it's based on LISP, recursion is easy to write, and text manipulation is accessible, too. These concepts are probably too advanced for your average 7yo, though!

-Corinna