5 ms·

Haskell is an experiment on having laziness at language level. This experiment clearly shows, that laziness on language level is a bad idea.You can get all the

by sesm 2y ago

Haskell is an experiment on having laziness at language level. This experiment clearly shows, that laziness on language level is a bad idea.You can get all the benefits of laziness at standard library level, as illustrated by Clojure and Twitter Storm using it in production. All the other FP stuff (union types, etc) existed before Haskell in non-lazy FP languages.

agentultra 2y ago
There’s a strong case that laziness should be the default: https://m.youtube.com/watch?v=fSqE-HSh_NU https://m.youtube.com/watch?v=fSqE-HSh_NU I’m not sure I’m experienced enough in PLT enough to have a strong opinion myself. However, from experience, laziness has a lot of advantages both from a program construction and performance perspective.
kccqzy 2y ago
Laziness is but one mistake in Haskell. It should not prevent you from using other parts of the language that are wonderful. There's a reason Mu exists, which is to take Haskell and make it strict by default: there are plenty of good things about Haskell even if you consider laziness to be a mistake. (Of course a small minority of people don't consider laziness as a mistake as it enables equational reasoning; let's not go there.)
- tome 2y ago
  Having used Mu I concluded that Haskell got function laziness correct. (Data type laziness is a different issue, but that can be solved by `StrictData`).
  - kccqzy 2y ago
    The problem with StrictData is that you need to convince every library in your dependency graph to switch to it, or provide strict versions of the data structures. Common container types like Map and Set do this. Your typical library implementing a domain-specific functionality does not.
    - tome 2y ago
      Yup, that's right. Libraries can expose the wrong thing, or just space leak internally. Here's an example: https://github.com/mrkkrp/megaparsec/issues/486 https://github.com/mrkkrp/megaparsec/issues/486
iainmerrick 2y ago
Right, I was surprised I had to scroll down here so far to see the first mention of laziness; it's the core feature of Haskell (copied from Miranda so researchers had a non-proprietary language to build their work on). From everything I've ready about people's experiences with using Haskell for large projects, it sounds like lazy evaluation unfortunately adds more problems than it removes.
whateveracct 2y ago
> This experiment clearly shows, that laziness on language level is a bad idea. This is quite the claim. I know plenty of experienced and productive Haskellers who disagree with this (myself included)
louthy 2y ago
I don't see laziness as a problem in Haskell, especially as you can opt out of laziness altogether, or partially. In practice I found that `StrictData` solves pretty much every issue.

by sesm 2y ago

agentultra 2y ago

There’s a strong case that laziness should be the default: https://m.youtube.com/watch?v=fSqE-HSh_NU https://m.youtube.com/watch?v=fSqE-HSh_NU I’m not sure I’m experienced enough in PLT enough to have a strong opinion myself. However, from experience, laziness has a lot of advantages both from a program construction and performance perspective.

kccqzy 2y ago

Laziness is but one mistake in Haskell. It should not prevent you from using other parts of the language that are wonderful. There's a reason Mu exists, which is to take Haskell and make it strict by default: there are plenty of good things about Haskell even if you consider laziness to be a mistake. (Of course a small minority of people don't consider laziness as a mistake as it enables equational reasoning; let's not go there.)

tome 2y ago
Having used Mu I concluded that Haskell got function laziness correct. (Data type laziness is a different issue, but that can be solved by `StrictData`).
- kccqzy 2y ago
  The problem with StrictData is that you need to convince every library in your dependency graph to switch to it, or provide strict versions of the data structures. Common container types like Map and Set do this. Your typical library implementing a domain-specific functionality does not.
  - tome 2y ago
    Yup, that's right. Libraries can expose the wrong thing, or just space leak internally. Here's an example: https://github.com/mrkkrp/megaparsec/issues/486 https://github.com/mrkkrp/megaparsec/issues/486

iainmerrick 2y ago

Right, I was surprised I had to scroll down here so far to see the first mention of laziness; it's the core feature of Haskell (copied from Miranda so researchers had a non-proprietary language to build their work on). From everything I've ready about people's experiences with using Haskell for large projects, it sounds like lazy evaluation unfortunately adds more problems than it removes.

whateveracct 2y ago

> This experiment clearly shows, that laziness on language level is a bad idea. This is quite the claim. I know plenty of experienced and productive Haskellers who disagree with this (myself included)

louthy 2y ago

I don't see laziness as a problem in Haskell, especially as you can opt out of laziness altogether, or partially. In practice I found that `StrictData` solves pretty much every issue.