4 ms·

but it's not that different than what you'd get with other programming languages. Until you have to solve a (maddeningly common) space leak issue. That's a pr

but it's not that different than what you'd get with other programming languages. Until you have to solve a (maddeningly common) space leak issue. That's a problem unique to lazily evaluated languages (basically Haskell) and is godawful to debug. It reminds me of solving git problems... you suddenly find yourself having to tear back the abstraction layer that is the language and compiler and start thinking about thunks and so forth. It's jarring and incredibly frustrating.

platz 9y ago
here is a method that can help debug space leaks: http://neilmitchell.blogspot.com/2015/09/detecting-space-leaks.html http://neilmitchell.blogspot.com/2015/09/detecting-space-lea...
- zzalpha 9y ago
  I wish the problem was simply detecting and isolating space leaks. My experience is that actually fixing them can be incredibly difficult, hence my comment about needing to understand the gory details about how the runtime evaluates lazy expressions. Heck, that post even uses the phrase "Attempt to fix the space leak" as it's often not an obvious slam dunk. Sometimes it even devolves to peppering !'s around until the problem goes away.
  - dllthomas 9y ago
    > My experience is that actually fixing them can be incredibly difficult My experience differs, FWIW. If you know where you're creating too many thunks, and you force them as you create them, they don't accumulate. Making sure you actually are forcing them, and not simply suspending a "force this", is probably the trickiest bit until you're used to the evaluation model.
    - zzalpha 9y ago
      If you know where you're creating too many thunks, and you force them as you create them, they don't accumulate. Translation: if you've internalized the way Haskell code is compiled and executes, so that you can easily reason about how lazy evaluation is actually implemented, you can solve these problems. If not, it devolves to throwing !'s in and praying. Which is basically my point. If I don't have a hope of solving common space leaks without deeply understanding how Haskell is evaluated, that's a real challenge for anyone trying to learn the language.
      - theoh 9y ago
        This sounds a bit FUD-ish. Programming in any language involves understanding the evaluation strategy. You seem to be advocating languages that can be used with a level of ignorance or innocence which in practice just isn't possible. https://en.wikipedia.org/wiki/Evaluation_strategy https://en.wikipedia.org/wiki/Evaluation_strategy
        zzalpha 9y ago
        I disagree. I contend that most of the time folks ignore the evaluation strategy for eagerly evaluated languages because they're simply easier to reason about. That strikes me as objectively true on its face and I believe most Haskellers would concede that point. The only time I can think of where that's not the case is when microoptimizing for performance, where the exact instructions being produced and their impact on pipelining and cache behaviour matter. But that's in general far more rare than one encounters space leaks in idiomatic Haskell. Heck, one just needs to read about two of the most common Haskell functions to hit concerns about space leaks: foldl and foldr. It's just part of the way of life for a Haskeller. There's simply no analog that I can think of in the world of eagerly evaluated languages that a) requires as much in-depth knowledge of the language implementation, and b) is so commonly encountered. The closest thing I can come up with in a common, eager language might be space leaks in GC'd languages, but they're pretty rare unless you're doing something odd (e.g. keeping references to objects from a static variable).
        platz 9y ago
solidsalvia 9y ago
There is this really great paper about space leaks and arrows: https://pdfs.semanticscholar.org/cab9/4da6e4b88b01848747df8297fccf1ea6b35a.pdf https://pdfs.semanticscholar.org/cab9/4da6e4b88b01848747df82...
dllthomas 9y ago
> unique to lazily evaluated languages More precisely, unique to significant use of laziness, which is going to (obviously) be more common in lazily evaluated languages but laziness is supported elsewhere.
- deleted 9y ago
  [deleted]
codygman 9y ago
> Until you have to solve a (maddeningly common) space leak issue. Hm, I've been making useful things with Haskell for a couple years including quite a few freelance projects and haven't encountered many space leaks. Definitely not enough to say they are maddeningly common, or even enough to say they are common.
- dllthomas 9y ago
  My experience tracks yours.
eximius 9y ago
I find this response a little ironic because we don't really see complaints about knowing the C runtime and C compiler when performance becomes a problem, which is also jarring and frustrating. But, ultimately, sometimes languages have failings and we need to peek under the hood to figure out how to address it - we're just more comfortable with the relatively common and direct mapping of the C runtime. I am not experienced enough with Haskell to know whether peeking under its hood involves a more complicated model or not. It might be more frustrating. But its certainly not a unique experience - it's costs are just less distributed over other runtimes.
- restalis 9y ago
  "we're just more comfortable with the relatively common and direct mapping of the C runtime" That's a funny way to put it. It's more like the difference between getting results or abandoning the thing altogether due to exploding cost of required effort.
- user5994461 9y ago
  The C is very straightforward. Maybe you meant C++? You see no complaint because noone use that anymore. Anything that can be done with an easier language is done with an easier language. The hardcore C++ performance critical code is left to a few veterans, who don't complain.
  - eximius 9y ago
    I don't consider the combination of the C runtime + the machine model straightforward - just less arcane than C++. Consider pipelines and branch prediction and cache lines and it quickly becomes difficult. Granted, those typically become relevant later in the optimization stage than other things.
    - Veedrac 9y ago
      Pipelines, branch prediction and caching are not part of the C runtime. And unlike Haskell, C makes it easy to look at the assembly for a piece of code, evaluate it for the machine it's running on, and fix these problems when they come up. C is not generally adding additional burdens, especially not ones that a higher-level language like Haskell won't also be adding to a far greater degree.

