The world could run on older hardware if software optimization was a priority

Really no notes on this. Carmack hit both sides of the coin:

- the way we do industry-scale computing right now tends to leave a lot of opportunity on the table because we decouple, interpret, and de-integrate where things would be faster and take less space if we coupled, compiled, and made monoliths

- we do things that way because it's easier to innovate, tweak, test, and pivot on decoupled systems that isolate the impact of change and give us ample signal about their internal state to debug and understand them

> You are comparing applications with wildly different features and UI. That's neither an argument for nor against performance as an important quality metric.

I never said performance wasn't an important quality metric, just that it's not the only quality metric. If a slow program has the features I need and a fast program doesn't, the slow program is going to be "higher quality" in my mind.

> How fast you can compile, start and execute some particular code matters. The experience of using a program that performs well if you use it daily matters.

Like any other feature, whether or not performance is important depends on the user and context. Chrome being faster than IE8 at general browsing (rendering pages, opening tabs) was very noticeable. uv/ruff being faster than pip/poetry is important because of how the tools integrate into performance-sensitive development workflows. Does Slack taking 5-10 seconds to load on startup matter? -- to me not really, because I have it come up on boot and forget about it until my next system update forced reboot. Do I use LibreOffice or Word and Excel, even though LibreOffice is faster? -- I use Word/Excel because I've run into annoying compatibility issues enough times with LO to not bother. LibreOffice could reduce their startup and file load times to 10 picoseconds and I would still use MS Office, because I just want my damn documents to keep the same formatting my colleagues using MS Office set on their Windows computers.

Now of course I would love the best of all worlds; programs to be fast and have all the functionality I want! In reality, though, companies can't afford to build every feature, performance included, and need to pick and choose what's important.

Your post seems entirely anachronistic.

2007 is the year we did get video streaming services: https://en.wikipedia.org/wiki/BBC_iPlayer

Steam was selling games, even third party ones, for years by 2007.

I'm not sure what a "VS-Code style IDE" is, but I absolutely did appreciate Visual Studio ( and VB6! ) prior to 2007.

2007 was in fact the peak of TomTom's profit, although GPS navigation isn't really the same as general purpose mapping application.

Grocery delivery was well established, Tesco were doing that in 1996. And the idea of takeaways not doing delivery is laughable, every establishment had their own delivery people.

Yes, there are some things on that list that didn't exist, but the top half of your list is dominated by things that were well established by 2007.

>Anyway, five seconds is long for a text editor; 10, 15 years ago, sublime text loaded and opened up a file in Do any of those do the indexing that cause the slowness? If not it's comparing apples to oranges.

> the market buys bug-filled, inefficient software about as well as it buys pristine software

In fact, the realization is that the market buy support.

And that includes google and other companies that lack much of human support.

This is the key.

Support is manifested in many ways:

* There is information about it (docs, videos, blogs, ...)

* There is people that help me ('look ma, this is how you use google')

* There is support for the thing I use ('OS, Browser, Formats, ...')

* And for my way of working ('Excel let me do any app there...')

* And finally, actual people (that is the #1 thing that keep alive even the worst ERP on earth). This also includes marketing, sales people, etc. This are signal of having support even if is not exactly the best. If I go to enterprise and only have engineers that will be a bad signal, because well, developers then to be terrible at other stuff and the other stuff is support that matters.

If you have a good product, but there is not support, is dead.

And if you wanna fight a worse product, is smart to reduce the need to support for ('bugs, performance issues, platforms, ...') for YOUR TEAM because you wanna reduce YOUR COSTS but you NEED to add support in other dimensions!

The easiest for a small team, is just add humans (that is the MOST scarce source of support). After that, it need to be creative.

(also, this means you need to communicate your advantages well, because there is people that value some kind of support more than others 'have the code vs propietary' is a good example. A lot prefer the proprietary with support more than the code, I mean)