Embedded in Academia

A Few Thoughts on Scratch

Over the last year or so my older son, who is about to turn eight, has spent maybe one morning a month creating a video game using Scratch. This doesn’t seem like a lot of time to spend learning to program, but I’ve been trying to avoid pushing. Our usual mode of operation is that he sits there at one computer while I work at another one; I’ll come over and answer questions or help out if he gets stuck, but he’s basically driving both the design and implementation.

The game is simple: you control an ant that is being chased by a bomb, which blows up the ant if it catches it. The ant cannot move through the walls of a simple maze, but the bomb can. Here the ant is being chased:

Here it got caught:

This morning I asked Jonas if his code used any variables and he asked: What’s a variable? So I explained it would be used to store the number of lives you had left or something like that, and he immediately wanted to give the player multiple lives. The mechanics of doing this was a bit beyond him—this was not only his first variable, but also his first inter-sprite messaging—so we sat down together and implemented it in around half an hour. Adding the reset-board and game-over logic were the most complicated tasks we’ve done so far.

I also tried to tell Jonas how creating a smart adversary is perhaps the hardest aspect of making a good computer game, and that nobody even knows how to make an enemy as smart as he is. Jonas replied that in that case it should be pretty easy to create an enemy as smart as his five years old brother. I think he was joking but it wasn’t totally clear.

Does Scratch have any drawbacks? Perhaps a few. I found the lack of procedural abstraction distracting; Scratch seems to encourage a significant level of code duplication that would grow onerous for any non-simple tasks. Jonas and I both found the concurrent-object execution model to be a bit confusing since it was often not clear where to put a particular piece of code. He ended up putting most of the game logic into the bomb that chases the player around the screen—this worked pretty well, but didn’t seem ideal. We ran into a few interface warts where, for example, a comparison widget seems to encourage you to type the name of a variable into one of its slots, but the resulting code doesn’t work—you rather must drag a widget corresponding to the variable into the comparison object.

Overall Scratch is really well done; I found the programming environment to be enjoyable and Jonas was able to pick up new constructs from the menus and figure them out on his own. The compile-to-Flash feature is totally great since you can execute people’s Scratch projects in the browser.

What next? I’m trying to choose between Racket and Python via Phil Guo’s online Python tutor.

regehr

,

