When I started this blog in 2007, a running theme was "Can interactive experiences like video games be written in a functional style?" These are programs heavily based around mutable state. They evolve, often drastically, during development, so there isn't a perfect up-front design to architect around. These were issues curiously avoided by the functional programming proponents of the 1980s and 1990s.
It's still not given much attention in 2016 in either. I regularly see excited tutorials about mapping and folding and closures and immutable variables, and even JavaScript has these things now, but there's a next step that's rarely discussed and much more difficult: how to keep the benefits of immutability in large and messy programs that could gain the most from functional solutions--like video games.
Before getting to that, here are the more skeptical functional programming articles I wrote, so it doesn't look like I'm a raving advocate:
- Admitting that Functional Programming Can Be Awkward
- Back to the Basics of Functional Programming
- Functional Programming Went Mainstream Years Ago
- Puzzle Languages
- Let's Take a Trivial Problem and Make it Hard
- Functional Programming Doesn't Work (and what to do about it)
I took a straightforward, arguably naive, approach to interactive functional programs: no monads (because I didn't understand them), no functional-reactive programming (ditto, plus all implementations had severe performance problems), and instead worked with the basic toolkit of function calls and immutable data structures. It's completely possible to write a video game (mostly) in that style, but it's not a commonly taught methodology. "Purely Functional Retrogames" has most of the key lessons, but I added some additional techniques later:
- Purely Functional Retrogames (4 parts)
- Turning Your Code Inside Out
- A Worst Case for Functional Programming?
- Messy Structs/Classes in a Functional Style
- Reconsidering Functional Programming
The bulk of my experience came from rewriting a 60fps 2D shooter in mostly-pure Erlang. I wrote about it in An Outrageous Port, but there's not much detail. It really needed to be a multi-part series with actual code.
For completeness, here are the other articles that directly discuss FP:
- Functional Programming Archaeology
- Accidentally Introducing Side Effects into Purely Functional Code
- Explaining Functional Programming to Eight-Year-Olds
- Erlang vs. Unintentionally Purely Functional Python
- Starting in the Middle
- You, Too, Can Be on the Cutting Edge of Functional Programming Research
- Tips for Writing Functional Programming Tutorials
- Purely Functional Photoshop
If I find any I missed, I'll add them.
permalink December 29, 2016