Toluu

Programming in the 21st Century

Revisiting "Purely Functional Retrogames"January 4

I wrote the Purely Functional Retrogames series as an experiment. There's been so much empty talk about how functional languages are as good or better than imperative languages--yet very little to back that up. Doubly so in regard to interactive applications. I'd bet there are more people learning to program the Atari 2600 hardware than writing games in Haskell.

For people who only read the beginnings of articles, let me say this up front: Regurgitating the opinion that functional programming (or any technology) is superior does absolutely nothing. That's a road of endless conjecture and advocacy. One day you'll realize you've been advocating something for ten years without having any substantial experience in it. If you think a particular technology shows promise, then get in there and figure it out.

The rest of this entry is about what I learned by writing some retro-style games in Erlang.

The divide between imperative and functional languages, in terms of thinking about and writing code, is much smaller than I once thought it was. It is easy to accidentally introduce side-effects and sequencing problems into purely functional code. It is easy to write spaghetti code, where the entanglement comes from threading data through functions rather than unstructured flow of control. There's mental effort involved in avoiding these problem

Accidentally Introducing Side Effects into Purely Functional CodeDecember 14 2008

It's easy to taint even purely functional languages by reintroducing side-effects. Simply have each function take an additional parameter representing the global state of the world--a tree of key/value pairs, for example--and have each function return a new state of the world. This is not news. It's an intentionally pathological case, not something I'd ever consider implementing.

What's more surprising is how easy it is to accidentally introduce side-effects.

For the Purely Functional Retrogames series, I wrote code that operated on a list of game entities: [A, B, C, D,...] Each element was a self-contained unit of sorts: an ID, x/y position, current state. Using this list of entities to build a new version for the next game frame was a simple map operation. The ID and state for each entity were used to call the correct transformation function for that entity.

Each of these transformations had three possible outcomes: a new entity would be returned with a different position and/or state, an entity could delete itself, or an entity could create some new entities (think of dropping a bomb or firing a shot). All three of these can be handled by having each transformation function return a list.

For example, if the original list was: [A, B, C, D] and entity "B" deleted itself, and entity "C" created four new entities in addition to a new version of itself, then the returned

Timidity Does Not ConvinceNovember 30 2008

The only arguments that hold water, in terms of programming language suitability, are bold, finished projects. Not a mini-Emacs written in Haskell. Not a Sudoku solver in Prolog. Not a rewrite of some 1970s video game using Functional Reactive Programming. They need to be large and daring projects, where the finished product is impressive in its own right, and then when you discover it was written in language X, there's a wave of disbelief and then a new reverence for a toolset you had previously dismissed.

And now, two of my favorite bold projects:

Wings 3D

Wings started as an attempt to clone Nendo, a 3D modeller designed around simplicity and ease of use. Nendo development and support had dried-up, and enthusiasm for Nendo fueled Wings 3D development. So now there's a full-featured, mature 3D modeller, with a great focus on usability, and it's written entirely in Erlang. Without a doubt it's the antithesis of what Erlang was designed for, with the entire program running as a single process and intensive use of floating point math. But it clearly works, and shows that there are benefits to using Erlang even outside of its niche of concurrency-oriened programming.

SunDog: Frozen Legacy

SunDog was an elaborate game for the Apple II. A 1MHz 6502 and 48K of memory look more like a platform for simple arcade games, not the space trading and exploration extravaganza that was SunDog. And though assembly language was the norm for circa-1984 c