Lines of code fails as a measure of code quantity for languages like Lisp and Haskell. 500 lines of Haskell code can accomplish what will take 1500-5000 lines of Java.
When I'm trying to get stuff done I would rather spend 3x as much time typing in code than waste all week deciphering 'core' and reading heap profiling output to track down a space leak that could never happen in any other language.
I've heard that Haskell's space performance isn't great, but I don't know enough about the language to confirm or deny this.
I would recommend, if you're concerned with performance, using Ocaml. You can compile it down to native code, and its performance characteristics are comparable to C.
Yes, I have had to solve this problem a lot. It's probably my own fault because I am an inexperienced Haskell programmer, and maybe it's just because I'm incompetent but I find space performance very difficult to reason about.
It seems like anybody can make these mistakes, and they are mostly invisible until one day your problem size is a little bit larger than normal and your program explodes and crashes.
In a strict language, you write an expression and it's perfectly clear when it will be evaluated.
With lazy evaluation to know if or when an expression will be evaluated you have to follow it through possibly many layers of function calls (which may have been written by somebody else) looking for a place where it needs to be evaluated. Along the way it may become embedded in other expressions which complicates the problem.
How do you know when an expression needs to be evaluated? I don't know if I'm smart enough to understand the answer to that question:
Students in introductory programming classes write programs longer than that.
Get back to me when you've implemented KDE, Aqua, or Aero in Haskell.