3 ms·

> This is FUD, repeated ad nauseum all over the internet as a misinterpretation of what Simon Peyton Jones said once during a talk. In case you hadn't noticed,

> This is FUD, repeated ad nauseum all over the internet as a misinterpretation of what Simon Peyton Jones said once during a talk. In case you hadn't noticed, there appears to be a tradition in programmer circles of picking SPJ quotes and turning them into memes. "Haskell is useless!" and "Avoid success at all costs!" are some others. I think you have this backwards. People have been saying that laziness has unpredictable performance characteristics (especially when it comes to space usage) as long as there have been lazy functional languages. SPJ was referring to that common sentiment; it didn't somehow materialize because of comment he made during a talk. There was an era where space complexity and space usage semantics were a big deal in functional programming, e.g. the work on giving a precise definition of "tail call optimization" and the emphasis on space safety that has since been present in the strict functional programming world. In contrast, there is no standard space semantics for lazy languages, and certainly none that GHC respects. It's tricky when simple CSE can dramatically alter the space complexity of your program, e.g. https://ghc.haskell.org/trac/ghc/ticket/947 https://ghc.haskell.org/trac/ghc/ticket/947 https://ghc.haskell.org/trac/ghc/ticket/1752 https://ghc.haskell.org/trac/ghc/ticket/1752

chongli 13y ago
I didn't say there wasn't any difficulty, I said it was FUD. It is true that there is more mental overhead in reasoning about space usage in a lazy language. It is not true that this is unpredictable. If that were the case, it would be a complete crapshoot for people to write code in a lazy language. Luckily, a basic understanding of Haskell's evaluation model gives one the ability to predict space usage and know reliably what sort of anti-patterns to avoid (such as the infamous lazy foldl). The problem with FUD is that it takes reasonable statements and exaggerates them to an unreasonable degree. People repeat the word "difficult", eventually someone starts using "very difficult", sooner or later people start throwing around "impossible".
- cwzwarich 13y ago
  It's not just the evaluation model; you have to know whether the compiler will perform transformations behind your back that increase space usage. If you were to impose a space semantics on the compiler and require that it preserve the semantics, a lot of optimizations would have to be disabled for lazy expressions. It's not surprising that people manage to produce lots of working programs despite this, though. Almost all life-critical software is written in completely unsafe languages.
  - chongli 13y ago
    the compiler will perform transformations behind your back that increase space usage This is not exclusive to Haskell; even C compilers will do this with jump tables and so on.
    - cwzwarich 13y ago
      Jump tables don't increase asymptotic space complexity, whereas some of GHC's optimizations will. You can also see how much jump tables increased the space usage of your program by inspecting the size of the compiled binary.
- Nimi 13y ago
  I'm not proficient in Haskell, just a bystander, but this isn't the sentiment I get from reading Neil Mitchell's posts on the subject: http://queue.acm.org/detail.cfm?id=2538488 http://queue.acm.org/detail.cfm?id=2538488 http://neilmitchell.blogspot.com/2013/02/chasing-space-leak-in-shake.html http://neilmitchell.blogspot.com/2013/02/chasing-space-leak-... He appears to use profiling tools and "try them all and see which produces the most useful information", to me that sounds very different from reasoning.
  - chongli 13y ago
    Try this: http://blog.ezyang.com/2011/05/anatomy-of-a-thunk-leak/ http://blog.ezyang.com/2011/05/anatomy-of-a-thunk-leak/ and particularly this: http://blog.ezyang.com/2011/05/an-insufficiently-lazy-map/ http://blog.ezyang.com/2011/05/an-insufficiently-lazy-map/ One point I'd like to mention: just because it seems complex and intimidating for beginners/outsiders does not mean it is intractable for experienced programmers.

chongli 13y ago

I didn't say there wasn't any difficulty, I said it was FUD. It is true that there is more mental overhead in reasoning about space usage in a lazy language. It is not true that this is unpredictable. If that were the case, it would be a complete crapshoot for people to write code in a lazy language. Luckily, a basic understanding of Haskell's evaluation model gives one the ability to predict space usage and know reliably what sort of anti-patterns to avoid (such as the infamous lazy foldl). The problem with FUD is that it takes reasonable statements and exaggerates them to an unreasonable degree. People repeat the word "difficult", eventually someone starts using "very difficult", sooner or later people start throwing around "impossible".

cwzwarich 13y ago
It's not just the evaluation model; you have to know whether the compiler will perform transformations behind your back that increase space usage. If you were to impose a space semantics on the compiler and require that it preserve the semantics, a lot of optimizations would have to be disabled for lazy expressions. It's not surprising that people manage to produce lots of working programs despite this, though. Almost all life-critical software is written in completely unsafe languages.
- chongli 13y ago
  the compiler will perform transformations behind your back that increase space usage This is not exclusive to Haskell; even C compilers will do this with jump tables and so on.
  - cwzwarich 13y ago
    Jump tables don't increase asymptotic space complexity, whereas some of GHC's optimizations will. You can also see how much jump tables increased the space usage of your program by inspecting the size of the compiled binary.
Nimi 13y ago
I'm not proficient in Haskell, just a bystander, but this isn't the sentiment I get from reading Neil Mitchell's posts on the subject: http://queue.acm.org/detail.cfm?id=2538488 http://queue.acm.org/detail.cfm?id=2538488 http://neilmitchell.blogspot.com/2013/02/chasing-space-leak-in-shake.html http://neilmitchell.blogspot.com/2013/02/chasing-space-leak-... He appears to use profiling tools and "try them all and see which produces the most useful information", to me that sounds very different from reasoning.
- chongli 13y ago
  Try this: http://blog.ezyang.com/2011/05/anatomy-of-a-thunk-leak/ http://blog.ezyang.com/2011/05/anatomy-of-a-thunk-leak/ and particularly this: http://blog.ezyang.com/2011/05/an-insufficiently-lazy-map/ http://blog.ezyang.com/2011/05/an-insufficiently-lazy-map/ One point I'd like to mention: just because it seems complex and intimidating for beginners/outsiders does not mean it is intractable for experienced programmers.