No, it's really not even arguable. Lots and lots of software is written in business contexts where the cost of developing reliable code is a lot more important than its performance. Not everything is a commercial product aimed at a wide audience.

What you're "sick of" is mostly irrelevant unless you represent a market that is willing to pay more for a more efficient product. I use commercial apps every day that clearly could work a lot better than they do. But... would I pay a lot for that? No. They are too small a factor in my workday.

Saving money is part of engineering too.

People have been sick of slow programs and slow computers since literally forever. I think you live in a bubble or are complacent.

No one I know has anything good to say about microsoft teams, for instance. And that's just one of the recent "dekstop apps" which are actually framed browsers.

> I for one am sick of 'developer productivity' being the excuse for why my goddamned supercomputer crawls when performing tasks that were trivial even on hardware 15 years older.

The problem here is developer salaries. So long as developers are as expensive as they are the incentive will be to optimise for developer productivity over runtime efficiency.

We've been making developer experience optimizations _long_ before they started demanding high salaries. The whole reason to go from assembly to C was to improve developer experience and efficiency.

It seems fairly reductive to dismiss the legitimate advantages of increased productivity. It's faster to iterate on ideas and products, we gain back time to focus on more complex concepts, and, more broadly, we further open up this field to more and more people. And those folks can then go on to invest in these kind of performance improvements.

> It seems fairly reductive to dismiss the legitimate advantages of increased productivity.

Certainly there are some, but I think we passed the point of diminishing returns long long ago and we're now well into the territory of regression. I would argue that we are actually experiencing negative productivity increases from a lot of the abstractions we employ, because we've built up giant abstraction stacks where each new abstraction has new leaks to deal with and everything is much more complicated than it needs to be because of it.

Hmm... I think our standards for application functionality are also a lot higher. For example, how many applications from the 90s dealt flawlessly with unicode text.

How much added slowness do you think Unicode is responsible for? Because as much of a complex nightmarish standard as it is[0], there are plenty of applications that are fast that handle it just fine as far as I can tell. They're built with native widgets and written in (probably) C.

[0] plenty of slow as fuck modern software doesn't handle it even close to 'flawlessly'

If developers costed one fifth of what they do now, how many projects that let performance languish today would staff up to the extent that doing a perf pass would make it's way to the top of the backlog queue?

Come on now. Let's be honest here. The answer for >90% of projects is either a faster pace on new features, or to pocket the payroll savings. They'd never prioritize something that they've already determined can be ignored.

Hmm, I don’t know about that. When I made a quarter of what I do now, I worked at companies that would happily let me spend two weeks on a task without expecting much in that time.

CPU intensive tasks are highly optimized already.

As far as I can tell, a slow computer is due to swapping from having a bunch of stuff open, or an inherently heavy background task and an OS that doesn't know how to allocate resources.

Sometimes there's some kind of network access bogging everything down, now that SASS is everywhere(In which case, we need more abstractions and developer productivity to enable offline work!).

Sometimes things are slow because we are doing a lot of heavy media processing. That's not inefficiency, it's just inherently heavy work. In fact, simplicity might actively slow things even more, because what you really need for that stuff is to use the GPU, and the "bloated mega library" you're avoiding might already do that.

Android is kind of the proof. Android is always pretty fast. Anything 15yo hardware could do trivially, Android can probably do faster. And Android is not lightweight.

There may be some slowness out there caused by abstraction layers, but as far as I can tell without digging into the code of every slow app I've ever seen, the real problem is the keep it simple mindset that discourages even basic optimization tricks like caching, and the NIH that makes people write things themselves and assume it's faster just because it's smaller.

Plus, the UNIXy pipeline mentality that did a number on computing. GUI workflows are not pipelines and there's lots of things that are very messy to do in a pipe style model, like changing one thing and selectively recomputing only what needs changing.

The "Data processing" way of thinking leads to producing a batch of stuff, then passing it to something that computes with it, instead of working directly with a state.

> when performing tasks that were trivial even on hardware 15 years older.

Did the software to perform those tasks stop working?