I agree. The flip side of that is that real programs are written by real humans, who have inherent limitations, that have to be reflected in the programming language somehow. ;)

Haskell certainly leans more toward the "cater to the limitations of humans" end rather than the "cater to the limitations of the machine" end, which is already filled by a whole host of languages like C++, Ada, Rust, D and others.

The "law" of leaky abstractions is bollocks. Haskell, Idris and the like demonstrate this quite thoroughly, by offering abstractions that you can only implement if you provide proof that your implementation satisfies the assumptions of the abstraction.

I'm broadly in agreement with a lot of haskeldownvot5's views (if not his tone); I think laziness is, with the benefit of hindsight, a mistake. But it's not a case of ivory-tower PhDs forgetting that programs run on real hardware; if anything it's the opposite, an assumption that our tools and reasoning would not be powerful enough to allow us to efficiently manage computation explicitly.

I think SQL is a far leakier language than Haskell in terms of the correlation between code and performance, but it seems to have achieved a measure of success even in situations where performance is critical.