This is an interesting read. One part jumped out at me (sorry for the long quote)
The purpose of the technical problem was to assess more directly candidates ability to write Haskell programs that can be used to solve real world problems, where memory usage and performance are important. The problem was all about evaluation order and memory behaviour. We started by asking candidates to look at a short program and say what shape they would expect the heap profile to be. That would then lead on to a discussion of what things are evaluated at what stage and how much memory they are taking in the meantime. For the final step we asked candidates to rewrite the program to run in constant space. We felt overall that the technical problem was quite useful and we allowed it to become a significant factor in our final decision making process.
The choice of problem is based on our belief that a good understanding of evaluation order is very important for writing practical Haskell programs. People learning Haskell often have the idea that evaluation order is not important because it does not affect the calculated result. It is no coincidence that beginners end up floundering around with space leaks that they do not understand.
I've written a lot of C++ and a fair amount of Haskell, and this kind reasoning about the evaluation order and space usage of Haskell a program is no less of a black art than pointer arithmetic or manual memory management in C++. In both cases, it's too steep of a learning curve to just be able to write practical programs, which is why garbage collected languages have displaced C++ in many domains.
It's particularly damning to say that "good understanding of evaluation order is very important for writing practical Haskell programs" because the easiest evaluation order to understand is strict evaluation order. In that sense, lazy evaluation is to strict evaluation as manual memory management is to garbage collection, except that the latter is supposed to be an improvement on the former.
I would actually say that pointer arithmetic and manual memory management are _easier_ than managing space by controlling evaluation order.
The real benefit of lazy-evaluation is that it decouples generation from consumption in a very thorough way. Unfortunately it often doesn't scale up as space leaks attest. I'm starting to think that in the large it should be feasible to replace it with CSP-like channels, though this is essentially boiler-plating the runtime code, it gives far more fine control.
I'd say also say that automatic memory management is similar. The downside to manual is not all the debugging difficulties per se, but the fact that you do have to decide who allocates, who deallocates, and that these decisions are highly coupled and can greatly impact the choice of feasible data structures.
I see one major difference: a Haskell program with optimization mistakes will run slowly and waste memory, its performance will improve as you fix them, and eventually you can stop because it's sufficient. A C++ program with any memory mistakes whatsoever will blow up randomly, and will continue doing so after you give up trying to make it perfect (which is hardly ever feasible) and ship unstable crap like the rest of the industry.
I was bitten by the space leak once or twice and my programs was useful for my colleagues despite that errors.
One great example is the model of CPU. Space leak made it to slow down quadratically - simulation_speed=O(1/simulated_time^2). It took a second for 5000 cycles and couple of hours for 100000. But all interesting effects about CPU execution could be discovered in 5000-20000 cycles - inner loops of various use cases. So you have to wait about minute or so to see what is good and what is not.
That's not entirely true. A haskell program can also fail in unpredictable ways thanks to lazy evaluation and memory exhaustion. It's probably still easier to pinpoint the source of the problem than it is to track down memory corruption in C++.
Yeah, it's true that performance can be so poor that the Haskell program can't get any useful work done. I was trying to express the spectrum from "perfect" to "tolerable" to "pretty bad" (and "unusable" does belong at the far end), where all the old unchecked languages only offer a cliff between "perfect" and SIGSEGV (or "random output" if you're really unlucky).
In most cases, tracking down memory corruption is pretty easy in C++. The simplest cases are solvable using gdb, and about 99% of the rest can be easily solved using valgrind.
Unless you're running 64-bit, a program's memory space is not only finite but relatively minuscule, and exhausting it through wasted memory is definitely a possibility.
Replace "lazy" with "non-strict" and I think you're on to something. Strict and lazy both specify a particular evaluation order, but you are talking about leaving the evaluation order unspecified and letting the compiler or runtime decide which evaluation order is best.
I love today's GC, which allows me to mostly forget about memory management, but if GC still meant waiting hours for a collection I would be more inclined to manage my own memory.
Clojure's lazy sequences, combined with doall to force strict evaluation when you want it, seem like a nice compromise for now, but will likely seem archaic when a good evaluation-order optimizer is developed.
The purpose of the technical problem was to assess more directly candidates ability to write Haskell programs that can be used to solve real world problems, where memory usage and performance are important. The problem was all about evaluation order and memory behaviour. We started by asking candidates to look at a short program and say what shape they would expect the heap profile to be. That would then lead on to a discussion of what things are evaluated at what stage and how much memory they are taking in the meantime. For the final step we asked candidates to rewrite the program to run in constant space. We felt overall that the technical problem was quite useful and we allowed it to become a significant factor in our final decision making process.
The choice of problem is based on our belief that a good understanding of evaluation order is very important for writing practical Haskell programs. People learning Haskell often have the idea that evaluation order is not important because it does not affect the calculated result. It is no coincidence that beginners end up floundering around with space leaks that they do not understand.
I've written a lot of C++ and a fair amount of Haskell, and this kind reasoning about the evaluation order and space usage of Haskell a program is no less of a black art than pointer arithmetic or manual memory management in C++. In both cases, it's too steep of a learning curve to just be able to write practical programs, which is why garbage collected languages have displaced C++ in many domains.
It's particularly damning to say that "good understanding of evaluation order is very important for writing practical Haskell programs" because the easiest evaluation order to understand is strict evaluation order. In that sense, lazy evaluation is to strict evaluation as manual memory management is to garbage collection, except that the latter is supposed to be an improvement on the former.