I always intended "Programming in the 21st Century" to have a limited run. I knew since the Recovering Programmer entry from January 1, 2010, that I needed to end it. It just took a while.
And now, an explanation.
I started this blog to talk about issues tangentially related to programming, about soft topics like creativity and inspiration and how code is a medium for implementing creative visions. Instead I worked through more technical topics that I'd been kicking around over the years. That was fun! Purely Functional Retrogames is something I would have loved to read in 1998. More than once I've googled around and ended up back at one of my essays.
As I started shifting gears and getting back toward what I originally wanted to do, there was one thing that kept bothering me: the word programming in the title.
I don't think of myself as a programmer. I write code, and I often enjoy it when I do, but that term programmer is both limiting and distracting. I don't want to program for its own sake, not being interested in the overall experience of what I'm creating. If I start thinking too much about programming as a distinct entity then I lose sight of that. Now that I've exhausted what I wanted to write about, I can clear those topics out of my head and focus more on using technology to make fun things.
Thanks for reading!
It's hard to sum up 200+ articles, but here's a start. This is not even close to a full index. See the archives if you want everything. (There are some odd bits in there.)
Also see the previous entry for all of the functional programming articles.
Programming as if Performance Mattered is something I wrote in 2004 which used to be linked from every prog21 entry.
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 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.
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 shortest job next). But this requires knowing how long each program will take before running it, and that's not possible in the general case.
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.)