Haskell: The Bad Parts, part 2 (2020)

Re:Haskell: The Bad Parts, part 2 (2020) by massysett on Tuesday February 09, 2021 @10:32AM (#26078597)

Laziness - or more precisely, non-strictness - is the essence of Haskell. Haskell was created because there were a bunch of non-strict languages out there, and folks saw a need for one non-strict language to rule them all.

Often a defining feature of Haskell is thought to be its purity. Purity arose from non-strictness. Monadic IO arose from non-strictness (other solutions to IO were also tried.)

This is best discussed in a paper: https://www.microsoft.com/en-us/research/wp-content/uploads/...

I guess you could make Haskell strict by default...but why? It wouldn't be Haskell anymore. Non-strictness is the defining element of the language. In my view a strict-by-default Haskell is...something else. Maybe it's better for certain things. Maybe it takes things to the next level. But it isn't Haskell. Don't call it that.

[ Parent | on HN ]

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?

[ Parent | on HN ]

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

[ Parent | on HN ]

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?

[ Parent | on HN ]

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.

[ Parent | on HN ]

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.

[ Parent | on HN ]

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?

[ Parent | on HN ]

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.

[ Parent | on HN ]

Re:Haskell: The Bad Parts, part 2 (2020) by rtpg on Tuesday February 09, 2021 @10:34AM (#26078635)

I think what’s being proposed around “strict data fields by default” (or, an alternative or “some new concept that evokes strictness where it makes sense”) could let us continue to use Haskell and its laziness.

This isn’t really obvious to me but I think you could build a mixed reality without splitting a community up.

[ Parent | on HN ]

Re:Haskell: The Bad Parts, part 2 (2020) by mst on Tuesday February 09, 2021 @11:32AM (#26079424)

"strict-by-default" isn't really the proposal here.

Only "some things' laziness is more a footgun than a feature, maybe we should consider fixing those".

The foldl/sum/product example in part one is maybe clearer about that.

[ Parent | on HN ]

Re:Haskell: The Bad Parts, part 2 (2020) by lmm on Tuesday February 09, 2021 @10:17PM (#26085393)

But once you have purity you don't need strictness - Idris takes that approach.

Implicit, pervasive laziness makes performance non-compositional and more or less impossible to reason about. AIUI the largest industrial deployment of Haskell uses a strict variant for this reason.

[ Parent | on HN ]