Laziness in haskell is a weird issue. It makes compilation harder and it makes it much harder to predict a program’s performance, or the global performance impact of a local change (eg a change might be locally good but change to no longer evaluate so many things at once, deferring that evaluation to happen when it is more expensive—because eg the compiler can’t inline or there is no cache efficiency). Indeed Peyton Jones has said that the next haskell [family language] would be strict.
On the other hand, it allows for many programs to be written in nicer, more direct and declarative ways. As well as allowing for weirdness like in this article. But maybe a lot of that is more coming from code transformations enabled by purity and something like clojure-style lazy sequences (or strict if they are finite) plus aggressive inclining and stream fusion would be sufficient.
Laziness being the default means libraries compose better though.
I quite like how Haskell does it now, and reasoning about its performance honestly isn't bad. And that's worn GHC optimizing like crazy (which is actually what makes Haskell performance wonky to think about - not laziness.)
Agreed. The laziness seems to only be useful when it is pervasive. Having only a little laziness isn’t so difficult from having none at all (eg OCaml has optional laziness but it is hardly used at all)
Fixpoints are one of the most important concepts in denotational semantics and domain theory (see [0] for a good introduction). Denotational semantics lets you precisely specify the meaning of a program as a mathematical object, and also nicely integrates partiality and nontermination. It's quite motivating to learn order theory this way as well.
Fixed points are also an important part of the technique described in the paper "Abstracting Definitional Interpreters" https://arxiv.org/pdf/1707.04755.pdf
The factorial function can be useful for explaining the basics since it’s so simple, but it makes a poor example for showing when foldr is better than direct recursion.
On the other hand, it allows for many programs to be written in nicer, more direct and declarative ways. As well as allowing for weirdness like in this article. But maybe a lot of that is more coming from code transformations enabled by purity and something like clojure-style lazy sequences (or strict if they are finite) plus aggressive inclining and stream fusion would be sufficient.