The importance of visual programming

Kudzu flower manipulated with NodeBox

Python has a well-earned reputation for being easy to use and to learn, at least for people who have learned programming in other languages first. Lately my kids have been very interested in programming, and I’ve found that Python doesn’t come as easily to 6-11 year olds as it does to adult programmers.

So I see two approaches to this problem, if it is a problem. One, let them use other languages than Python. Two, find (or make) ways for Python to be more approachable. Let’s look at both of these.

Scratch Screenshot


For languages other than Python, there are some really good choices. The best language for getting kids interested and up to speed quickly that I’ve found is Scratch, which is a visual, drag-and-drop programming language for games and animations based on Squeak Smalltalk. Scratch allows kids to program without worrying about the syntax, so they can drag blocks together, use the built-in drawing program to create sprites or import images from the library that comes with the environment. They can also share their creations on the web, projects get automatically converted to Java applets when shared on the Scratch website, and the kids can vote for and comment on each others projects.

Learn more about this project

Scratch is great for learning and for sharing. My seven-year-old can download someone else’s project and generally is able to read it to see what is going on, so it is good for building basic programming literacy. It also has some pretty severe limitations: no user-defined blocks, no return values, no file interaction (so no high scores), no network interaction, no dynamic object creation, the program cannot draw on sprites (only on the background), no string variables or any real string handling. It is a great environment for learning to think creatively within its constraints, but my kids also bump up against its limits pretty quickly.

One option that is often suggested as a step up from Scratch is GameMaker, which apparently is a very nice commercial system that lets kids build games. Besides being commercial, it is also Windows-only, which makes it a non-starter in my household. Scratch runs on both Windows and OS X, with a port to Linux being worked on, but as a Windows-free household, GameMaker is right out.

Quartz Composer Screenshot

Quartz Composer

Another interesting system we’ve been playing around with lately is Quartz Composer. This is a program that comes with Apple’s free Developer Tools. Rather than snap-together blocks, as in Scratch, it is a patch-based environment (there are many of these for working with audio): You drag patches onto a workspace, then wire them up by dragging from the output of one patch to the input of another. Different patches have different numbers of connectors and there are a wide variety of patches to choose from, along with template starter projects for screen savers, audio visualizers, and more. This is a popular tool with VJs, and there is a community around it for sharing custom patches and compositions. A composition can be saved and used in various Cocoa programs that take *.qtz files as plugins, such as the Screen Saver or iChat.

While my seven-year-old can create some effects by playing around with the patches and randomly wiring them up, the system as a whole has been too abstract for him and he doesn’t get it the way he gets Scratch. There is a steeper learning curve to literacy with Quartz Composer.

eToys Screenshot


One more tool we’ve begun to explore is Squeak/eToys. I have tried in the past to understand the Squeak environment, and to grasp eToys. I was amazed how impenetrable this system, ostensibly designed for children, was to me. A while back I read on Ted and Julie Leung’s respective blogs I read about Squeak: Learn Programming with Robots. This book finally gave me a good starting point for learning Squeak, and an introduction to eToys I could understand. Familiarity with Scratch helps too, since I think Scratch came about in part as a way to make eToys more accessible. So far, while I like the ideas behind Smalltalk, I haven’t been able to muster much enthusiasm for Squeak. It’s always been slow on the Mac (the Macs I have now are finally fast enough to make it bearable), and the UI for it is downright ugly.

I realize there are lots of other visual environments out there we could try. Alice and StarLogo are on our radar, for instance. But that is enough to give a sample of both what is available and the journey my kids and I have taken so far.


Turning now to Python. Python has some visual tools built in: Tkinter for building a GUI and the turtle library that is built on top of Tkinter. I actually built a turtle library on top of Tkinter once, not knowing that Python came with one. I added a few things: Turtles could follow mouse clicks, and they looked like turtles, not like triangles. There is also the rather more advanced xturtle library, which is quite cool (also built on top of Tkinter). Besides adding more direct manipulation to turtle drawing (point to move, drag to reposition, etc.) I wanted to have the turtles able to write out the resulting scripts, so kids could learn by modifying those starter scripts. Other projects came along though, and I still haven’t finished either my turtle program or my port of xturtle to run on top of PyObjC on the Mac.

