Hacker News Reader

Comment by adrian_b | Hacker News Reader

In any programming language where functions are allowed as arguments to functions, and most languages that are still in use allow this, you can choose lazy evaluation for any function argument. Already Algol 60 had "call-by-name", which could be used to do lazy evaluation.

The only difference in Haskell and similar languages is that lazy evaluation is the default mode of evaluation, and if you do not want this it is more difficult to make another choice.

While there is no doubt that there are certain cases when lazy evaluation is desirable, I have never seen any evidence that lazy evaluation by default is better instead of worse.

Despite lower efficiency, lazy evaluation by default may have a psychological advantage for programmers who find it easier to understand programs with lazy evaluation than programs with immediate evaluation, but neither I am one of those nor have I ever met one of those.

View on HN

> I have never seen any evidence that lazy evaluation by default is better instead of worse

With lazy-by-default: if you want strictness, you can simply 'evaluate something now'.

With strict-by-default: if you want laziness, you have to rewrite your code, and all the libraries that your code calls.

> psychological advantage for programmers who find it easier to understand programs with lazy evaluation

This is entirely based what you're used to. If you can be OK with executing either the true-branch or the false-branch of an if-statement (but not both), you can be OK with lazy evaluation. Same with boolean short circuiting.

Why should

    true || error()

return true, but

    any [true, error(), error()]

return error?

> "If you can be OK with executing either the true-branch or the false-branch of an if-statement (but not both), you can be OK with lazy evaluation. Same with boolean short circuiting."

Understanding lazy evaluation that occurs here and there in a program is not a problem for anyone.

Understanding the behavior of a program where all function arguments are evaluated lazily is something extremely different and it is notorious that even the experienced Haskell programmers frequently fail to predict correctly the requirements in time and memory of a program.

> With strict-by-default: if you want laziness, you have to rewrite your code

I agree that this is true, but in decades of programming experience I have never encountered such a case.

Discovering that you want lazy evaluation after you have already written a program means that the initial concept of the program had very serious flaws and you have started coding before thinking properly what you have to do.

Sometimes it happens that it is discovered that a program needs a rewrite because the problem that it must solve had not been understood, but in almost all cases such rewrites are needed for completely other causes than the need of some lazy evaluations.

So this argument in favor of lazy evaluation brings an advantage in some very rare cases, like also the argument that lazy evaluation by default sometimes saves work because eventually it may be discovered that the evaluation is not necessary, but this is also a relatively rare event, which must be balanced with much extra work that must be done by the CPU at each function invocation (which is a very frequent event), in order to implement lazy evaluation by default.

In Clojure, where lazy evaluation is also the default (although only for sequences), someone recently wrote an in-depth article about the issues caused by this choice: https://clojure-goes-fast.com/blog/clojures-deadly-sin/

I haven’t read the whole article yet, but maybe it could be interesting to compare it with Haskell and see if some of the same problems occur or if Haskells compiler or overall design around (pervasive) lazyness makes it easier to work with and more performant.

clojure does not have lazy evaluation of any form. “lazy sequences” are a hack, clojure core uses macros to thunkify sequence traversal in userland. this hack interacts badly with a few other aspects of clojure because clojure itself is not lazy, being that it is a hosted language designed to lightly cover the host platform (Java, JS, .NET, Dart) and maximize host ecosystem compatibility and therefore does not alter core platform semantics such as concurrency model or evaluation model.

>Already Algol 60 had "call-by-name", which could be used to do lazy evaluation.

https://en.m.wikiquote.org/wiki/Niklaus_Wirth

See section: Quotes about Niklaus Wirth

" Whereas Europeans generally pronounce his name the right way ('Nick-louse Veert'), Americans invariably mangle it into 'Nickel's Worth.' This is to say that Europeans call him by name, but Americans call him by value. "

Reply on news.ycombinator.com