I always intended "Programming in the 21st Century" to have a limited run. I knew since the entry from January 1, 2010, that I needed to end it. It just took a while.Recovering Programmer 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! 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.Purely Functional Retrogames 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 in the title.programming I don't think of myself as a programmer. I write code, and I often enjoy it when I do, but that term 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.programmer 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 if you want everything. (There are some bits in there.)archivesodd Also see the for all of the functional programming articles.previous entry is something I wrote in 2004 which used to be linked from every prog21 entry.Programming as if Performance Mattered widely linked popular on creativity others that I like Erlang retro Things That Turbo Pascal is Smaller Than Do You Really Want to be Doing This When You're 50? Organizational Skills Beat Algorithmic Wizardry Retiring Python as a Teaching Language Computer Science Courses that Don't Exist, But Should Five Memorable Books About Programming A Spellchecker Used to Be a Major Feat of Software Engineering Want to Write a Compiler? Just Read These Two Papers. On Being Sufficiently Smart Optimizing for Fan Noise Free Your Technical Aesthetic from the 1970s Advice to Aimless, Excited Programmers Write Code Like You Just Learned How to Program Don't Distract New Programmers with OOP Recovering From a Computer Science Education Don't Fall in Love With Your Technology A Complete Understanding is No Longer Possible Solving the Wrong Problem This is Why You Spent All that Time Learning to Program We Who Value Simplicity Have Built Incomprehensible Machines Your Coding Philosophies are Irrelevant The Silent Majority of Experts Hopefully More Controversial Programming Opinions How much memory does malloc(0) allocate? The Pure Tech Side is the Dark Side Flickr as a Business Simulator How to Think Like a Pioneer What Do People Like? Accidental Innovation, Part 1 If You're Not Gonna Use It, Why Are You Building It? It's Like That Because It Has Always Been Like That Trapped by Exposure to Pre-Existing Ideas Get Good at Idea Generation You Can't Sit on the Sidelines and Become a Philosopher The Software Developer's Sketchbook Design is Expensive Why Doesn't Creativity Matter in Tech Recruiting? Deriving Forth Tales of a Former Disassembly Addict Living Inside Your Own Black Box Tricky When You Least Expect It The Most Important Decisions are Non-Technical Things to Optimize Besides Speed and Memory All that Stand Between You and a Successful Project are 500 Experiments The UNIX Philosophy and a Fear of Pixels Dangling by a Trivial Feature Documenting the Undocumentable You Don't Want to Think Like a Programmer You Don't Read Code, You Explore It If You Haven't Done It Before, All Bets Are Off What Can You Put in a Refrigerator? The Same User Interface Mistakes Over and Over Fun vs. Computer Science A Deeper Look at Tail Recursion in Erlang My Road to Erlang Garbage Collection in Erlang How to Crash Erlang Eleven Years of Erlang A Ramble Through Erlang IO Lists A Concurrent Language for Non-Concurrent Software A Peek Inside the Erlang Compiler Evolution of an Erlang Style A Personal History of Compilation Speed Slow Languages Battle Across Time How Much Processing Power Does it Take to be Fast? 8-Bit Scheme: A Revisionist History Stumbling Into the Cold Expanse of Real Programming Why Do Dedicated Game Consoles Exist? Lost Lessons from 8-Bit BASIC Programming Modern Systems Like It Was 1984

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