Programming for Artists

Speaking of PyObjC, there have been several tools which take advantage of the powerful graphics capabilities of OS X, using the PyObjC bridge to access Cocoa classes and Quartz graphics from Python. The first of these (that I know of) was DrawBot, by Just van Rossum which is now at version 2.0. The 0.9 version of DrawBot was forked to add additional GUI capabilities, but was not differentiated well from the main DrawBot to avoid confusion. Another fork of DrawBot is NodeBox, which also continues on as a current project today and has gathered an ecosystem to it of artists, designers, and many powerful plugin extensions. All of the DrawBot family of tools are inspired by Processing, which is a similarly stripped-down language for graphics processing. While I use NodeBox extensively, and work with the kids with it (my 11-year-old created the logo for her weblog with it), Processing has its advantages too. NodeBox is focussed on creating art works in PDF or Quicktime movies and focuses on making these easy (including very easy to get started with animation). Processing is built on Java rather than Python, and you can embed the resulting tools as interactive art or games directly in a web page as applets. So while the core languages used by both are nearly identical, they diverge quickly based on their extensions or the desired end result. I recommend looking at the galleries for both NodeBox and Processing to get a feel for what they can do. The key goal of these projects is that they are written for artists, not for programmers.

Another tool which is inspired by DrawBot and Processing, but is a separate, cross-platform project, is Winston Wolff’s MakeBot. Besides being the only tool here which works across Windows and Macintosh, MakeBot has games as the end-goal, and is specifically designed with teaching kids in mind (Winston uses it for his Lunar Repair Yard course in NYC). Winston has also started the Command Blocks project to bring some of the drag-and-drop programming ideas from Scratch into Python (and which I’m hoping to contribute to as well).

Graphics for Physicists

The first tool on our tour which handles 3D is VPython (formerly Visual Python, but changed because there was already a Visual Python project, but it’s good to know the history because it still starts as “import visual”). Like the Processing-inspired tools, VPython is designed for non-programmers, although in this case it is designed for physics students to create simple simulations easily, although the possibilities for games and art projects still exist. I love the simple API of this library, if you want a sphere the code is “ball = sphere()” That gets you a grey unit sphere centered on 0,0,0. If you want it a different size, color, or position you can pass them as arguments to sphere or change the properties afterwards. If there isn’t a window yet, one will be created automatically, but of course you can create a window yourself (or more than one). To give a more concrete example, here is a complete, animated program from the VPython examples:

VPython Screenshot

from visual import *

