[lordCarbonFiber]

If 5MB of memory means swaping out to a floppy disk 30 years ago and 1GB usage doesn't today because your macbook has 32gb of ram the older program is still going to be slower. I think there's an important distinction between "modern programs could be faster" (which is unambiguously true) and "modern programs are slower than older programs or even analogue equivalents" which ends up often relying of invalid comparisons or rose colored glasses about what computing was like.

Often times what's being optimized for isn't even the speed of experience and maybe that's ok. Chrome spawns a million processes so if a tab crashes it doesn't end your browsing session, VS code being written in electron means writing plugins is a breeze and thus has built a thriving ecosystem in a record amount of time. If nothing else the world of software is a lot more flexible in 2020 than 1990 and maybe people prefer that to raw speed (given there's not a huge demand for native terminal based applications there's an argument to be made)

[jonhohle]

Has document writing or spreadsheet creation changed much since the 90s? Word and Excel 6 were significantly faster than current versions and were running on PCs with 8 or 16MB of RAM and, at least for my use cases, did effectively the same job they do today. In some cases they did it better.

How has document creation changed in two decades that justifies two orders of magnitude more RAM and CPU performance, 10x power draw, etc.?

If your house was built with 100x the resources and consumed that much more power, and it took longer to turn on the lights or cook a meal would it be justified because the building process was easier and you could add new light fixtures more easily? That would be lunacy, but for some reason we think it’s OK in software to avoid the craftsmanship the profession demands while treat users like fools who should just accept that computers are faster so their apps should be slower. It’s garbage reasoning. The ergonomics of developers should always come second to providing the best for customers.

[philipkglass]

It's hard to stay in business offering a product that touts "fewer features, but smaller memory footprint and snappier UI response" vs. its competitors. There are a few exceptions to this rule, but they are exceptional. That's why organizations pay for big, slow Slack instead of using fast, free, svelte IRC clients.

[jonhohle]

In other industries these are things that become commodities. They aren't thrown out and replaced with something new, the business move into a different phase (or shed that business to someone else willing to take the role).

[selectodude]

>10x power draw

I can run xlookup functions on a 1000 row excel spreadsheet on my cell phone.

[jonhohle]

Amazing, isn’t it? Yet somehow a 100w i9 is doing things at nearly the same perceived speed as a 10w Pentium.

[rplnt]

The random numbers were just that, random numbers. Startup times are noticeably slower. Even with fast SSDs, many multi-GB apps that run in background can get swapped out, and that's still slower than RAM decades ago.

> Chrome spawns a million processes so if a tab crashes it doesn't end your browsing session

This one is funny, because

1) before Chrome pages didn't seem to crash (js could, but not the whole "page")

2) Chrome still crashes completely loads of times

(also it's not really related; Chrome is a fast application written relatively effectively)

But I get your point, and you are not wrong. I just wouldn't discount "cheap development" to be the primary reason.