>He seems to enjoy writing Haskell
This article gives no evidence of this. None of the concepts that the article lists out are Haskell exclusive. Thunks and linked list can be made in C too.
This article gives no evidence of this. None of the concepts that the article lists out are Haskell exclusive. Thunks and linked list can be made in C too.
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.
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()
any [true, error(), error()]
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.
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.
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. "