> I remember using a computer with RAM measured in two-digit amounts of MiB

Yes, so do I. It was limited to 800x600x16 color mode or 320x200x256. A significant amount of memory gets consumed by graphical assets, especially in web browsers which tend to keep uncompressed copies of images around so they can blit them into position.

But a lot is wasted, often by routing things through single bottlenecks in the whole system. Antivirus programs. Global locks. Syncing to the filesystem at the wrong granularity. And so on.

FWIW a two digit amount of MB is usually at least 16MB (though with low hundreds of MHz it was probably at least 32MB if not 64MB) and most such systems could easily do 1024x768 at 16bit, 24bit or 32bit color. At least my mid-90s PC could :-P (24bit color specifically, i had some slow Cirrus Logic adapter that stored the framebuffer in triplets of R,G,B, probably to save RAM but at the cost of performance).

Next time you someone on HN blithely post "CPU / RAM is cheaper than developer time", it's them. That is the sort of coder who are collectively wasting our CPU and RAM.

Even an editor running under Inferno plus Inferno itself would be lighter than the current editors by large. And that with the VM being weighted on. And Limbo it's a somewhat high level language...

If you ran a business, would you rather your devs work on feature X that could bring in Y revenue, or spend that same time reducing CPU/RAM/storage utilization by Z% and gives the benefit of ???

There is probably some low hanging fruit to be harvested in terms of memory optimizations, and it could be a selling point for the next while as the memory shortage persists

You work on both. Sometimes you need to prioritize one, sometimes the other. And the benefit of the second option is "it makes our product higher quality, both because that is our work ethic but also because our customers will appreciate a quality product".

The business is only going to care about the bottom line. If it's not slow enough to cause business problems, they are not going to say "here's a week to make software faster"

Likewise engineers are only going to care about doing their job. If the business doesn't reward them from taking on optimization work, why would they do it?

This is not true of all engineers and all businesses. Some businesses really do 'get it' and will allow engineers to work on things that don't directly help stated goals. Some engineers are intrinsically motivated and will choose to work on things despite that work not helping their career.

What I'm really getting is, yes, engineers choose "slower" technologies (e.g. electron, React) because there are other benefits, e.g. being able to get work done faster. This is a completely rational choice even if it does lead to "waste" and poor performance.

I agree with this. What you focus on depends on the circumstances. I believe PaulG likes to say that premature optimization is the root of all evil. Early on, you’re trying to ship and get a functioning product out the door — if spending a bit of money on extra RAM at that time helps you, it’s worth it. Over time, as you are trying to optimize, it makes sense to think more about memory management, etc.

That is why we have slow, bloated software. The companies that create the software do not have to pay any of the operational costs to run it.

If you have to buy extra RAM or pay unnecessary electrical or cooling expenses because the code is bad; it's not their problem. There is no software equivalent to MPG measurements for cars where efficient engine designs are rewarded at the time of purchase.

Why not both ?

Because time, effort, and attention are all finite

I too wonder that. And it is true on an OS level as well. The only worthwhile change in desktop environments since the early 2000s has been search as you type launchers. Other than that I would happily use something equivalent to Windows XP or (more likely) Linux with KDE 3. It seems everything else since then has mostly been bloat and stylistic design changes. The latter being a waste of time in my opinion.

Of course, some software other than desktop environments have seen important innovation, such as LSPs in IDEs which allows avoiding every IDE implementing support for every language. And SSDs were truly revolutionary in hardware, in making computers feel faster. Modern GPUs can push a lot more advanced graphics as well in games. And so on. My point above was just about your basic desktop environment. Unless you use a tiling window manager (which I tried but never liked) nothing much has happened for a very long time. So just leave it alone please.

>The only worthwhile change in desktop environments since the early 2000s has been search as you type launchers.

Add to that: unicode handling, support for bigger displays, mixed-DPI, networking and device discovery is much less of a faff, sound mixing is better, power management and sleep modes much improved. And some other things I'm forgetting.

There are some people who would exclude all of those an enhancements because they don't care about them (yes, even Unicode, I've seen some people on here argue against supporting anything other than ASCII)

Unicode is a fair point, I do speak a language that has a couple of letters that are affected. And of course many many more people across the world are way more affected by that. I didn't really consider that part of the desktop environment though, but I could see the argument for why it might (the file manager for example will need to deal with it, as would translations in the menus etc).

I was primarily thinking about enhancements in the user interactions. Things you see on a day to day basis. You really don't see if you use unicode, ASCII, ISO-somenumbers, ShiftJIS etc (except when transferring information between systems).

That's me. 1 byte ASCII is all that's needed for text.

Work expands to fill the available time. This applies to CPU time just as it does to project management.