programming in the
twenty-first century

It's not about technology for its own sake. It's about being able to implement your ideas.

Retiring Python as a Teaching Language

For the last ten years, my standard advice to someone looking for a programming language to teach beginners has been start with Python. And now I'm changing that recommendation.

Python is still a fine language. It lets you focus on problem solving and not the architectural stuff that experienced developers, who've forgotten what it's like to an absolute beginner, think is important. The language itself melts into the background, so lessons aren't explanations of features and philosophies, but about how to generate musical scales in any key, computing distances around a running track based on the lane you're in, or writing an automated player for poker or Yahtzee.

Then one day a student will innocently ask "Instead of running the poker simulator from the command line, how can I put it in a window with a button to deal the next hand?"

This is a tough question in a difficult-to-explain way. It leads to looking at the various GUI toolkits for Python. Turns out that Guido does the same thing every few years, re-evaluating if TkInter is the right choice for IDLE, the supplied IDE. For now, TkInter it is.

A week later, another question: "How can I write a simple game, one with graphics?"

Again, time to do some exploration into what's out there. Pyglet looks promising, but it hasn't been updated since July 2012. There are some focused libraries that don't try to do everything, like SplatGL, but it's pretty new and there aren't many examples. PyGame appears popular, and there's even a book, so okay let's start teaching how to use PyGame.

A month later, more questions: "How can I give this game I made to my friend? Even better, is there a way can I put this on my phone so I can show it to kids at school without them having to install it?"


All of these questions have put me off of Python as a teaching language. While there's rigor in learning how to code in an old-school way--files of algorithmic scripts that generate monochromatic textual output in a terminal window--you have to recognize the isolation that comes with it and how far away this is from what people want to make. Yes, you can find add-on packages for just about anything, but which ones have been through the sweat and swearing of serious projects, and which are well-intentioned today but unsupported tomorrow?

The rise of non-desktop platforms complicates matters, and I can sympathize. My goal in learning Erlang was to get away from C and C++ and shift my thinking to a higher level. I proved that I could use Erlang and a purely functional style to work in the domain that everyone is most scared of: games. Then the iPhone came out and that was that. Erlang wasn't an option.

It's with all of this in mind that my recommended language for teaching beginners is now Javascript. I know, I know, it's quirky and sometimes outright weird, but overall it's decent and modern enough. More importantly it's sitting on top of an unprecedentedly ubiquitous cross-platform toolkit for layout, typography, and rendering. Want to display UI elements, images, or text? Use HTML directly. Want to do graphics or animation? Use canvas.

I expect some horrified reactions to this change of thinking, at least to the slight degree that one can apply horrified to a choice of programming language. Those reactions should have nothing to do with the shortcomings of Javascript. They should be because I dismissed so many other languages without considering their features, type systems, or syntaxes, simply because they aren't natively supported by modern web browsers.

permalink January 20, 2015



twitter / mail

I'm James Hague, a recovering programmer who has been designing video games since the 1980s. Programming Without Being Obsessed With Programming and Organizational Skills Beat Algorithmic Wizardry are good starting points. For the older stuff, try the 2012 Retrospective.

Where are the comments?