4 ms·

Bryan Cantrill's take: https://youtu.be/0T2XFSALOaU?t=2021 https://youtu.be/0T2XFSALOaU?t=2021 My answer would be lazy evaluation by default. It's extremely un

Bryan Cantrill's take: https://youtu.be/0T2XFSALOaU?t=2021 https://youtu.be/0T2XFSALOaU?t=2021 My answer would be lazy evaluation by default. It's extremely unusual, and I've never seen a convincing enough justification for it, and it gives rise to performance bugs (space leaks) that can be fiendishly difficult to track down and fix and are disastrous in production. With the arrival of Idris, I think we can pretty conclusively say this was a mistake and that the Miranda branch of the PL family tree is likely to prove to be an evolutionary dead-end.

Tyr42 10y ago
My perspective on this is that lazy be default made sticking to purity much more compelling as if you just dropped print statements in you weren't sure exactly when they get evaluated. This lead to important developments like IO (they started with user input just being a lazy list! Very possible to accidentally block trying to read too much), which might not have happened otherwise. But now, I do feel like lazy is best kept for core data-structures and places where you know you can use it, and a strict by default variant of Haskell would be better, now that we have learned most of the lessens from lazyness.
- oldmanmike 10y ago
  "My perspective on this is that lazy be default made sticking to purity much more compelling as if you just dropped print statements in you weren't sure exactly when they get evaluated." And that's basically a death sentence to the feature because it reduces it to a silver lining of desperate post-mortem optimism. As far as my understanding goes, lazy evaluation was originally included in the language because it was perceived to be a powerful optimization technique enabled by pure functional programming. You reduce the amount of work a program is doing dynamically at runtime while not trading off on readability or modularity. All win. Except there were subtle trade-offs that have made themselves clear over the years and like you said, most would agree that lazy-by-default is too extreme of a feature and doesn't really pay its share of the rent at the end of the day. My main gripe with lazy evaluation is that it's implicit behavior. It's to evaluation what garbage collection is to memory or dynamic types are to types. It hides something from the programmer that is useful to know more often than not.
  - js8 10y ago
    > My main gripe with lazy evaluation is that it's implicit behavior. It's to evaluation what garbage collection is to memory Are you saying you would like to return to the languages with explicit memory management? Or why is, generally speaking, GC considered good and LE considered bad?
    - oldmanmike 10y ago
      > Are you saying you would like to return to the languages with explicit memory management? Not really, but that does seem to be the logical conclusion at the end of the day. Haskell makes a really good case for the use of a garbage collector via pure functional programming, but I'm open to more fine-grain programmer-driven mechanisms for handling memory. I need to try out Rust's borrowing system on a meaningfully large project before I can start saying anything conclusive.
- tene 10y ago
  > a strict by default variant of Haskell would be better https://ghc.haskell.org/trac/ghc/wiki/StrictPragma https://ghc.haskell.org/trac/ghc/wiki/StrictPragma is coming in GHC 8.
  - POSIXprog 10y ago
    > The extension only affects definitions in this module. Functions and data types imported from other modules are unaffected

Tyr42 10y ago

My perspective on this is that lazy be default made sticking to purity much more compelling as if you just dropped print statements in you weren't sure exactly when they get evaluated. This lead to important developments like IO (they started with user input just being a lazy list! Very possible to accidentally block trying to read too much), which might not have happened otherwise. But now, I do feel like lazy is best kept for core data-structures and places where you know you can use it, and a strict by default variant of Haskell would be better, now that we have learned most of the lessens from lazyness.

oldmanmike 10y ago
"My perspective on this is that lazy be default made sticking to purity much more compelling as if you just dropped print statements in you weren't sure exactly when they get evaluated." And that's basically a death sentence to the feature because it reduces it to a silver lining of desperate post-mortem optimism. As far as my understanding goes, lazy evaluation was originally included in the language because it was perceived to be a powerful optimization technique enabled by pure functional programming. You reduce the amount of work a program is doing dynamically at runtime while not trading off on readability or modularity. All win. Except there were subtle trade-offs that have made themselves clear over the years and like you said, most would agree that lazy-by-default is too extreme of a feature and doesn't really pay its share of the rent at the end of the day. My main gripe with lazy evaluation is that it's implicit behavior. It's to evaluation what garbage collection is to memory or dynamic types are to types. It hides something from the programmer that is useful to know more often than not.
- js8 10y ago
  > My main gripe with lazy evaluation is that it's implicit behavior. It's to evaluation what garbage collection is to memory Are you saying you would like to return to the languages with explicit memory management? Or why is, generally speaking, GC considered good and LE considered bad?
  - oldmanmike 10y ago
    > Are you saying you would like to return to the languages with explicit memory management? Not really, but that does seem to be the logical conclusion at the end of the day. Haskell makes a really good case for the use of a garbage collector via pure functional programming, but I'm open to more fine-grain programmer-driven mechanisms for handling memory. I need to try out Rust's borrowing system on a meaningfully large project before I can start saying anything conclusive.
tene 10y ago
> a strict by default variant of Haskell would be better https://ghc.haskell.org/trac/ghc/wiki/StrictPragma https://ghc.haskell.org/trac/ghc/wiki/StrictPragma is coming in GHC 8.
- POSIXprog 10y ago
  > The extension only affects definitions in this module. Functions and data types imported from other modules are unaffected