Disclaimer: If you’ve read a certain previous article of mine, you may have noticed that this opinion represents an almost-complete reversal on the one expressed there. Hang in there. I think this one is better.

Why is C still as popular as it is amongst free-software-hacker types? Why are command-line interfaces treated as the one true way to control a computer by many of these same people? Should IRC still be popular, despite missing lots of functionality that centralized chat platforms have had for years? Why am I writing this in Vim on the console? While there’s certainly some logical reasoning behind choosing “simpler” technology (like escaping the hamster wheel of backwards incompatibility1), some of the reasons that people use for why they avoid anything that they believe is excessively complex are silly and potentially dangerous, holding back developers from the state of the art in computing.

First of all, there’s no true “simplicity” in computers. Transistors are pretty easy to wrap your mind around. Anything beyond that level gets complex quick; even relatively basic 8-bit CPUs and microcontrollers aren’t simple in the least. Needless to say, modern computers aren’t something you can debug by attaching a logic probe. The x86_64 instruction set is a monstrosity of compatibility layers. The C language, treated by some as the pinnacle of programming language design, isn’t simple nor “how the machine works”. Maybe C maps well to a PDP-11, but it certainly doesn’t correspond to anything made this millennium. The “UNIX philosophy” hasn’t dictated software design on Unix-like systems for a long time, not that it ever bred a quality user experience in the first place. From analog interference in the circuitry of computers to the pile-of-hacks software running atop it, there never was and never will be simplicity in computing.

That doesn’t mean that there isn’t a time and place for deliberately simpler software. Complexity spiraling out of control is the cause of a lot of security vulnerabilities. It’s also nice to be able to wrap your mind completely around a project. In the past, however, software has come to the rescue, allowing us to write projects an order of magnitude bigger and with hundreds of developers. If it hadn’t been for version control, package managers, testing, fuzzing, and other tooling innovations, we wouldn’t be where we are today. And as a side effect of computing being more and more accessible to people everywhere, incidental complexity has also increased. You can’t ignore the billions of users whose native languages don’t fit in ASCII and keyboards aren’t the en_US design, not to mention those who have impairments that make using computers “normally” impossible.

Now that it’s obvious why an excessive desire for a false sense of simplicity is a dangerous thing, allow me to caution against the polar opposite approach: taking everything from academia to be gospel, piling on layers upon layers of 3-line packages, or building systems that are excessively complex to be able to better handle some kind of “future demand”. Enterprise-style Java doesn’t solve anything other than maybe the programmer’s financial troubles if they’re paid by the line of code. While package managers are a great solution to a lot of problems, my node_modules directory should not contain thousands of packages for a project with zero lines of code. If most programmers need months of study to understand your code (especially since “academic Haskell” and “Haskell at work” are so different), that’s a problem. Somewhere between the two extremes lies “pragmatism”, a surprisingly difficult-to-achieve goal that allows for getting the real work done. Over time, what constitutes “pragmatic” has moved more towards the complex side, so maybe it won’t be too long before we see Haskell everywhere.

If you’re writing real software, for real people, you can’t just ignore the hard questions for the sake of “avoiding complexity”2.


  1. Thank you to Steve Losh for apparently inventing this phrase that I didn’t know I needed until I started seeing it. 

  2. At the same time, if you’re making a hobby project, you’re allowed to deliberately ignore a lot of what I just said. However, much of what we rely on today started as a hobby project, so maybe it isn’t a bad idea to apply good engineering practices. As software development changes from a pastime or an academic curiosity to a nascent full-fledged industry, more serious problems can’t be brushed away.