In a lazy evaluated program, you say “We need these pieces of information”. You don’t specify the order in which they get worked out, so the compiler is free to process them in any order, or split the calculations across many cores, .

Which isn’t to say that I disagree with you (although I think we have a long way to go before the ability of the compiler to optimise pure lazy code is as good as the state of the art of garbage collection these days). It’s just that the specific example is wrong.

http://www.cs.mu.oz.au/research/mercury/information/papers.html#wangp-hons

Lazy evaluation implies a particular evaluation order (outermost-first, rather than strict-evaluation’s innermost-first), along with the technique of sharing the computation of expressions which came from a function parameter being duplicated in the function’s body. Lazy evaluation is an implementation of non-strict semantics — it’s possible to show that if some order of evaluation terminates and produces a result, then lazy evaluation will also terminate and produce the same thing.

However, that aside, even just lazy evaluation really does have a big impact on the way in which you can program. Because results are only produced if demanded, it becomes possible to define larger structures than you might need in your specific case (which is often easier than explicitly restricting your computation), and then have the remaining part of the computation only use what it needs. This allows you to decompose problems in new ways that you couldn’t before, and get better code reuse.

Non-strict semantics, without the guarantee of lazy evaluation, allows compiler writers additional freedom to do things like parallelise (though this is really hard to accomplish automatically — programmer annotations help a lot) or apply other evaluation strategies like strict evaluation automatically in places where it’s verifiably safe to do so.

Also, I think you need to look in more detail about automatic memory manage. The speed increase they gained was probably due to a copy on garbage collect behavior. Whenever the garbage collector is run, it likely automatically restructures the allocated memory so that its contiguous. Once this is the case, memory allocation just requires a few pointer arithmetic operations. In manual memory languages, since you cannot ‘defrag’ the active memory like this, you must maintain dirty/clean lists of memory, and every memory allocation is a search.

The speed increase for the memory managed version is amortized by the general slowdown of whatever garbage collection algorithm that is in use. Even still, automatic memory management is something I think nearly everyone should use and enjoy.

To round out this comment, one real benefit of lazy evaluation, is in the building of infinite streams. If you can describe a value as some formula of previous values, then it naturally fits into a list comprehension. For example, you could define fibiconni’s numbers (0,1,1,2,3,5…) as a array and access any member of it (element 0 to element 6×10^66) — the program will only compute as much as you actually use. This frees the programmer from some explicit bookkeeping.

What does lazy evaluation have to do with this?