<p>I understand there are some advantages of lazy languages like Haskell. For example, one can easily write/use an infinite list without worrying about it being evaluated eagerly. I heard there are other theoretical advantages.</p>
<p>But some of the newer functional programming languages (even ones inspired by Haskell) such as <a href="https://stackoverflow.com/a/72193000">lean4 and idris are strict</a>.</p>
<p><em>Are there some disadvantages (or practical difficulties) of making a language lazy by default?</em></p>

<functional-programming><lazy-evaluation>
What are the disadvantages of lazy languages?
CC BY-SA 4.0
2023-05-25T07:54:32.517Z
I'd like to note that in contrast to Haskell, dependently-typed languages like Agda, Idris and Lean are (mostly) **total**, which entails they are **confluent**, meaning the order of reductions — lazy or strict evaluation — doesn't matter, the end result will always be the same. Which is again, not the case for Haskell/OCaml. And strict evaluation order is easier to implement, so... :)
Alex Chichigin
CC BY-SA 4.0
2023-05-25T08:43:14.167Z
See also https://en.wikipedia.org/wiki/Confluence_(abstract_rewriting)
Bruce Adams
<p>There are a lot of situations where lazy evaluation is beneficial and avoids unneeded calculation (like infinite lists in Haskell) or gives other benefits (like <code>substitute</code> in R), but it also imposes unavoidable performance costs everywhere to thunk computations, both in time and memory.</p>
<p>For the cases where lazy behaviour is required, embedding that piece of computation into a function, or an explicitly-lazy construct (like a generator), is possible, so there are middle grounds available. Lazy-by-default can lead to pretty severe unexpected blowups from the programmer's code: the traditional example is something like <code>foldl (+) 0 [1..100000]</code> in Haskell, which looks innocent but expands out to the full summation expression before reducing.</p>
<hr />
<p>For <em>impure</em> functional languages, lazy evaluation gives observable effects, often confusing ones. The value of the expression may change before it's forced, or out-of-order side effects can be visible (and wrong). Lazy-by-default is quite rare in these languages, understandably; R is probably the most widespread one with this behaviour. My unscientific feeling is that more new functional languages recently are impure than pure, which can also account for some reduction in overall laziness.</p>
<hr />
<p>It's also significantly easier to implement a strict language; I don't think that is an issue for Idris, but for others implementing lazy evaluation may be more engineering effort than is worthwhile. As a practical matter, picking lazy evaluation is a big commitment if you're not making it fundamental to the nature of the language. GHC does a lot of (ongoing!) work to get acceptable performance, and that's worthwhile for getting the essence of Haskell.</p>
<p>Non-strict evaluation just isn't inherently better, only different, and there have always been (more) strict functional languages. Even in Haskell, many programs wouldn't fundamentally change under a strict model — the infinite recursive constructs that really benefit from lazy evaluation aren't even part of many problem domains.</p>
<p>Debugging lazy behaviour can also be difficult. Precisely when some piece of code runs is not (easily) predictable, or even knowing whether it has. Available debugger tooling and affordances to help with this are also limited, and compensating for that would again be real development effort.</p>
<p>It's a very reasonable design choice to decide that the things that strict evaluation provides, like fixed evaluation ordering and predictable performance, help the ergonomics of the language without losing out on anything significant.</p>
<hr />
<p>From the language designer's perspective, it may also be the case that Haskell has so thoroughly occupied that particular niche in the design space that making a whole new language just isn't worthwhile. Some GHC extensions could well be different languages, and we just call them all &quot;Haskell&quot; for social reasons.</p>

CC BY-SA 4.0
2023-05-25T05:43:06.273Z
2023-05-25T06:54:00.260Z
2023-05-25T06:54:00.260Z
Michael Homer
CC BY-SA 4.0
2023-05-25T06:39:01.887Z
I would add difficulty of debugging as a downside of laziness. Also, on the unscientific side, Simon Peyton-Jones used to say that if he had to do it again, he'd make Haskell strict (I don't know if he wrote it down somewhere). On the other hand, in terms of language design, being able to encode control structures as ordinary functions is a benefit: it does make the language simpler to use for simple things like an `if` “statement” which can be an ordinary expression.
Gilles 'SO- stop being evil'
CC BY-SA 4.0
2023-05-25T07:58:21.590Z
"GHC does a lot of (ongoing!) work to get acceptable performance" — GHC performance is **excellent** and very impressive. One time I easily outperformed Rust on a lambda (Krivine) machine implementation. :D
Alex Chichigin
CC BY-SA 4.0
2023-05-25T08:01:01.857Z
@Gilles'SO-stopbeingevil' "Simon Peyton-Jones used to say that if he had to do it again, he'd make Haskell strict (I don't know if he wrote it down somewhere)" I remember reading Peyton-Jones saying if they'd made Haskell strict, they would dream of a lazy version in the same way now we're dreaming about a strict one. :)
Alex Chichigin
CC BY-SA 4.0
2024-02-22T18:23:25.040Z
I am sure that fiexd evaluation ordering is bad for automatic parallelization and note that non strict evaluation allows for that every program if terminates will terminate, which is not guaranteed in strict evaluation
Delfin
# What are the disadvantages of lazy languages?
Posted by: username_0 on 2023-05-25
I understand there are some advantages of lazy languages like Haskell. For example, one can easily write/use an infinite list without worrying about it being evaluated eagerly. I heard there are other theoretical advantages.

