In 1999 I earned $200 writing an essay titled Toward Programmer Interactivity: Writing Games in Modern Programming Languages. It was an early, optimistic exploration of writing commercial games in Haskell, ML, and Lisp.

It was not a good article.

It's empty in the way that so many other "Hey everyone! Functional programming! Yeah!" essays are. I demonstrated the beauty of Haskell in the small, but I didn't offer any solutions for how to write state-heavy games in it. There are a few silly errors in the sample code, too.

Occasionally during the following years, I searched for information about writing games in functional languages, and that article kept coming up. Other interesting references turned up too, like papers on Functional Reactive Programming, but apparently I had accidentally become an authority. An authority who knew almost nothing about the subject.

I still didn't know if a mostly-functional style would scale-up past the usual toy examples. I didn't know how to build even a simple game without destructive assignment. I wasn't sure if there were even any legitimate benefits. Was this a better way of implementing game ideas than the usual tangled web of imperative code--or madness?

As an experiment, I decided to port an action game that I wrote in 1997 to mostly-pure Erlang. It wasn't a toy, but a full-featured game chock full of detail and special cases. I never finished the port, but I had the bulk of the game playable and running smoothly, and except for a list of special cases that I could write on a "Hello! My Name is" label, it was purely functional. I wrote about what I learned in Purely Functional Retrogames.

Now when I search for info about writing games in a functional style, that's what I find.

Sure, there are some other sources out there. Several times a year a new, exuberant "Haskell / ML / Erlang is a perfect match for games!" blog entry appears. Functional Reactive Programming keeps evolving. A couple of people have slogged through similar territory and managed to bang-out real games in Haskell (Raincat is a good example).

If you want to be on the cutting edge of functional programming research, it's easy. Pick something that looks like a poor match for state-free code, like a video game, and start working on it. Try to avoid going for the imperative pressure release valves too quickly. At some point you're going to need them, but make sure you're not simply falling back on old habits. Keep at it, and it won't be long before you're inventing solutions to problems no one else has had to deal with.

If you come up with something interesting, I'd like to hear about it.

(If you liked this, you might enjoy Back to the Basics of Functional Programming.)

I occasionally get puzzled questions about a parenthetical remark I made in 2010: that I no longer program for a living. It's true. I haven't been a full-time programmer since 2003. The short version of these questions is "Why?" The longer version is "Wait, you've got a super technical programming blog and you seem to know all this stuff, but you don't want to work as a programmer?"

The answer to both of these is that I realized that the most important decisions are non-technical. That's a bare and bold statement, so let me explain.

In the summer of 1993, I answered a newspaper ad looking for a "6502 hacker" (which I thought was amusing; the Pentium was released that same year) and got a job with a small company near Seattle writing Super Nintendo games. I had done game development prior to that, but it was me working by myself in my parents' living room.

The first SNES game I worked on was a Tarzan-themed platformer authorized by the estate of Edgar Rice Burroughs (it had no connection to the Disney movie, which was still six years in the future). I had fun working out ways of getting tropical fish to move in schools and creating behaviors for jungle animals like monkeys and birds. It was a great place to work, with the ten or so console programmers all sharing one big space.

The only problem was that the game was clearly going to be awful. It was a jumble of platformer clichés, and it wasn't fun. All the code tweaking and optimization and monkey behavior improvements weren't going to change that. To truly fix it required a project-level rethink of why were building it in the first place. As a "6502 hacker" I wasn't in a position to make those decisions.

While it's fun to discuss whether an application should be implemented in Ruby or Clojure, to write beautiful and succinct code, to see how far purely functional programming can be taken, these are all secondary to defining the user experience, to designing a comfortable interface, to keeping things simple and understandable, to making sure you're building something that's actually usable by the people you're designing it for. Those are more important decisions.

Whatever happened to that Tarzan game? Even though it had been previewed in Nintendo Power, the publisher wisely chose to pay for the year of development and shelve the finished project.

That a clean system for separately compiled modules appeared in Modula-2, a programming language designed by Niklaus Wirth in 1978, but not in the 2011 C++ standard...hmmm, no further comment needed. But the successor to Modula-2, Oberon, is even more interesting.

With Oberon, Wirth removed features from Modula-2 while making a few careful additions. It was a smaller language overall. Excepting the extreme minimalism of Forth, this is the first language I'm aware of where simplicity of the implementation was a concern. For example, nested modules were rarely used in Modula-2, but they were disproportionately complex to compile, so they were taken out of Oberon.

That simplicity carried over to optimizations performed by the compiler. Here's Michael Franz:

Optimizing compilers tend to be much larger and much slower than their straightforward counterparts. Their designers usually do not follow Oberon's maxim of making things "as simple as possible", but are inclined to completely disregard cost (in terms of compiler size, compilation speed, and maintainability) in favor of code-quality benefits that often turn out to be relatively marginal. Trying to make an optimizing compiler as simple as possible and yet as powerful as necessary requires, before all else, a measurement standard, by which both simplicity and power can be judged.

For a compiler that is written in the language it compiles, two such standards are easily found by considering first the time required for self-compilation, and then the size of the resulting object program. With the help of these benchmarks, one may pit simplicity against power, requiring that every new capability added to the compiler "pays its own way" by creating more benefit than cost on account of at least one of the measures.

The principle is "compiler optimizations should pay for themselves."

Clearly it's not perfect (the Oberon compiler doesn't make heavy use of floating point math, for example, so floating point optimizations may not speed it up or make it smaller), but I like the spirit of it.

(If you liked this, you might enjoy Papers from the Lost Culture of Array Languages.)