Also, it does no good to compare the best software of the past with the average or worst software of the present. We tend to forget the average software of the past, and I would guess that most of us weren't exposed to the worst of it.
Inefficient software has been a problem for practically all of the history of personal computing. I'll illustrate with two anecdotes:
I was in high school when Office 97 came out. I only have a vague memory of this, but I do remember one of my classmates complaining that it was sluggish on whatever computer he had at the time.
The first commercial product that I shipped, in 2002, was a desktop application written in Java (though, as shipped, it only ran on Windows). I didn't do most of the original development; it was developed by an outsourced development shop, and then I had to take over the project. Whether on my underpowered 366 MHz laptop or my boss's much more powerful machine, the app took considerable time to start up, so much so that we put in background music during some of the startup process (the app was a self-contained audio environment for blind people, so that was our equivalent of a splash screen). I never really dug into what caused the slow startup, but in hindsight, I would guess that it was the late-binding nature of Java, particularly the fact that classes had to be loaded individually as they were first used, often from multiple jar files, not to mention loading native code from multiple DLLs. The peanut gallery here may say the app should have been a statically linked native executable, but for all practical purposes, that would have meant C++, and if that had been a hard requirement, the app would never have shipped at all. And while we struggled to sell that particular app, it did have some happy users (indeed, for some of the target users that we did manage to reach, the app was positively life-changing in its impact), so I don't regret that we shipped it in its inefficient state. If the same app were developed today in Electron, with any decent build setup, I'm guessing it would be up and running in a few seconds.
Whether in the 90s, the 2000s, or today, most development teams have never had the resources to produce the highly optimized gems that we fondly remember from the past that we so often pine for. But the software that we do manage to ship is used and even enjoyed anyway. And, to bring this back to the original discussion, advances in hardware enable more under-resourced teams to ship more useful and enjoyable software that would otherwise not exist.
> for all practical purposes, that would have meant C++, and if that had been a hard requirement, the app would never have shipped at all.
This is a really good point. Slow software certainly has its place. Not everything needs to be as optimized as possible. I don't think that the loss of speculative execution would put us back so far in terms of performance that it would hurt slower languages like java or python, but I think it might encourage putting more effort into optimization and probably create more interest in lower level languages. It might even lead to new creative approaches to speeding things up. That said, I'd really rather processors stay fast if they can do it while still being secure.
Inefficient software has been a problem for practically all of the history of personal computing. I'll illustrate with two anecdotes:
I was in high school when Office 97 came out. I only have a vague memory of this, but I do remember one of my classmates complaining that it was sluggish on whatever computer he had at the time.
The first commercial product that I shipped, in 2002, was a desktop application written in Java (though, as shipped, it only ran on Windows). I didn't do most of the original development; it was developed by an outsourced development shop, and then I had to take over the project. Whether on my underpowered 366 MHz laptop or my boss's much more powerful machine, the app took considerable time to start up, so much so that we put in background music during some of the startup process (the app was a self-contained audio environment for blind people, so that was our equivalent of a splash screen). I never really dug into what caused the slow startup, but in hindsight, I would guess that it was the late-binding nature of Java, particularly the fact that classes had to be loaded individually as they were first used, often from multiple jar files, not to mention loading native code from multiple DLLs. The peanut gallery here may say the app should have been a statically linked native executable, but for all practical purposes, that would have meant C++, and if that had been a hard requirement, the app would never have shipped at all. And while we struggled to sell that particular app, it did have some happy users (indeed, for some of the target users that we did manage to reach, the app was positively life-changing in its impact), so I don't regret that we shipped it in its inefficient state. If the same app were developed today in Electron, with any decent build setup, I'm guessing it would be up and running in a few seconds.
Whether in the 90s, the 2000s, or today, most development teams have never had the resources to produce the highly optimized gems that we fondly remember from the past that we so often pine for. But the software that we do manage to ship is used and even enjoyed anyway. And, to bring this back to the original discussion, advances in hardware enable more under-resourced teams to ship more useful and enjoyable software that would otherwise not exist.