How should we teach programming?

One of Shimon Schocken’s colleagues says that “Computer science is a thousand layers of abstraction.” This is quite true, and the same applies for programming.

Recently I’ve been thinking a lot about how we can get more people involved with programming. I don’t necessarily mean programming as professionals, but just to develop enough of an understanding on what software is and how it works. So I wrote a book aimed at teaching games programming in Python to the 9 to 12 year age range (get ‘em while they’re young). In my “Python is the new BASIC” post, (which was a plug for my free, Creative Commons-licensed book, “Invent Your Own Computer Games with Python”) I received this comment:

You know, I took a look at that game book and it struck me how so 1980s the thing was. It brought me down to memory lane.

Now, looking at the alternative (Squeak), which is fully OOP all the way down to the very menus and icons, buttons, which has a much richer environment and is totally ready for multimedia, along with the derived (written in Squeak) Scratch language, I think it’s very bad that we’re returning to Basic.

Kids deserve something better in 2008, and we can deliver it, just as long as we keep our prejudice at bay against Smalltalk (because it really is about prejudice and lack of information).

1980s would be right. I based the book I wrote on a 1983 book that taught me BASIC programming (adding Python’s modern features). However, my book specifically avoids higher-level concepts such as object-oriented progamming, event-driven applications, and graphics. I thought these concepts would hide the actual underlying workings of the programs. By using textual input and output from simple raw_input() calls and print statements, my book could focus on variables, expressions, and flow control. I wanted as little “magic” as possible.

“Programming is a thousand layers of abstractions.” I’ll argue that to really understand software, one has to go down this rabbit hole all the way to the bottom, as far as assembly or machine language. But one doesn’t need to understand assembly (arguably the lowest of the programming abstraction layers) in order to actually write useful software, even professionally. And for the purpose of teaching programming, those layers of abstractions save us a lot of tedious details. The key to teaching programming is to find that ideal middle ground: low enough to pull back the “automagic” curtain, high enough to stay above minutia.

My book aims low. There are already several high-level game engine SDKs and drag-and-drop game creator packages to make programming easy (well, easier). I would lose the appeal of graphics, animation, and sprites, and instead rely on text and ASCII art. I would use function calls and loops, a level below recursion and callbacks but above dread goto statements. The high-level space already has lots of ink or bytes devoted to it already, so I aimed low.

But maybe I’ve gone too low. I fell back on my target audience (which I pictured as my 9-year-old self). I learned programming from a book that taught games programming in BASIC (which I used as a starting template for IYOCGwP). It covered a lot less ground than my book (the syntax for Python makes complex programming tasks easier). That book had opened up an entirely new creative world for me, which I hope my book will also do. Ask any software developer with motivation that extends beyond a mere paycheck, and they will have a similar “How I Learned to Program” story.

And even though the games in the BASIC book I read were only text, they still held my attention. Console video games of the day (i.e. my 16-bit Super Nintendo) had games that were far more engaging than anything I ever made, but coding my own Tic Tac Toe program still appealed to me. Programming was a fun, creative task. The fruits of my labor were simple, but they were mine.

Is this low approach what we’ve been missing in programming education? Michael Kölling’s Greenfoot and MIT’s Scratch environments have been great successes at general computer science education. Both make liberal use of graphics and automagic techniques that make introducing high-level computer science concepts accessible to the general audience. But I feel that a low enough level of understanding software may be lost in this approach as well.

I’ll be the first to admit, my book’s approach is experimental. I have no trouble confessing that it will probably not appeal to a wide audience of children. But for the neophyte geeks (such as my 9-year-old self), I think a more direct approach gives the young (and not so young) programmer an education that can be applied to a much wider scope of software. Python is both easy to learn, but scales into almost every domain of software development and the professional world.