platz 9y ago

here is a method that can help debug space leaks: http://neilmitchell.blogspot.com/2015/09/detecting-space-leaks.html http://neilmitchell.blogspot.com/2015/09/detecting-space-lea...

zzalpha 9y ago
I wish the problem was simply detecting and isolating space leaks. My experience is that actually fixing them can be incredibly difficult, hence my comment about needing to understand the gory details about how the runtime evaluates lazy expressions. Heck, that post even uses the phrase "Attempt to fix the space leak" as it's often not an obvious slam dunk. Sometimes it even devolves to peppering !'s around until the problem goes away.
- dllthomas 9y ago
  > My experience is that actually fixing them can be incredibly difficult My experience differs, FWIW. If you know where you're creating too many thunks, and you force them as you create them, they don't accumulate. Making sure you actually are forcing them, and not simply suspending a "force this", is probably the trickiest bit until you're used to the evaluation model.
  - zzalpha 9y ago
    If you know where you're creating too many thunks, and you force them as you create them, they don't accumulate. Translation: if you've internalized the way Haskell code is compiled and executes, so that you can easily reason about how lazy evaluation is actually implemented, you can solve these problems. If not, it devolves to throwing !'s in and praying. Which is basically my point. If I don't have a hope of solving common space leaks without deeply understanding how Haskell is evaluated, that's a real challenge for anyone trying to learn the language.
    - theoh 9y ago
      This sounds a bit FUD-ish. Programming in any language involves understanding the evaluation strategy. You seem to be advocating languages that can be used with a level of ignorance or innocence which in practice just isn't possible. https://en.wikipedia.org/wiki/Evaluation_strategy https://en.wikipedia.org/wiki/Evaluation_strategy
      - zzalpha 9y ago
        I disagree. I contend that most of the time folks ignore the evaluation strategy for eagerly evaluated languages because they're simply easier to reason about. That strikes me as objectively true on its face and I believe most Haskellers would concede that point. The only time I can think of where that's not the case is when microoptimizing for performance, where the exact instructions being produced and their impact on pipelining and cache behaviour matter. But that's in general far more rare than one encounters space leaks in idiomatic Haskell. Heck, one just needs to read about two of the most common Haskell functions to hit concerns about space leaks: foldl and foldr. It's just part of the way of life for a Haskeller. There's simply no analog that I can think of in the world of eagerly evaluated languages that a) requires as much in-depth knowledge of the language implementation, and b) is so commonly encountered. The closest thing I can come up with in a common, eager language might be space leaks in GC'd languages, but they're pretty rare unless you're doing something odd (e.g. keeping references to objects from a static variable).
        platz 9y ago

solidsalvia 9y ago

There is this really great paper about space leaks and arrows: https://pdfs.semanticscholar.org/cab9/4da6e4b88b01848747df8297fccf1ea6b35a.pdf https://pdfs.semanticscholar.org/cab9/4da6e4b88b01848747df82...

dllthomas 9y ago

> unique to lazily evaluated languages More precisely, unique to significant use of laziness, which is going to (obviously) be more common in lazily evaluated languages but laziness is supported elsewhere.

deleted 9y ago
[deleted]

codygman 9y ago

> Until you have to solve a (maddeningly common) space leak issue. Hm, I've been making useful things with Haskell for a couple years including quite a few freelance projects and haven't encountered many space leaks. Definitely not enough to say they are maddeningly common, or even enough to say they are common.

dllthomas 9y ago
My experience tracks yours.

eximius 9y ago

I find this response a little ironic because we don't really see complaints about knowing the C runtime and C compiler when performance becomes a problem, which is also jarring and frustrating. But, ultimately, sometimes languages have failings and we need to peek under the hood to figure out how to address it - we're just more comfortable with the relatively common and direct mapping of the C runtime. I am not experienced enough with Haskell to know whether peeking under its hood involves a more complicated model or not. It might be more frustrating. But its certainly not a unique experience - it's costs are just less distributed over other runtimes.

restalis 9y ago
"we're just more comfortable with the relatively common and direct mapping of the C runtime" That's a funny way to put it. It's more like the difference between getting results or abandoning the thing altogether due to exploding cost of required effort.
user5994461 9y ago
The C is very straightforward. Maybe you meant C++? You see no complaint because noone use that anymore. Anything that can be done with an easier language is done with an easier language. The hardcore C++ performance critical code is left to a few veterans, who don't complain.
- eximius 9y ago
  I don't consider the combination of the C runtime + the machine model straightforward - just less arcane than C++. Consider pipelines and branch prediction and cache lines and it quickly becomes difficult. Granted, those typically become relevant later in the optimization stage than other things.
  - Veedrac 9y ago
    Pipelines, branch prediction and caching are not part of the C runtime. And unlike Haskell, C makes it easy to look at the assembly for a piece of code, evaluate it for the machine it's running on, and fix these problems when they come up. C is not generally adding additional burdens, especially not ones that a higher-level language like Haskell won't also be adding to a far greater degree.