But some of the newer functional programming languages (even ones inspired by Haskell) such as [lean4 and idris are strict](https://stackoverflow.com/a/72193000).

*Are there some disadvantages (or practical difficulties) of making a language lazy by default?*
**Tags:** functional-programming lazy-evaluation
> **Comments:**
> **username_1**: I'd like to note that in contrast to Haskell, dependently-typed languages like Agda, Idris and Lean are (mostly) **total**, which entails they are **confluent**, meaning the order of reductions — lazy or strict evaluation — doesn't matter, the end result will always be the same. Which is again, not the case for Haskell/OCaml. And strict evaluation order is easier to implement, so... :)  
> **username_2**: See also https://en.wikipedia.org/wiki/Confluence_(abstract_rewriting)  
---
## 1 answers
### Answer by username_3 on 2023-05-25. Score: 14 | Accepted answer
There are a lot of situations where lazy evaluation is beneficial and avoids unneeded calculation (like infinite lists in Haskell) or gives other benefits (like `substitute` in R), but it also imposes unavoidable performance costs everywhere to thunk computations, both in time and memory.

For the cases where lazy behaviour is required, embedding that piece of computation into a function, or an explicitly-lazy construct (like a generator), is possible, so there are middle grounds available. Lazy-by-default can lead to pretty severe unexpected blowups from the programmer's code: the traditional example is something like `foldl (+) 0 [1..100000]` in Haskell, which looks innocent but expands out to the full summation expression before reducing.

---

For *impure* functional languages, lazy evaluation gives observable effects, often confusing ones. The value of the expression may change before it's forced, or out-of-order side effects can be visible (and wrong). Lazy-by-default is quite rare in these languages, understandably; R is probably the most widespread one with this behaviour. My unscientific feeling is that more new functional languages recently are impure than pure, which can also account for some reduction in overall laziness.

---

It's also significantly easier to implement a strict language; I don't think that is an issue for Idris, but for others implementing lazy evaluation may be more engineering effort than is worthwhile. As a practical matter, picking lazy evaluation is a big commitment if you're not making it fundamental to the nature of the language. GHC does a lot of (ongoing!) work to get acceptable performance, and that's worthwhile for getting the essence of Haskell.

Non-strict evaluation just isn't inherently better, only different, and there have always been (more) strict functional languages. Even in Haskell, many programs wouldn't fundamentally change under a strict model — the infinite recursive constructs that really benefit from lazy evaluation aren't even part of many problem domains.

Debugging lazy behaviour can also be difficult. Precisely when some piece of code runs is not (easily) predictable, or even knowing whether it has. Available debugger tooling and affordances to help with this are also limited, and compensating for that would again be real development effort.

It's a very reasonable design choice to decide that the things that strict evaluation provides, like fixed evaluation ordering and predictable performance, help the ergonomics of the language without losing out on anything significant.

---

From the language designer's perspective, it may also be the case that Haskell has so thoroughly occupied that particular niche in the design space that making a whole new language just isn't worthwhile. Some GHC extensions could well be different languages, and we just call them all "Haskell" for social reasons.
> **Comments:**
> **username_4** (2023-05-25): I would add difficulty of debugging as a downside of laziness. Also, on the unscientific side, Simon Peyton-Jones used to say that if he had to do it again, he'd make Haskell strict (I don't know if he wrote it down somewhere). On the other hand, in terms of language design, being able to encode control structures as ordinary functions is a benefit: it does make the language simpler to use for simple things like an `if` “statement” which can be an ordinary expression.  
> **username_1** (2023-05-25): "GHC does a lot of (ongoing!) work to get acceptable performance" — GHC performance is **excellent** and very impressive. One time I easily outperformed Rust on a lambda (Krivine) machine implementation. :D  
> **username_1** (2023-05-25): @Gilles'SO-stopbeingevil' "Simon Peyton-Jones used to say that if he had to do it again, he'd make Haskell strict (I don't know if he wrote it down somewhere)" I remember reading Peyton-Jones saying if they'd made Haskell strict, they would dream of a lazy version in the same way now we're dreaming about a strict one. :)  
> **username_5** (2024-02-22): I am sure that fiexd evaluation ordering is bad for automatic parallelization and note that non strict evaluation allows for that every program if terminates will terminate, which is not guaranteed in strict evaluation  
---