I’ve been putting some thought into the next book, whose content will be determined by the success (or lack thereof) of this first book. I’m going to keep the teach-by-example format of presenting an entire game’s source code and explaining the principles from the code (unlike teaching principles without immediate and complete application), but I don’t know how high of a step up the abstraction stack I want to take it. I want to introduce graphics, but I don’t know if I will continue with ASCII text with the curses library, or dive into PyGame or Pyglet.

I encourage anyone to take a look at the book (I offer it on http://pythonbook.coffeeghost.net in full for free under a Creative Commons license.) and offer an opinion: how high or low on the abstraction stack should we teach computer programming to those new to the skill? (Especially young folks.) Should we use real languages (like BASIC, Python, Smalltalk, or Java) or languages made specifically for teaching (Scratch, Logo, etc.) Should we have them learn pointers, object-oriented programming, assembly, functional programming, GUIs and/or graphics?

Should we aim high or aim low?

This is the basic problem with learning how to program computers these days:

public class Hello
{
public static void main(String[] args)
{
System.out.println(”Hello World!”);
}
}

The above is the Hello World program for Java, arguably one of the most popular programming languages. Encapsulated in the above three lines are several different concepts ranging from static functions to return types to stdout and to the entirety of object oriented programming in general.

Below is the Hello World program for BASIC:

10 PRINT “Hello World!”

One line. Simple. Back in the days of the Commodore 64, simple software was forgivable, it was expected. The expectation that computer programming is achievable by kids and mere mortals still existed. And BASIC came with most home PCs as well. Writing simple programs and games was a large part (or at least, larger part) of owning a computer.

These days, with physics engines, 3D graphics, MMORPGs, and professional artwork, that expectation is gone. Text-only games with ASCII art are considered obsolete, and the replacement for BASIC has mostly been game creation kits that offer drag-and-drop, point-and-click interfaces to tie together multimedia elements into games that mostly follow fit the same genre. Behind all the graphics and menus and wizards, the art of programming is lost.

The replacement for BASIC has been clumsy at best. How do we introduce fancy GUIs, graphical animation, and ’splosions to beginner programmers? Visual Basic? HTML/Javascript? Some random, closed source “4 kidz” programming language whose company will fold in three years? NO!!! You can’t be serious!!! (more…)

A new video on atheism where I talk about the theist’s concept of moral absolutism and why I think it is an incorrect and impractical view to have.

Transcript: (more…)

A poem that I wrote that any geek with grand project ideas can relate to. (By the way, I’ve finally settled on Django as the framework for my next web app. Maybe with SQLAlchemy. Or not. Or maybe I’ll do it in LISP instead. Or Haskell. Or Erlang. Either way, I still need to learn more JavaScript for the front-end. I should probably buy another book on it. Or two.)

Starting Out, by Albert Sweigart

“When starting out,” the sculptor said,
“First lay out your tools with care.
And always remember, through and through,
The most important thing is to prepare.”

The sculptor’s tools were neat and ordered,
His studio was well-lit and clean,
He always began by sweeping eleven times,
And sometimes twelve or thirteen.

Centered was an untouched marble block,
His raw, undeveloped masterpiece,
Here is where the magic was made,
On this stone his genius would be released.

“But not so fast,” the sculptor warned,
“Great works don’t just fall from Heaven,
After all, it takes nine months to make a baby,
And sometimes, ten or eleven.” (more…)

The title comes from an astute commenter named Frank on my last post, Your Ignorance Does Not Make a Programming Language Suck. Many of the comments on the post and the comments on Reddit quickly devolved into precisely the kind of language war I spoke against.

If I were a cynic (and on alternate odd days I am), I would say that it’s an inevitable side effect of the blog-comments medium. You can say, “I like chocolate ice cream” and you’ll get a slew of angry comments, half demanding why you hate chocolate ice cream and the other half demanding why you think chocolate is better than every other flavor.

But it is an interesting question: Is it possible at all to discuss language wars without starting one? Not really. Most reasonable debates about programming languages fail for a number of reasons. (more…)