13 responses to “A Few Thoughts on Scratch”

  1. I learned to program at an age comparable to your son’s. The computer must have arrived in my home about when I was 6 or 7. I would not be surprised if the first book I ever read was a programming book. Specifically, this one:

    http://www.zx81stuff.org.uk/zx81/books/z/ZX81ALaConqueteDesJeux.Front.jpg

    The ZX81 had 1KB or 16KB of memory in its most common configurations. There were a number of tricks to save memory. A literal constant took 5 bytes in memory (in floating-point format), but there was a pre-defined constant pi that took one byte. You could get other useful values from it. 0 was “not pi” (2 bytes), 1 was “sgn pi” (2 bytes), and so on.

    This was easy to understand for a 7-year-old, but a sentence in the introduction of the aforementioned had me stumped for years.

    It suggested saving bytes by computing the new coordinates of the spaceship like this:

    let x = x + inkey$=”8″ – inkey$=”5″

    (The “5” key sported a left arrow, the “8” key a right arrow.)

    I had neither used mathematical unknowns nor done any analytical geometry at the time, and there was absolutely no reason the location of the ship in my program would be in a variable named “x”. I probably consumed letters in alphabetical order as I needed them.

    So when I typed the magical line in my program, it did not work. I would erase the line and type it again, but to no avail. It never worked. Stupid book!

    It turned out later that in the magic line, the “x” represented the name one would be using for the ship’s location in one’s program. I was still young but older than your son when I had this particular epiphany. Don’t introduce him to meta-variables just yet.

  3. Hi Pascal, I learned a little later, at age 9 or 10, on a TI-99/4A. Nobody was available to help me so I just went through the BASIC manual and tutorial, which were actually pretty good.

    The main epiphany that I remember from that time period is when I figured out the relationship between hex digits and bits. This machine’s BASIC didn’t have real graphics but it was possible to make pretty decent pictures by programming customized characters, which were just 8×8 arrays of pixels, specified using 16 hex digits.

    http://www.classiccmp.org/dunfield/ti/beginbas.pdf
    http://www.classiccmp.org/dunfield/ti/usrguide.pdf

  5. Python has a lot of libraries, but there isn’t a comprehensive environment where everything that a game needs is available. Racket seems better for this because you get an editor, graphics libraries and a good general purpose language all in one package. Also you might consider one of the many Logo variants.

  6. My sons (6 and 9) and I have messed around with Scratch, Processing and Python.

    Python is nice but as the previous comment says, there’s not much in the way of a comprehensive easy-to-use library for drawing stuff. I’ve used Pygame myself but it’s not something for the <10 set.

    Scratch I found simply too weird.

    "Processing" is our current favorite. It's a bit closer to a consensus reality programming language and less confusing than Scratch (I found the level of concurrency in Scratch pretty confusing given the target audience).

  7. Thanks Geoff and Anon. I’ll definitely try Processing– hadn’t even heard of it before.

    Another one that looks really fun is Inform 7, since Jonas is already kind of hooked on text adventures.

  8. Heh, I learnt to program on a TI99/4a too; can still remember the frustration of accidentally resetting it by typing fn-= rather than shift-= halfway through a session… Completely bonkers hardware design, too, with only 256 bytes of RAM directly attached to the CPU. I started out (like I guess many others of that generation) by just typing in other peoples’ programs, and progressing to trying to “port” programs from one BASIC dialect to another. (The idea of learning by reading rather than writing code also appears at a rather more advanced level as John Lions’ motivation for writing his commentary on 6th Ed Unix.)

  9. I’ve never looked into Scratch, but from your description it reminds me a lot of ZZT.
    http://en.wikipedia.org/wiki/ZZT-oop
    ZZT allowed you to create on-screen actors with various behaviors (“chase the player”, “move north”, “if you hit a wall goto label X”, “spawn a new monster of type M to your left”,…) and send messages from one actor to another. All actors run concurrently (which makes exact timing pretty tricky). It has no variables, just Boolean flags.

    Inform 7 sounds like a great idea if Jonas is hooked on text adventures, but it’s not going to make it any easier to explain variables to him. 🙂 Inform 7’s syntax for doing “real programming”-style math is about on the level of COBOL’s.

    I still recommend Basic or Pascal for learning programming. (Or heck, just throw him in with C, if you’ve got .)

  10. Hi Arthur, I also have a soft spot in my heart for BASIC and Pascal (I spent years using Turbo Pascal 2.0) but are they really the right thing to use now? I feel like Python captures most of what was good about those languages and has other benefits as well.

  11. I admit I’ve never tried to teach a child to program, using Basic or Pascal or Python or anything else for that matter. My recommendations are just based on the fact that I know Basic and Pascal worked for a lot of people back in the day, and I don’t know of [argument from ignorance] any modern languages that come with such easy-to-use graphical environments out of the box.

    Seems like most real languages suffer from “System.out.println syndrome” — the I/O commands are there, but they’re buried in a confusing and tiresome nest of namespaces. (C and C++ being the exception, in that they don’t *have* I/O other than the standard streams.)

    But Python seems reasonable too. You can always “from WConio import *” at the top of every program. Or use pygame, although pygame definitely has System.out.println syndrome.

  13. That sounds like a good project, John. Send him to my Scratch camp next summer.

    We also use Python with Pygame and Processing in the camps. I also really like the Processing spirit and that you can get something cool in a small bit of code. And since it is basically Java, kids enjoy seeing it go on an Android tablet.

    I am also starting to look at HTML5 as a starter language since it is fun to see a browser do things.