I'm pretty sure it has to do with comments like these:
Yes, you CS PhDs who secretly wish you were math PhDs wouldn't be able to write toy programs with infinite lists, but that's a small price to pay for lowering the language's skyscraper-steep learning curve and giving it predictable, easily reasoned-about performance characteristics.
Instead of Evil Haskell Conspiracy shutting down your criticism.
He's right though. Real programs run on real hardware, that has inherent limitations, that have to be reflected in the programming language somehow. Law of leaky abstractions and all that.
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.
Hmm ... let's not get carried away here. The abstraction leaks in Haskell seem to me to be of an order of magnitude less significant than in, say, Python or C++, but Haskell still has them (especially around _|_ and performance).
Idris already demonstrates that you don't have to have Haskell's ⊥ issues or its space leak issues. Idris may still have some leaks (or may not; I can't think of any), but the so-called law, "All non-trivial abstractions, to some degree, are leaky", is out-and-out false.
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.
Comments
I'm pretty sure it has to do with comments like these:
Instead of Evil Haskell Conspiracy shutting down your criticism.
He's right though. Real programs run on real hardware, that has inherent limitations, that have to be reflected in the programming language somehow. Law of leaky abstractions and all that.
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.
I really like this distinction!
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.
Hmm ... let's not get carried away here. The abstraction leaks in Haskell seem to me to be of an order of magnitude less significant than in, say, Python or C++, but Haskell still has them (especially around _|_ and performance).
Idris already demonstrates that you don't have to have Haskell's ⊥ issues or its space leak issues. Idris may still have some leaks (or may not; I can't think of any), but the so-called law, "All non-trivial abstractions, to some degree, are leaky", is out-and-out false.
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.