floor = box(length=4, height=0.5, width=4,

ball = sphere(pos=(0,4,0),
ball.velocity = vector(0,-1,0)

dt = 0.01
while 1:
    ball.pos = ball.pos + ball.velocity*dt
    if ball.y < 1:
        ball.velocity.y = -ball.velocity.y
        ball.velocity.y = ball.velocity.y - 9.8*dt

One of the projects I would like to explore is using Python to generate/work with POV-Ray for more advanced 3D rendering than what I can get with VPython, but a good starting point is that there is an extension to VPython that can export its models to POV-Ray.

Taking the Red PIL

The Python Image Library (PIL) is more or less the standard tool for creating non-interactive graphics, but it has its place in interactive graphics as well. I often rely on it for importing and exporting images from PyGame, and it can be used off-line for creating or manipulation graphics to use in an animation or game. It is perhaps a measure of my geekiness that I often find it easier to write a program to create or manipulate some graphics than I do to figure out how to perform the same task in Photoshop or any of the other half-dozen or so graphics programs I have at hand. Lately NodeBox has been my tool of choice for these scripts, but I still use PIL a lot when I’m working in Linux.

Pygame Screenshot

The Once and Future PyGame

PyGame is a great success story for Python. There are real, polished games created with it, like SolarWolf and Pathological. It is also used for teaching (as in the LiveWires course), and in game creation contests such as Ludum Dare and PyWeek. My own experience with PyGame has been something of a love/hate relationship. On the love side, it is easy to set up, works virtually anywhere (on my tiny Nokia N800, for instance) and is quite good at moving pixels around. On the hate side, it is very low-level, and I either have to learn one (of several possible) libraries that add necessary abstractions for events, input, collisions, etc., or I have to roll my own. It feels like programming the Mac, back in the ’80s. Lately I have been trying to do some work with PyGame targetting the OLPC XO and the aforementioned N800, and have been hampered by the fact that many of the really cool extensions to PyGame rely on OpenGL, which neither of those devices have.

There are other cool Python libraries for graphics: Pyglet, PyOpenGL, PyGame. I’ve written stuff for the kids with PyGame, but I think it is still too much for them to manage themselves. And I’m not cruel enough to have thrown OpenGL (which includes Pyglet) at them yet. Let them think the world is kinder than that for awhile yet.

Overall there is a lot of promise in the world of graphics for Python. There is still plenty of work to be done, too. I guess I’d better get coding.


  1. rasmus said,

    February 23, 2008 at 3:29 pm

    If you are interested in another easy to use graphics library for python, I recommend my own, SUMMON

    Its designed for rapidly prototyping scientific 2D visualizations. You mention you found PyGame too low level (e.g. catching input events etc). SUMMON handles the underlying event loop for you, and lets you specify user interactions in a more declarative way (define areas of the screen to react to mouse-clicks called hotspots).

    SUMMON is similar to DrawBot, NodeBox, and Processing, except I use a scene graph representation, and I cater more to easing scientific visualization.

    I started this project three years ago when I found my self rewriting the same boiler plate code for many of my projects. SUMMON was my way of abstracting that stuff away into a library I can use in all my projects. I’m curious to hear feedback if you do try it out.

  2. Dave Briccetti said,

    March 6, 2008 at 12:17 am

    Hi Dethe. Thanks for this post. I taught Squeak for a couple years, then discovered Scratch. Now I’m teaching Alice as well:

    I’ve also taught Python and Pygame for a few years, but I’m thinking of switching to Ruby, especially if I can find some sort of easy to learn graphical/game toolkit for it.

  3. Dave Briccetti said,

    March 6, 2008 at 12:21 am

    Thanks for the informative post. I taught Squeak for a couple years, then switched to Scratch. Some of my students have outgrown Scratch–no subroutines is a major weakness–so I was thinking of showing them Squeak, but then discovered Alice.

    I’ve been teaching Python and Pygame but now I’m really interested in Ruby so I think I may teach that instead. I’d like to find an easy-to-use graphical/game library for it. Something about the difficulty of, say,

  4. Living Code » Blog Archive » Processing Critters said,

    March 19, 2008 at 9:22 pm

    [...] been playing around some with Processing, this is the result. As I mentioned in my earlier article, Processing and NodeBox are quite similar. Processing has some more interactivity (better keyboard [...]

  5. cefn said,

    July 3, 2009 at 8:29 am

    A recent project from BT – Rules – inspired by Scratch now has screencasts showing how to program a range of devices with a Scratch-like tile-based programming interface…

    Visit the Rules website at

    Given your interest in the area of accessible programming, it could be worth a look and welcome your feedback.

  6. TL said,

    September 15, 2009 at 10:43 pm

    Hi Dethe Elza,

    Good day.

    I am currently working on some small modification on SCRATCH using Squek VM.
    But I am facing some small technical problem which I could not change the name of the UI of SCRATCH. I am planning to change the name of the 8 buttons on the left hand upper corner. I am able to modify them all and save the user image file but then after I reopen it all the button refresh back to original name.

    Do you think you can help me?
    I had asked around in SCRATCH Forum but then no one actually answered me or else no one find out a way for to change that.

    Your kind reply is highly appreciate!

    Thank you so much.

  7. Dethe said,

    September 17, 2009 at 8:17 pm

    Hi Teresa,

    I wish I could be of more help, but my knowledge of Squeak is very limited. I think you need to be sure your changes are applied to the image that the Scratch app uses, but how you would go about doing that, I’m not sure. Rather than the Scratch forums, you might be better off getting help from the Squeak community:

    Good luck!

Post a Comment

You must bee logged in to post a comment.