🖙There Wasn't an Era of Software Quality, LOL
I recently read an, ummm, opinionated article about Jai. I'm not going to talk much about Jai here; you can't make me talk about Jonathan Blow on Alys Plus. (And less snarkily, I"m not going to write about a language that I can't use or read the documentation of.) But one header stood out to me: " The lost era of good software." This seems like the perfect example of what I was talking about in my previous post, "A Lot of Statements about Software Speed and Quality are Just Vibes." This is one of the stronger claims in that section:
The net effect of this is that the software you’re running on your computer is effectively wiping out the last 10-20 years of hardware evolution; in some extreme cases, more like 30 years. The impact of this on things like server costs, environmental footprint, user experience, and overall outcomes for everybody is staggering.
One one level, this isn't as an egregious statement in itself or in relation to the header about an era of software quality. I mean, you need 30 years of hardware evolution to be able to wipe it away. I guess you could write software in the early 80s that wipes out 20 years of hardware evolution, but it would be unusably slow. Maybe the 80s were the lost era of good software? Certainly there was good software produced during that time. Much has been made of George R. R. Martin's use of WordStar. At the time, plenty of people liked it, so I don't think we can dismiss his fondness for it as entirely due to Martin being a curmudgeon or a weirdo. Plenty of people liked WordPerfect as well. I myself use Neovim, which owes a lot to Vim, which came out in 1991. Vim in turn owes a lot to Vi, which came out in 1976. I certainly like Vim, so I definitely believe good software was made during this time.
On the other hand, perhaps I'm overstating the extent to which people couldn't trade performance for other nice features. People still programmed in BASIC, which was much slower, yet people used it for learning and even for useful programs. People also wrote shell scripts, which I suspect were genuinely significantly slower at the time due to the cost of initiating a new process and other overheads that aren't as noticeable now.
And of course, like I said in that prior post, describing the 80s or 90s as an era of "quality" is a bit dubious. Crashes and blue screens were pretty common. I don't have hard numbers on their frequency, but it's pretty clear they're less common now, even if they should be even less frequent. Certainly there were things to like about the era: bad design trends (or bad application of design trends) hadn't undermined the UI by reducing contrast and eliminating useful affordance, software subscriptions were unheard of, and there was a lot less telemetry.
Perhaps you could make a case for the 00s. In fact, after writing all that about the 80s and 90s, I realize maybe he really does mean the 00s, as that would sort of line up with his complaints about dynamic languages, which were taking off in a big way then. Reiterating that earlier post, it had the benefit of technologies that made operating systems much more stable and a reasonably healthy web while mostly predating a lot of trends people rightly criticize. However, there were certainly people complaining about programs being too large and complicated then. Java essentially played the role of Electron, and similarly to critics of Electron today, I think critics of Java had a mix of good and bad points. I guess that could be named an era of software quality, but it seems like a relative term at best.
I also can't escape the sense that the "era" wasn't some sort of stable point that was disrupted or a uniformly golden kingdom ruined by programmers losing the old ways but was just kind of a fortuitous coinciding of different trends. And although I'm trying my best to broaden the view and get beyond whatever nostalgia or other biases, this all feels pretty imprecise.
But I'd really object to this is that this isn't really true of current software on my computer writ large. Glancing at the programs I happen to have open right now in my sidebar, I think the only one that feels clearly like it's "wiping out the last 10-20 years of hardware evolution" is Teams, and honestly part of that might be less its actual performance than my other frustrations with it. Firefox is also a contender, although that gets into the question of how much to blame the browser rather than the webpages in the browser. I guess there's something to claiming the web wipes out years of hardware evolution, regardless of how you assign blame—certainly there are trivial websites that bog down computers and websites that would benefit from a lot less JavaScript. I should also note that while my current slate of apps are using more memory than I'd prefer (roughly 10 to 11 gigabytes as I've sporadically checked free -h while writing), they're pretty light on the CPU, my computer's not actually swapping, and I don't think the programs are doing anything crazy with disk I/O either. I might use more desktop apps and fewer Electron apps than the average person in 2025, but none of these example applications I use have stopped getting updates. I'm not running an all-suckless userspace or a bunch of abandonware or anything.
Curiously, the author isn't too negative about dynamic languages per se, especially Python, but does seem to be pretty negative about dynamic language programmers. If I had to guess, he seems to treat the languages as good tools for their niches, which is a healthy attitude. His statements about the programmers feel pretty disparaging, which is not a healthy attitude. E.g.,
Suddenly programmers were being encouraged to pretend they knew nothing about the hardware their program was destined to run on. Just assume that resources are abundant, that their allocation and deallocation was practically free, and if things started getting sluggish they could just ask management for more servers.
I've definitely seen people suggest a simplistic version of "hardware is cheaper than programmers, don't worry about it!" And similarly, people sometimes present Donald Knuth's adage about premature optimization as though optimization should always happen at the very end or that is worthless 99 percent of the time. But honestly, for some problems, this not-great advice is...actually okay. If you're banging out CRUD routes that hit the database a handful of times, especially if they're not foundational things the user must do (like log in) or the user does frequently, your optimization is likely to be premature and not worth the programmer cost.
My thresholds might not be quite right—I don't have the magic formula for how much you should care about performance. Certainly I've messed this up and written code that could have been faster or less resource-intensive. My point is that we shouldn't treat exhortations to care a little bit less about performance or tools that let you think a little less about hardware as tantamount to advocating for total ignorance.
I mean, people didn't say "Python is fast enough" because they're dumbasses or want to advocate ignorance. They said it because Python is fast enough for a lot of things. I'm sure plenty of people did give versions of this advice without sufficient context or nuance, as people caught up in hype cycles tend to do. Certainly that's a valid criticism of someone like Bob Martin, whose writing, as far as I have read, is a mixture of straight-up bad advice and good advice ruined by being canonized into inflexible rules.
It's fine to vent, of course, and there's plenty to vent about in computing today. But I think if your language advocacy is so rooted in a negative view, especially if the negativity seems overbroad or exaggerated, the community you will build around the language risks not being much fun to be in.