[jefb]

From my experience most of your assertions have a hidden assumption that the software requirements are complete and they are good. Computing something 10000 times faster is useless if it turns out to be the wrong computation. Furthermore, things that run 10000 times faster than other things tend to be harder to adapt and change.

Requirements that are good enough to warrant a 5 second page load time being "unacceptable" must have, at some point, been prototyped with real use cases, real data, and in real environments.

Getting to that point - where the business case is connected with such a strong through-line to the user experience can literally take years. Early in a project lifecycle it's more important to design software that is easy to change than software that is fast.

Language choice does not matter, performance does not matter; the design philosophy of the developer(s) when building something new is everything. That philosophy should be "I'll likely have to change this" not "I need to make sure this runs quickly". Any high level design decisions should be made with the former in mind, not the latter.

Once you've earned that product wisdom, sure - carve out the slow thing and write it in CUDA or something. If things are easy to change, that's not a scary proposition; it's just part of the natural project lifecycle and Knuth lives to die another day.

[hsn915]

This is a false dichotomy.

"We either have perfect information or we make software that is very slow".

[jefb]

It is not an either/or situation - it's a maturation process. Make flexible slow software first, then optimize the parts that need to be fast.

Optimize iteration frequency of features not for loops.

[hsn915]

What I'm advocating here is not for optimized code. Only for non-pessimized by default code.

This kind of code does not tend to be rigid as you might imagine. Quite the opposite. Since it doesn't introduce a ton of premature abstractions and stays straight to the point, it tends to be flexible and easy to change/adapt.

You are still thinking in terms of a false dichotomy:

- Flexible but slow

- Fast but rigid

But it's a false dichotomy.

You don't need optimizations to get high performance software. Computers are very fast. You just need non-pessimized code.

It's funny. People use "computer are very fast" to dismiss all performance concerns. But this is not how we should think about it.

"Computer are very fast" means we don't need to optimize (as in micro-optimize on the instruction level) code to get high performance. We just need to get the clowns out of the car.

[jefb]

I think we're largely in agreement here e.g. I agree 100% that premature abstractions hold a lot of inertia. I'm just advocating for making decisions that optimize for "the right thing" over speed alone. In my experience the right thing tends to be adaptation, but that's because I do a lot of R&D work.

Sometimes yes, you can eat your cake and have it too w/r/t performance and flexibility; but the choice of programming language cannot be categorically relegated to "always pick the fastest one". There are no silver bullets, there will always be tradeoffs.

Flexibility matters, ecosystem matters, developer experience matters, third party libraries matter, good requirements (or lack thereof) matter, budget matters, timeline matters, security matters, and yes, performance also matters - it's just not the only consideration.

High level design decisions, language included, are not "pessimized by default" because they deem some of those other considerations more important than speed.