A colleague recently asked if I had any thoughts on what would be “a good first programming language” for a precocious 9-year-old who was very  much into computers and wanted to learn programming, giving me an excuse to agonize about this again.

The executive summary of my current opinion is probably “Scratch if you want training wheels, Python otherwise”, but if this sort of thing interests you, read on.

My colleague’s question gave me an excuse to wring my hands about it some more, and even talk to some other people about it seriously, including Colleen Lewis, a Berkeley computer scientist and educator whose opinion I respect tremendously on such matters, and a bunch of smart colleagues from industry who attended the recent RAD Lab retreat.

We concluded that there’s a handful of absolutely fundamental concepts that are (a) common to the vast majority of programming paradigms/languages and (b) not “natural” in the sense that they have no obvious analog in non-programming-based activities and simply have to be internalized:

• variables and assignment
• manipulating collections of elements (arrays exist even in languages that don’t support user-defined data structures)
• conditional evaluation
• control flow
• iteration
• subprograms (i.e., procedural abstraction)

(I’ve deliberately omitted OO; while really important, it’s not fundamental in that there’s lots of programs you can write without it.)

Beyond focusing on absorbing those concepts, a “good first language” should make the young programmer feel empowered at being able to do stuff, gradually stripping away the “mystique” of how computers do the cool things they do.

Hence my concerns about Scratch, a popular GUI-based programming environment designed for teaching that we are starting to use at Berkeley for the intro-level CS class.  Colleen reassured me that it’s possible to write non-toy programs in Scratch once you ditch the GUI, that it supports constructs like lambda expressions that let you teach important concepts like closures, and that students who complete the new intro course also understand things like objects and class inheritance and are more than ready to tackle any programming language.  My concern is that the Scratch GUI environment is so amazingly rich and polished that it might diminish the sense of empowerment—even if you write a cool program, there’s still just too much magic between your program and the machine.  The nice thing about Scratch is that it’s widely used in education so (I assume) there’s lots of freely-available supplementary materials to go with the software.  (Wearing my “productivity programming” hat, I’d say Scratch is almost too productive because so much is happening beyond the code you wrote.)

The alternative seems to be Python, probably the closest thing to BASIC these days (albeit a much better language, of course).  And in fact I found a pretty good book—Hello World: Computer Programming for Kids and Other Beginners—co-authored by a programmer and his young son and written in a kid-friendly yet noncondescending way.  The downside is that while Python is a pretty nice language, like all languages it has a few quirky notations, idiosyncrasies, arbitrary-seeming behaviors, etc. While the book goes out of its way to clarify these only as much as needed, their presence might detract from a learning experience…but then, to be fair, the same was true of BASIC way back when, and probably those of us who glamorize learning it have selective amnesia about getting bitten by those idiosyncrasies and learning to work around them.

So maybe my current recommendation is: for a gentle introduction with training wheels and rubber bumpers, Scratch; for something a little more hardcore that you won’t outgrow (Python is used for lots of real programs) but comes complete with real-life idiosyncracies, Python with the above book.

The good news is that while neither is “built in” to today’s PCs like BASIC used to be, they’re both open source free downloads.

Ideas from anyone who’s actually helped their kids learn to program?  (I have no kids, only a toucan, and it’s unlikely she’ll learn to program anytime soon.)

PlayPower’s booth at Maker Faire had a couple of these devices on display. The NES, also called the Famicom in Asia, was a 6502-based cartridge game system whose technology was only half a generation or so ahead of the Atari 2600. The device plugs into a TV (they have both composite video out and RF out, and soldering an undocumented pad on the board switches between NTSC and PAL) and come with a starter cartridge that has various game titles on it, and even seems to have programs that “simulate” word processing and Web browsing (kind of like “my first cell phone” toys simulate making phone calls). Presumably, the carts have ROMs that take over part of the address space when plugged in; the more advanced Atari carts had some additional bank-switching logic (triggered by memory-mapped I/O) that allowed multiplexing lots of different game levels into a fixed amount of address space, typically around 4K.

Intriguingly, Bob Brost at CMU taught a class on NES game development and even produced “nBasic”, a BASIC-level (sort of) language that, although it eliminates the need to program in 6502 assembly, it does not seem to eliminate the need to understand the arcane programming approach required by these devices, i.e. you have to time your code around the vertical retrace interval (only “safe” to write GPU registers during vertical retrace to avoid flickering/loss of picture sync), etc. 

So my questions would be: is this level of programming abstraction going to be sufficient to catalyze the development of a lot of “edu-ware” for these devices? Given that the source of this “edu-ware” is ultimately (we hope) going to be programmers in the very countries in which the devices are sold, should we be looking for something that enables a much higher level of abstraction for development—say, something more like Scratch—and port a subset of it to this 8-bit world?

(Update: the Design For Developing Countries wiki has a lot of great information about their progress and preliminary studies.)

(For the curious, the NES has:

• a 1.9MHz 8-bit 6502
• 32K ROM address space for game code & data (typically 16K code, 16K swappable to store different “levels” data)
• 240w x 248h viewable graphics (NTSC or PAL) organized as 8×8 pixel “tiles” for the purposes of color palette assignment, sprite rendering, etc.
• system, background and foreground color palettes (64, 16 and 16 entries respectively)
• up to 64 sprites (8×8 or 8×16 pixels, 3 colors + transparent color, no more than 8 sprites per scanline)
• 4 synthesizer channels (2 square waves, 1 triangle, 1 white noise) with ~6 octave range; one note per channel at a time

I have to admit, the pervasive availability of $10 TV-computers is awfully compelling, as someone who remembers very vividly what remarkable things can be done within the constraints of these old 6502 systems.