I think this has more to do with management timeline expectations and income valuation than software development. I do understand that they're almost inseparable, as software has to make money. But, timelines need to take into account the "craft" of software creation and not just the desk hours, for lack of better terms =/ Short timelines and quick turn arounds don't leave time for refactoring and quality code creation. First passes tend to be the final draft, more often then not.

This issue however, exists in more than just commercial software. Personal example, OSes feel bloated, I switched from BigSur to Mojave in my 2018MBPro and I saw significant improvements in responsiveness with virtually no change in usage behavior. Even software whose supposed features are stability and speed feel bloated, e.g. weird bugs in Unity, photoshop is sluggish without any significant increase in the visible features.

It makes sense though, the cost of hardware per performance has nosedove, whereas the cost of human labor has probably gone up? Why pay devs to write fast code when you can buy faster computers faster and cheaper?

I wonder when the trend reverses. It must, at some point, mustn't it?

> Why pay devs to write fast code when you can buy faster computers faster and cheaper?

Because you can do more in the same time. Speed and responsiveness are features, the issue is, the general population has come to accept that bugs are not only acceptable, but just that, 'bugs' that you can shoo away by restarting the machine/program.

> I wonder when the trend reverses. It must, at some point, mustn't it?

I hope so. As we have seen with spectre and now AMD's equivalent, speculative execution is risky and very complex to get right. We can't rely on ever increasing complexity on CPUs and fabrication processes, at some point quantum mechanics will bite back.

Your experience of using Haskell is that it causes more bugs than less abstract languages?

No, on the contrary, my experience with Haskell is that my code is mostly bug free, but ends up less performant because you can accidentally create huge trunks in the heap and it consumes too much mental stamina.

However, there exists an intermediate plane of abstraction over C and under Haskell that is absolutely horrendous and results in all sorts of weird bugs and unpredictable situations.

I've heard people say that Haskell would be better with eager rather than lazy evaluation, because of the mental burden that it causes. IMO that doesn't seem like a hard problem to solve. We can design pure functional languages with eager evaluation.

Haskell would be better if it used polarity and focusing to make both strict and lazy evaluation first-class citizens in the language. A stricrly-evaluated counterpart to Haskell is just ML, which we've had since the 1970s.

I've coded in OCaml, which wasn't pure immutable, but rather immutable by default. Because it has mutability, that removes the focus on immutable data structures, making it a very different language.

You can make any module strict by using the XStrict language pragma in Haskell.

What about Rust?

It solves memory problems and certainly doesn't shoot your foot with destructors, weird moves and so on like C++, it lacks a garbage collector which imho is a big plus (though, as C# and Java show it is not necessarily a big problem), and I prefer the trait system over than Cxx's virtual classes/interfaces. I also like that the compiler is very helpful, it introduces some friction while writing, but I suppose that is my lack of expertise.