So I’d say I’m a post-newbie stage functional programmer.  I tend to program in Haskell no matter what language I’m using, as they say.  I go for purity even when it hurts.

But I’ve actually never made a complex game with a functional language.   It turns out there’s some tricky bits, and I ended up wasting an enormous amount of time on them.  I’m not sure I even learned anything.  Maybe I learned: 1) You can fudge random numbers with sufficiently weird multiplication, 2) Functional programming does not ensure non-crufty code.  This was some of the ugliest code I’ve ever written.

Last week I made an asteroids clone in Elm that ended up being more fun than my compo game. But maybe that’s because asteroids is just fun.

Things I like about Elm:

1. It has a really useful time-traveling debugger.  You should check it out.
2. It never froze.  If it compiles, it’s solid.  Pretty much.  But I’m used to that with other functional languages.

Things I didn’t like:

1. I’m actually a little puzzled about the benefits of functional reactive programming for game programming.  The structure of the code ended up not looking much different than my naive non-FRP games in functional languages.  The whole signal-processing part of it is really only a few lines.  Maybe I’m missing something.
2. Random numbers. lol. I’m just totally unaccustomed to the functional way of dealing with this. Using random numbers anywhere pollutes everything. Every function that touches a random number has to pass a seed around. Blech.
3. Elm is supposed to have human-readable error messages.  But they were actually atrocious.  I assume this is a work-in-progress, but I really, really missed GHC’s unfriendly messages this weekend.
4. I like using little sprites.  Like, 16×16 or 32×32.  But I can’t make a low-res game with elm.  I can only make a very small canvas.  So I ended up with just tiny little sprites