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!

Lightning Compiler and RUR-PLE update

Both Lightning Compiler and RUR-PLE have been updated. Lightning Compiler (L.C.) has been refactored to make it easier to be incorporated inside another program (like RUR-PLE). I have added a sample application that shows how to import L.C., using a different layout for the buttons.

RUR-PLE has changed internally quite a bit. I now use ".po" files for string translations instead of the idiosyncratic approach I was using. Previously I added a python file for each language, containing a series of variable assignements like:
USER_STOP = "You stopped me!"
or
USER_STOP = "Vous m'avez arrêté!"
and I would invoke the strings through something like translation.USER_STOP.

Now, I use the same method as the gettext approach, i.e. something like
_("You stopped me!")
with the translations stored in .po files. More than 100 strings had to be changed in some 14 different files. Other "minor" changes had to be made as well... all very tedious, but it seems to be working ok. I wrote my own ".po" interpreter instead of compiling the files to ".mo" format and using gettext, as this seems to give me a better control over the encoding. A similar project (Guido van Robot) is using gettext and baffling encoding problems seem to be surfacing from time to time.

Three other significant changes were made to RUR-PLE:
1. a program can be run without being saved first. This was inspired from reading a post by Ted Leung
2. The dialog that appears after a successful run now disappears on its own after two seconds, instead of requiring the user to click a button. This was suggested in a comment left on this blog.
3. The embedded Python editor has been replaced by Lightning Compiler. I had to draw a whole bunch of images to use for the buttons; artwork is not exactly my forte, but it will have to do for now. A consequence of this new embedding has been a more consistent choice of color used in the embedded Python interpreter as well; the same basic coloring is used in the Python editor, the "robot editor" and the interpreter.

Unfortunately, I had to write new strings... which are neither translated in Spanish (help!) nor in French (my own laziness).

I am seriously considering embedding a turtle graphics page within the app; this would be using the same format as the robot world page: an editor on the left, a canvas on the right, and the program is executed by clicking on a button. However, this is a major change and will probably have to wait after version 1.0 has been released (RUR-PLE is at 0.9.7 currently!). I will soon have to learn about using setup.py, pyexe and inno installer, as version 1.0 probably should be a one click install affair. I might have to learn how to install it in a multi-user environment, with some common directory for the basic app and separate directories for each user-written programs... Suggestions as to the best way to do that are more than welcome!

Python wish: a new meaning for "import ... as ..."

For Python modules that are meant to be imported, I usually try to put the testing code inside the module using the standard

if __name__ == "__main__":

block of code.

However, if the module is also meant to possibly be used by itself, then this approach doesn't work and the testing code has to be put in a separate module. I wish it would be possible to write something like

if __name__ == ''SomeNameChosenForTestingPurpose":

inside this_module.py and that importing the module using

import this_module as SomeNameChosenForTestingPurpose

would result in the variable __name__ inside this_module.py being assigned to SomeNameChosenForTestingPurpose. This would allow the inclusion of the testing code to be always kept inside a given Python module. To build a test suite, one would only need to have a module that does a series of "import ... as ..." statements.

As it is, __name__ is either equal to "__main__" or the original name of the Python file (this_module in the example above).

===In short, I would like to be able to design Python modules in this way:

some clever Python code

if __name__ == "__main__":
    some clever Python code to be 
    executed when this module
    is called as the main program.

if __name__ == "SomeNameChosenForTestingPurpose":
   Some clever Python code
   to be executed when
   this module is imported as
   SomeNameChosenForTestingPurpose

Was rur-ple broken for Linux?

A while ago, I made some changes with the help of a MacOS user so that rur-ple could work properly with that platform. Since then, many people downloaded it; I assumed that everything was working properly as there was no bug report - until tonight. Under Windows, if you start rur-ple by double-clicking RUR_start.py (which is what I always do), everything is ok. However, if you start it [version 0.9.5] with "python RUR_start.py", nothing happens! I assume that this is the way it is invoked by Linux users too... I just made a small change which should make it work. The new version on sourceforge is 0.9.5a. If there are any users out there who could report if it works properly (and under what operating system), I would be most grateful!

Lightning 1.7 released

As requested by a user, I've added the possibility to pass arguments to a running script. The arguments are passed as a string (named _Args). The new version is available from the usual place.

One thing I have noticed is that scripts that contain encoding information give a run-time error. It is thus necessary to remove the encoding information (a line like # -*- encoding: latin-1 -*-) prior to running the script. If anyone knows of a different workaround, I'd appreciate hearing about it.

Lightning 1.6 released

Following some suggestions left by readers on the previous post of this blog, Lightning 1.6 has been released. The main visible change is the possibility to change the layout and have the output window "switched" from the bottom of the editor window to the right of the editor window (and vice versa).

The code has also been refactored so that it should be possible to customize various display options (default window sizes and fonts primarily) without having to understand how the rest of the program is structured.

Planned for the next release is the ability to simulate running a program with an argument list.

Lightning compiler: drag and drop option

A new version (1.5) of Lightning Compiler has been released. It is now possible to "drag" a file (icon) and "drop" it in the editor window. The text of the file will be automatically imported to the editor window. This option has been added following a suggestion. Since I believe that it fitted well with the philosophy of L.C. as a quick-and-painless testing tool for Python scripts, I decided to implement it (which was surprisingly easy, thanks to wxPython!)

Feel free to suggest other useful options. :-)