2 ms·

It seems we have have got a bit off track and my quite precise claims have got lost. My claims are that 1. It is incorrect to claim that "Laziness is very har

by tome 9y ago

It seems we have have got a bit off track and my quite precise claims have got lost. My claims are that 1. It is incorrect to claim that "Laziness is very hard to get right in practice. ... It's the reason why ... Standard Chartered, uses their own Haskell compiler that's strict by default." 2. Rather, the reason Mu is strict is that it was designed to target an existing strict runtime (I offer this claim without proof but I was told this directly by one of the authors of Mu). 3. It is incorrect to claim that Standard Chartered "think strict haskell is a lot easier to deal with" 4. Rather, Lennart Augustsson holds that each has their upsides and downsides. He says "I don't think strict or lazy matters that much in practice; they both work fine" and "I think laziness is a much nicer way of programming except for these pesky resources."

chillee 9y ago
My claim that Standard Chartered thinks "strict haskell is a lot easier to deal with" comes from this comment from Lennart. > If my only concern was semantics (i.e., input-output behavior) then I'd prefer call-by-name semantics, because I think it behaves more compositionally. But for practical concerns like resource consumption, debugging, stack trace, etc then strict evaluation is better. Overall though, you're right that my initial claims against strictness may have been a bit too harsh. If I could edit my initial comment, I would write something more like > 2. Laziness is often hard to use in practice. As Standard Chartered, a company that uses a strict variant of Haskell, notes: space leaks, difficulty of debugging, and hard to decipher stack traces are downsides to laziness. In my opinion, laziness definitely does have nicer semantics than strictness. It's more expressive and easier to compose. In practice though, I prefer strict languages mostly for the reasons Standard Chartered mentions.

by tome 9y ago

chillee 9y ago

My claim that Standard Chartered thinks "strict haskell is a lot easier to deal with" comes from this comment from Lennart. > If my only concern was semantics (i.e., input-output behavior) then I'd prefer call-by-name semantics, because I think it behaves more compositionally. But for practical concerns like resource consumption, debugging, stack trace, etc then strict evaluation is better. Overall though, you're right that my initial claims against strictness may have been a bit too harsh. If I could edit my initial comment, I would write something more like > 2. Laziness is often hard to use in practice. As Standard Chartered, a company that uses a strict variant of Haskell, notes: space leaks, difficulty of debugging, and hard to decipher stack traces are downsides to laziness. In my opinion, laziness definitely does have nicer semantics than strictness. It's more expressive and easier to compose. In practice though, I prefer strict languages mostly for the reasons Standard Chartered mentions.