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: 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 , but there's not much detail. It really needed to be a multi-part series with actual code.An Outrageous Port For completeness, here are the other articles that directly discuss FP: If I find any I missed, I'll add them. 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) (4 parts)Purely Functional Retrogames Turning Your Code Inside Out A Worst Case for Functional Programming? Messy Structs/Classes in a Functional Style Reconsidering Functional Programming 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

We've all seen progress bars that move slowly for twenty minutes, then rapidly fill up in the last 30 seconds. Or the reverse, where a once speedy bar takes 50% of the time covering the last few pixels. And bars that occasionally jump backward in time are not the rarity you'd expect them to be. Even this past month, when I installed the macOS Sierra update, the process completed when the progress bar was only two-thirds full. DOOM 2016 has a circular progress meter for level loads, with the percent-complete in the center. It often sits for a while at 0%, gets stuck at 74% and 99%, and sometimes finishes in the 90s before reaching 100%. Clearly this is not a trivial problem, or these quirks would be behind us. Conceptually, a perfect progress bar is easy to build. All you need to know is exactly how long the total computation will take, then update the bar in its own thread so it animates smoothly. Simple! Why do developers have trouble with this? Again, all you need to know is ...exactly how long Oh. You could time it with a stopwatch and use that value, but that assumes your system is the standard, and that other people won't have faster or slower processors, drives, or internet connections. You could run a little benchmark and adjust the timing based on that, but there are too many factors. You could refine the estimate mid-flight, but this is exactly the road that leads to the bar making sudden jumps into the past. It's all dancing around that you can't know ahead of time exactly how long it should take for the progress bar to go from empty to full. There's a similar problem in process scheduling, where there are a number of programs to run sequentially in batch mode. One program at a time is selected to run to completion, then the next. If the goal is to have the lowest average time for programs being completed, then best criteria for choosing the next program to run is the one with the shortest execution time (see ). But this requires knowing how long each program will take before running it, and that's not possible in the general case.shortest job next And so the perfect progress bar is forever out of reach, but they're still useful, as established by Brad Allan Meyers in his 1985 paper ("The importance of percent-done progress indicators for computer-human interfaces"). But "percent-done" of what? It's easy to map the loading of a dozen similarly sized files to an overall percentage complete. Not so much when all kinds of downloading and local processing is combined together into a single progress number. At that point the progress bar loses all meaning except as an indication that there's some sort of movement toward a goal, and that mostly likely the application hasn't hasn't locked up. (If you liked this, you might enjoy .)An Irrational Fear of Files on the Desktop