
Analyzing Three Space Leaks in Haskell - okasaki
http://neilmitchell.blogspot.com/2015/09/three-space-leaks.html
======
maxander
This sort of problem is Haskell's downfall, and very nearly negates all the
other wonderful features of the language. It doesn't matter how fun it was to
write or how the type system promised you up and down it was correct- if your
program is taking up 20Gb of memory to run in simple cases it's going nowhere.
And as this post shows, solving such problems is easily as laborious a process
as tracking down memory leaks or buffer overflows in C; in these cases nearly
all of Haskell's great and powerful abstractions are working _against_ you.

The guys behind Haskell are utterly brilliant and seem to come up with
profound new programming concepts on a regular basis, so I'm surprised they've
not introduced fundamental features to solve or mitigate this problem. Until
they do most people are going to be too scared to use Haskell for serious
projects.

~~~
yokohummer7
> I'm surprised they've not introduced fundamental features to solve or
> mitigate this problem.

The problem is, to completely solve space leaks, Haskell should abandon
pervasive laziness. But laziness is sold as one of the best things about
Haskell, and most Haskellers _do_ love laziness because it improves
composability.

I myself _hate_ pervasive laziness, and I'm all for removing it from the
language. Unfortunately this argument will fail to convince most Haskellers
because they're already sold on the bright sides of pervasive laziness.

Ok, this is all good, but from here there's one really annoying aspect of the
Haskell community. They try to twist the reality to convince _themselves_. The
typical reaction when these kinds of arguments are brought on the Haskell
community is "space leaks are actually rare in the real world applications".
Yes, this is the saying from the very community that emphasizes on program
correctness. Sure, buffer overflow and memory leaks also rarely happen in
other languages? Isn't "exact resource usage" also a part of correctness? At
least in a broader sense?

Even SPJ (one of the designers of the language) admits laziness should retire
now (it was a good experiment to develop purely functional ways, but now the
disadvantages outweigh the advantages), but most Haskellers will never agree
with this because laziness does also have advantages, and they love it. I
actually gave up waiting for the Haskell community to abandon pervasive
laziness, so just moved to other languages.

Sometimes I get a sense that many Haskellers treat hardware as merely
implementation details.

~~~
chriswarbo
> I actually gave up waiting for the Haskell community to abandon pervasive
> laziness, so just moved to other languages.

I certainly wouldn't hold my breath for Haskell abandoning pervasive laziness.
It's a core principle of the language (Haskell is, after all, "being lazy with
class"); if it were removed, the result would be Haskell in name only.

If you don't want pervasive laziness then using a different language is
absolutely the correct thing to do. That's not a bad thing; it's just a case
of having different tools for different jobs. Haskell may be the best fit for
some projects but not others.

~~~
LukeHoersten
Completely agree. Laziness has too many benefits not to justify the added
complexity of thunks and thunk-based space leaks. If you don't agree, don't
use Haskell =)

------
tempodox
What, by All That Is Curried, is a space leak?

~~~
the_af
As someone else already posted, here is a more detailed explanation:
[https://queue.acm.org/detail.cfm?id=2538488](https://queue.acm.org/detail.cfm?id=2538488)

------
lolo_
A quick google suggests space leak == memory leak, is that correct?

~~~
okasaki
Usually, a space leak is an abnormal/unexpected amount of unevaluated data in
a lazy language. A memory leak is data in the process heap that isn't
referenced by the process.

