It's not about technology for its own sake. It's about being able to implement your ideas.
In The Nostalgia Trap I wrote, "I was in contact with a hundred or more designers of 8-bit computer games, and I learned their stories." Those stories were fantastically interesting, but most of them were only incidentally about programming. The programming side usually went like this:
Early home computers were magic, and upon seeing one there was a strong desire to learn how to control it and create experiences from moving graphics and sound. At power-up there was the prompt from a BASIC interpreter, and there was a BASIC reference manual in the box, so that was the place to start.
Later there was serendipitous exposure to some fast and impressive game that was far beyond the animated character graphics or slow line-drawing of BASIC, and that led to the discovery of assembly language and the freedom to exploit the hardware that came with it. It was suitably clunky to be writing a seven instruction sequence to do 16-bit addition and remembering that "branch on carry set" could be thought of as "branch on unsigned greater or equal to." The people with prior programming experience, the ones who already knew C or Algol or Scheme, they may have been dismayed at the primitive nature of it all, but really it came down to "you do what you have to do." The goal was never to describe algorithms in a concise and expressive manner, but to get something interactive and wonderful up on the screen.
Now imagine if an Atari 800 or Commodore 64 shipped with a CPU designed to natively run a high-level language like Scheme. That's not completely outrageous; Scheme chips were being developed at MIT in the late 1970s.
My suspicion is that Scheme would have been learned by budding game designers without a second thought. Which language it was didn't matter nearly so much as having a language that was clearly the right choice for the system. All the quirks and techniques of Scheme would have been absorbed and worked around as necessary.
It's not so simple with today's abundance of options, none of which is perfect. Haskell is beautiful, but it looks difficult to reason about the memory usage of Haskell code. Erlang has unappealing syntax. Python is inconsistently object-oriented. Lisp is too bulky--Scheme too minimalist. All of these ring more of superficiality than the voice of experience. Yet those criticisms are preventing the deep dive needed to get in there and find out how a language holds up for a real project.
What if you had to use Scheme? Or Haskell? Or Erlang? You might slog it out and gain a new appreciation for the mundane, predictable nature of C. Or you might find out that once you've worked through a handful of tricky bits, there are great advantages in working with a language that's more pleasant and reliable. Either way, you will have learned something.
(If you liked this, you might enjoy Five Memorable Books About Programming.)
permalink August 4, 2011
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?