> We spent a lot of time these last 40–50 years chasing performance above all else, prioritising it before safety, expressiveness & development time.

I'm not sure I agree with this assessment. Certainly some developers have been targeting performance (particularly compiler devs. Arguably UI devs). However, in corporate development, performance has ALWAYS come second to development time. The only time performance matters is.. well, when it does :). That is to say, it only matters when slow things are causing unhappy clients or missed deadlines.

> Certainly some developers have been targeting performance (particularly compiler devs. Arguably UI devs)

Difficult to believe with how unresponsive modern UIs are.

We make the UIs responsive, and then we come up with a new way to make them slow.

Performance was critical to all projects 25 years ago when software had to run on a 100 MHz CPU with 16 MB of memory.

FWIW, Apple's Power Macintosh 8500, released 25 years ago tomorrow, started at 120MHz & 16MB RAM, but went up to 200MHz & 512MB RAM.

As I recall, it was pretty snappy! I think it would still have been sufficiently snappy had its OS been written in Smalltalk or Lisp …

BeOS on a 166Mhz Pentium with 128MB of RAM (luxury!) felt positively spacious. Like you were lavishing it with far more resources than it needed and so rarely risked even approaching its limits, so far as maintaining UI responsiveness while multitasking, at least.

> We spent a lot of time these last 40–50 years chasing performance above all else, prioritising it before safety, expressiveness & development time.

I would agree with this for operating systems, but I just don't see this being true for application development. I am thinking Electron and deep levels of abstraction introduced by the Web.

I don't think it's at all true that major consumer operating systems have chased performance as even a mid-tier priority for ~25 years, at least. The only major counterexample I can think of is iOS. OSX/macOS probably does the best job as far as desktop operating systems, but even it has long stretches where it just gets worse. KDE and Gnome desktops haven't been particularly good compared to contemporaries in the 20ish years I've been using them off-and-on (though KDE's gotten back to non-terrible territory, at least). Chasing performance on the desktop, for a user, largely means "regressing" to older or older-style software and abandoning the mainstream. The full-featured modern stuff, despite not really doing that much more than the older stuff, is far heavier and slower.

What I was getting at can be reduced to a single word — a single letter, even: C. The fact that any software is written in C (or C++) is IMHO sufficient proof that the developers care more about performance than they do about anything else.

I think that still holds even if they demonstrably do not care about performance all that much! You are quite right: current software is heavier and slower than it used to be and than it needs to be; it is also less safe and is more difficult to develop than it needs to be.

The popularity of things like Java or JavaScript is another disfunction: although they are very different from one another, they are similar in that they have poor syntax, frighteningly bad ergonomics and poor semantics. They require too much boilerplate (in very different ways) and are insufficiently expressive and powerful. They are not even as much safer as they should be, given their memory safety!

Our industry is appallingly immature.

Operating systems in the sense of kernels might still be focused on performance, but the whole GUI layer of every major OS (maybe except macOS, which might explain why most of its utility programs are still so snappy and nice to use relative to much of the competition) is full of virtual-machine languages, scripting languages, and so on. Look at Gnome—they've wrecked their performance in no small part (so far as I can tell) by integrating JavaScript so heavily into the shell, and show no signs of reversing course. The parts of the OS typical users directly interact with, and its basic GUI utility programs, are increasingly not written in C, C++, or similarly high-performance languages with tight memory and performance control, but VM languages, languages with (relatively) big, heavy runtimes, and interpreted langs.

It's bad that so many applications have given up on even halfway caring about respecting the user's computing resources, but IMO it's much worse if you can't even boot to your damn GUI desktop without a pile of JavaScript being loaded into memory.

JavaScript delenda est. It is to the 2010s as Java was to the 2000s and C was to the 1990s: unjustly popular, and a step backwards from better, deployable technologies. Its deep design flaws are obscured by its superficial design flaws.

Choosing JavaScript is a very different mistake than choosing C (it is at least memory safe, which counts for something). But it is deeply disheartening to imagine how many man-centuries (or man-millennia?) of work have gone into the ramshackle apparatus which is the JavaScript ecosystem while better ecosystems wither and starve for lack of involvement.

JavaScript delenda est.

No, the modern computers aren't that fast. Try running a BFS over a large matrix in python and then in cpp. You'll understand why perf matters. I realised this during one of my college assignments.

Also, it's because people think like this we have electron apps for things as simple as note taking.