3 ms·

> Trying to debug a memory leak caused by insufficient strictness --- why do I need to care about this? The runtime should just take care of it for me; the whol

> Trying to debug a memory leak caused by insufficient strictness --- why do I need to care about this? The runtime should just take care of it for me; the whole point of a lazy language is that I shouldn't have to care when evaluation happens. This is a completely wrong assumption. The point of laziness is not so you won't have to care about evaluation order. Everyone would like to have a language in which you don't have to think about evaluation order, but that has proven to be rather hard. Not because the people who invented Haskell or implemented the compilers are idiots who don't know what they're doing, but because it a hard problem to tackle. With many pros and cons on both the lazy and the strict side. This isn't embarrassing at all. At least you need to think less about evaluation order in Haskell than in most other languages.

platz 11y ago
intuition about lazy evaluation order can be very misleading
- AnimalMuppet 11y ago
  Is it fair to say that in Haskell, you have to think about evaluation order less, but when you do, it's harder?
  - jonnybgood 11y ago
    When you hit that difficult to reason about evaluation order in Haskell, it'll take that time you thought you gained.
  - oconnore 11y ago
    I think it can be unexpected if you're used to other semantics, but the behavior of laziness is very well defined. > let x = [1 .. 100] :: [Int] > seq x () -- force the first cons > :sprint x x = 1 : _ -- we evaluated the first cons > foldr (\e l -> e + l) 0 x 5050 -- printing this value forces foldr to complete > :sprint x x = [1,2,3,4,5...100] -- all conses evaluated
- safewayclubcard 11y ago
  I agree with this statement. I think lazy evaluation is very hard, especially when you are dealing with a codebase of of say 50 files with structures containing other structures, the line between lazy and strict is very hard to see. The difficulty learning lazy evaluation skill goes from * 0 where you know nothing to 5 where you sort of understand. * 5 - 90 is a space where you think you know what it is, but you really don't. You'll probably get yourself in trouble more than helping. * 90-100 is when you grok it and can use it effectively. I am an avid haskell user for a few years and I am still 50/50 on most of my conclusions about laziness without asking someone else.

platz 11y ago

intuition about lazy evaluation order can be very misleading

AnimalMuppet 11y ago
Is it fair to say that in Haskell, you have to think about evaluation order less, but when you do, it's harder?
- jonnybgood 11y ago
  When you hit that difficult to reason about evaluation order in Haskell, it'll take that time you thought you gained.
- oconnore 11y ago
  I think it can be unexpected if you're used to other semantics, but the behavior of laziness is very well defined. > let x = [1 .. 100] :: [Int] > seq x () -- force the first cons > :sprint x x = 1 : _ -- we evaluated the first cons > foldr (\e l -> e + l) 0 x 5050 -- printing this value forces foldr to complete > :sprint x x = [1,2,3,4,5...100] -- all conses evaluated
safewayclubcard 11y ago
I agree with this statement. I think lazy evaluation is very hard, especially when you are dealing with a codebase of of say 50 files with structures containing other structures, the line between lazy and strict is very hard to see. The difficulty learning lazy evaluation skill goes from * 0 where you know nothing to 5 where you sort of understand. * 5 - 90 is a space where you think you know what it is, but you really don't. You'll probably get yourself in trouble more than helping. * 90-100 is when you grok it and can use it effectively. I am an avid haskell user for a few years and I am still 50/50 on most of my conclusions about laziness without asking someone else.