Reprogramming Sugar

One of the core ideas of the OLPC was that the underlying programming be visible to kids.

"the View Source button allows one to look behind the activity, peeling away layers of abstraction in order to reveal the underlying codebase which makes it tick. This feature will integrate cleanly with the Develop activity, encouraging children to view, modify, and redistribute variations on the activities they use. Through collaboration and sharing, a garden of home grown activities will begin to develop on the laptops, created by the children themselves."

OLPC Human Interface Guidelines

Pressing function space is meant to show the code. I recently looked to see how many of a selection of activities supported view code


activity .........Shows source
write ..................no
calculate ............no
ruler ...................no
speak ..................no
turtleart .............no
chat .....................yes
pippy ...................yes
record .................no
etoys ...................no
browse ................does not reveal application code, saves the webpage, can paste to write to view html but not intuitive


Hopefully more activities will have this feature enabled.

I was inspired by Walter Bender's Patching Turtle Art to see how easy it was for casual programmers like myself to patch activities. With some help from Walter, I have documented the process at Modifying_Activities . I show there examples of hacking activities, I hope that it will give teachers and more importantly students the confidence to try.

I did not find it easy , you will see that my efforts are mainly about changing constants and variables, not changing program flow. Here are my thoughts on what was hard:

locating the source code for applications
finding suitable programming tools
lack of documentation
understanding Linux
understanding Python
library documentation
object oriented programming
undestanding how program code is integrated with Sugar
no high level programming tools

A lot of the problem is about encapsulation and high level tools. Back in DOS days, it was relatively easy for the casual programmer to create applications. Just type print("hello world") into the IDE, press build and you had made your first application. Then Windows and C++ arrived and hello world took pages of code, only for the professionals. Fortunately VB came along, and despite its shortcoming, hello world was possible again for the casual programmer.

We do not think about print() but it represents pages of assembly code which has been encapsulated into a single command. Likewise, VB encapsulated pages of window handles and messaging into the simple action of dragging a button onto a form.

This allows the learner to do solve different problems, ones that are more appropriate to their learning trajectory. There is a lot of value in allowing students to become good problem solvers and good self directed learners but this is unlikely to happen if some programming issues aren't solved and encapsulated for them.

The messy business of creating an application has to be encapsulated if students are going to create applications. This could be by providing a high level programming environment which automates the messy stuff. It could be through providing a template or blank application in the distribution and appropriate documentation.