7 ms·

>Haskell's laziness makes slow code and code that use up a lot of memory hard to locate, and at times require significant refactoring, to correct This is large

by copergi 13y ago

>Haskell's laziness makes slow code and code that use up a lot of memory hard to locate, and at times require significant refactoring, to correct This is largely mythology built up around a misunderstanding of the grain of truth at the core of it. Lazyness can create pathological performance issues, just as strictness can. 90% of the time neither matters, 5% of the time you need strictness, 5% of the time you need laziness. Using strictness in haskell is very simple, and knowing when you need to is very easy to learn. The profiling tools make it incredibly obvious when laziness is causing a problem. And I can't even imagine a case where it requires significant refactoring. It is generally adding a couple of "!"s or importing Module.Strict instead of Module.Lazy.

tel 13y ago
I'd like to add that for the 90% of the time it doesn't matter, 95% of that time you could use a total language. This is one of the joys of using a total language: seeing what's still easy!
chriswarbo 13y ago
> This is largely mythology built up around a misunderstanding of the grain of truth at the core of it. I agree. I've encountered a few space leaks in my Haskell code, but it's always been pretty easy to track down: profile the memory usage and look for a conspicuously huge peak. It will usually be fixable by forcing an intermediate result, or using a different recursion strategy (eg. a fold instead of explicit recursion). Haskell functions tend to be so small and single-purpose that there are no knock-on effects of doing this refactoring. I think there's a perception that 'Haskell is difficult to debug', whereas the reality is more like 'Haskell will reject all of the easy bugs'. In other words, the average difficulty of a Haskell bug may be higher, but the density is less.
- ufo 13y ago
  > eg. a fold instead of explicit recursion Wouldn't adding some bangs in the patterns kind of do the same thing as using foldl'?
  - AaronFriel 13y ago
    Yes. Most recommendations for implementing recursion in Haskell that I've seen have amounted to writing it in terms of folds. You gain the benefit of experts vetting the code, and novices being able to understand what it is doing it a glance.
theseoafs 13y ago
I see no reason why strictness would have pathological performance problems. If you don't need to compute a value, dinner compute it. No performance problems. I also see no reason you would need laziness for 5% of programming problems. That seems absurd given that the overwhelming majority of programmers have gotten along without it for 50 years.
- copergi 13y ago
  >I see no reason why strictness would have pathological performance problems. If you don't need to compute a value, dinner compute it. No performance problems. You just answered your own question. "If you don't need to compute a value, then don't compute it" is laziness. >That seems absurd given that the overwhelming majority of programmers have gotten along without it for 50 years. No they haven't. Most programmers don't understand it, but they tend to use it on a regular basis.
  - theseoafs 13y ago
    > You just answered your own question. "If you don't need to compute a value, then don't compute it" is laziness. No -- "laziness" is saying "the programmer wants us to compute this value, but we don't need it just yet, so we're going to create a thunk that will sit on the heap until it's evaluated or garbage collected". Strictness is doing what the programmer says, which involves the programmer deciding what does and does not have to be computed while he's writing the program.
    - copergi 13y ago
      Perhaps I was not clear. You stated the very reason for laziness: to not compute things you don't need computed. There are many cases where it is very beneficial to be able to determine this at evaluation time, rather than when writing the code. Hence laziness, and hence it being used all the time in most mainstream languages.
      - theseoafs 13y ago

by copergi 13y ago

tel 13y ago

I'd like to add that for the 90% of the time it doesn't matter, 95% of that time you could use a total language. This is one of the joys of using a total language: seeing what's still easy!

chriswarbo 13y ago

> This is largely mythology built up around a misunderstanding of the grain of truth at the core of it. I agree. I've encountered a few space leaks in my Haskell code, but it's always been pretty easy to track down: profile the memory usage and look for a conspicuously huge peak. It will usually be fixable by forcing an intermediate result, or using a different recursion strategy (eg. a fold instead of explicit recursion). Haskell functions tend to be so small and single-purpose that there are no knock-on effects of doing this refactoring. I think there's a perception that 'Haskell is difficult to debug', whereas the reality is more like 'Haskell will reject all of the easy bugs'. In other words, the average difficulty of a Haskell bug may be higher, but the density is less.

ufo 13y ago
> eg. a fold instead of explicit recursion Wouldn't adding some bangs in the patterns kind of do the same thing as using foldl'?
- AaronFriel 13y ago
  Yes. Most recommendations for implementing recursion in Haskell that I've seen have amounted to writing it in terms of folds. You gain the benefit of experts vetting the code, and novices being able to understand what it is doing it a glance.

theseoafs 13y ago

I see no reason why strictness would have pathological performance problems. If you don't need to compute a value, dinner compute it. No performance problems. I also see no reason you would need laziness for 5% of programming problems. That seems absurd given that the overwhelming majority of programmers have gotten along without it for 50 years.

copergi 13y ago
>I see no reason why strictness would have pathological performance problems. If you don't need to compute a value, dinner compute it. No performance problems. You just answered your own question. "If you don't need to compute a value, then don't compute it" is laziness. >That seems absurd given that the overwhelming majority of programmers have gotten along without it for 50 years. No they haven't. Most programmers don't understand it, but they tend to use it on a regular basis.
- theseoafs 13y ago
  > You just answered your own question. "If you don't need to compute a value, then don't compute it" is laziness. No -- "laziness" is saying "the programmer wants us to compute this value, but we don't need it just yet, so we're going to create a thunk that will sit on the heap until it's evaluated or garbage collected". Strictness is doing what the programmer says, which involves the programmer deciding what does and does not have to be computed while he's writing the program.
  - copergi 13y ago
    Perhaps I was not clear. You stated the very reason for laziness: to not compute things you don't need computed. There are many cases where it is very beneficial to be able to determine this at evaluation time, rather than when writing the code. Hence laziness, and hence it being used all the time in most mainstream languages.
    - theseoafs 13y ago