It's not about technology for its own sake. It's about being able to implement your ideas.
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.
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:
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:
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:
If I find any I missed, I'll add them.
permalink December 29, 2016
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?