[Haskell-cafe] Does laziness make big difference?

[Claus Reinke]

> So, as I understand, choosing default laziness was just experimental design decision in order to 
> answer the >question: "how good lazy language can be". I am practically convinced, that lazy 
> evaluation included in the >_right_ places can be extremely useful. I didn't state the question as 
> "strict vs lazy", my question is different - >"default laziness with optional strict -vs- default 
> strictness with optional lazy". And sorry, but the question >remains open.

at the time, lazyness was also the best-known basis for pure functional i/o (result
continuations and monads taking over later), still a hot and tricky topic then.

as for defaults, lazy evaluation is normal order strategy + sharing of arguments,
strict evaluation corresponds to applicative order strategy, and we know from
lambda-calculus that normal order strategy is normalizing (reaches a normal form
if one exists) whereas applicative order strategy is not.

on this basis, non-strictness is a safe default, with strictness to be inferred or
annotated where needed. since strictness is undecidable in general, inference
has to be approximate, and a safe default is essential.

of course, one can program in mostly strict languages - I started out in one that used
applicative order strategy, but had normal order application as well, plus the usual
\()->thunking. and as you say, modern versions of default strictness allow you to
annotate the function as non-strict, so you don't have to use special application
operators everywhere, and lazy-keywords are clearer than \()->thunks.

but from my own experience, I had to think a lot more about evaluation order
in the default-strict language than I have to in the default-non-strict language,
and what is worse, I had to do this thinking up-front, whereas now I can
think about the data-dependencies first, and do the thinking about evaluation
order later, and only on demand:-)

that is also why programs written in default-strict languages often seem to win
in performance competitions: if you get it to work at all, you'll also have put in
some thoughts on performance/evaluation order already. programs written in
default-non-strict languages can be made to "work" without worrying about
those details, so it often happens to look as if lazy programs were resource-
hungry, and a lot of extra work had to be put in to make them efficient.

but I'd put it differently: about the same amount of thought has to be put in
to make either kind of program efficient, only that with non-strict default, I
get to choose when (and whether) to put in that effort.

in other words, default-strict languages are strict in demanding evaluation-
order information early, whereas default-non-strict languages give the
programmer more leeway.

hth,
claus