News for hackers. Stuff that matters.
Re:Haskell: The Bad Parts, part 2 (2020) by cies on Tuesday February 09, 2021 @12:15PM (#26080016)
I understand the historic context of laziness, and what it "brought" or "taught" us. But is it really that important now, or moving forward? I side with Snoyman in the "strict by default would probably be better".

Sure it's no longer Haskell then. But could there not be a language like Haskell leveraging strict by default? Possibly even on the GHC?

Re:Haskell: The Bad Parts, part 2 (2020) by PhineasRex on Tuesday February 09, 2021 @06:36PM (#26084010)
Making Haskell strict-by-default would also break the rewrite engine which is the core of Haskell's high performance with functional combinators.

The whole haskell project is about allowing programmers to write code that is declarative without making concessions for performance. Laziness makes this possible because it abstracts out evaluation order and thus allows extreme optimization by the compiler

Re:Haskell: The Bad Parts, part 2 (2020) by rowanG077 on Thursday February 11, 2021 @03:37PM (#26106787)
I don't see how the rewrite engine would break if Haskell would be strict. Can you expand on that?
Re:Haskell: The Bad Parts, part 2 (2020) by pera on Tuesday February 09, 2021 @01:38PM (#26081021)
Idris for instance is strict "by default" but still supports laziness through the Lazy data type.
Re:Haskell: The Bad Parts, part 2 (2020) by cies on Tuesday February 09, 2021 @02:23PM (#26081473)
Forgot about Idris.

Elm, PureScript, OCaml (Reason/ReScript) and F# did come to mind.

Re:Haskell: The Bad Parts, part 2 (2020) by cycloptic on Tuesday February 09, 2021 @12:28PM (#26080187)
Isn't that basically every other ML variant?
Re:Haskell: The Bad Parts, part 2 (2020) by wk_end on Tuesday February 09, 2021 @01:54PM (#26081184)
Not exactly. Syntax-aside, MLs in general: have better module systems than Haskell, no typeclasses, and aren’t pure.