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

Not everyone wants the cheapest, but lemons fail and collapse the expensive part of the market with superior goods.

To borrow your example, it's as if Mercedes started giving every 4th customer a Lada instead (after the papers are signed). The expensive Mercedes market would quickly no longer meet the luxury demand of wealthy buyers and collapse. Not the least because Mercedes would start showing super-normal profits, and all other luxury brands would get in on the same business model. It's a race to the bottom. When one seller decreases the quality, so must others. Otherwise, they'll soon be bought out, and that's the best-case scenario compared to being outcompeted.

There is some evidence that the expensive software market has collapsed. In the 00s and 90s, we used to have expensive and cheap video games, expensive and cheap video editing software, and expensive and cheap office suites. Now, we have homogeneous software in every niche — similar features and similar (relatively cheap) prices. AAA game companies attempting to raise their prices back to 90s levels (which would make a AAA game $170+ in today's money) simply cannot operate in the expensive software market. First, there was consumer distrust due to broken software, then there were no more consumers in that expensive-end market segment.

Hardware you mention (iPhones, Androids, Macs, PCs) still have superior and inferior hardware options. Both ends of the market exist. The same applies to most consumer goods - groceries, clothes, shoes, jewelry, cars, fuel, etc. However, for software, the top end of the market is now non-existent. It's gone the way of expensive secondary market (resale) cars, thanks to how those with hidden defects undercut their price and destroyed consumer trust.

Rendering a volume slider or some icons shouldn't take half a second, regardless. e.g. speaking of Carmack, Wolfenstein: Enemy Territory hits a consistent 333 FPS (the max the limiter allows) on my 9 year old computer. That's 3 ms/full frame for a 3d shooter that's doing considerably more work than a vector wifi icon.

Also, you could keep the status accurate because it only needs to update on change events anyway, events that happen on "human time" (e.g. you plugged in headphones or moved to a new network location) last for a practical eternity in computer time, and your pre-loaded icon probably takes a couple kB of memory.

It seems absurd to me that almost any UI should fail to hit your monitor's refresh rate as its limiting factor in responsiveness. The only things that make sense for my computer to show its age are photo and video editing with 50 MB RAW photos and 120 MB/s (bytes, not bits) video off my camera.

Your original comment was saying you have to give up features and development speed to have faster software. I've seen this claim before many times, but it's always from people rationalizing not learning anything beyond the scripting languages they learned when they got in to programming.

I explained to you exactly why this is true, and it's because writing fast software just means doing some things slightly differently with a basic awareness of what makes programs fast, not because it is difficult or time consuming. Most egregiously bad software is probably not even due to optimization basics but from recomputing huge amounts of unnecessary results over and over.

What you said back is claims but zero evidence or explanation of anything. You keep talking about assembly language, but it has nothing to do with getting huge improvements for no time investment, because things like instruction count are not where the vast majority of speed improvements come from.

I mean, you’re the one who started this off with the insane claim that there’s no tradeoff, then claimed there are no optimizations available below C++ (i.e. C++ is the absolute most optimized code a person can write).

This is a hallucination that has nothing to do with your original point. The vast majority of software could be sped up 100x to 1000x easily if they were written slightly different. Asm optimizations are extremely niche with modern CPUs and compilers and the gains are minuscule compared to C++ that is already done right. This is an idea that permeates through inexperienced programmers, that asm is some sort of necessity for software that runs faster than scripting languages.

Go ahead and show me what specifically you are talking about with C++, assembly or any systems language or optimization.

Show me where writing slow software saves someone so much time, show me any actual evidence or explanation of this claim.

The explicit annotation on people is there for illustration. In real code it can be inferred from whatever the expression is (as the other lines are).

I don't think it's reasonable to specify the time complexity of insert/delete/lookup. For one, joins quickly make you care about multi-column indices and the precise order things are in and the exact queries you want to perform. e.g. if you join A with B, are your results sorted such that you can do a streaming join with C in the same order? This could be different for different code paths. Simply adding indices also adds maintenance overhead to each operation, which doesn't affect (what people usually mean by) the time complexity (it scales with number of indices, not dataset size), but is nonetheless important for real-world performance. Adding and dropping indexes on the fly can also be quite expensive if your dataset size is large enough to care about performance.

That all said, you could probably get at what you mean by just specifying indices instead of complexity and treating an embedded sqlite table as a native mutable collection type with methods to create/drop indices and join with other tables. You could create the table in the constructor (maybe using Object.hash() for the name or otherwise anonymously naming it?) and drop it in the finalizer. Seems pretty doable in a clean way in Scala. In some sense, the query builders are almost doing this, but they tend to make you call `run` to go from statement to result instead of implicitly always using sqlite.