MILU and force in Purescipt warning logger

[tomjaguarpaw]

@rhendric

@tomjaguarpaw

implying “assume we don’t want to MILU”, which defeats the point of the discussion.

I don’t know why it would imply that!

Sorry, I miscommunicated here. I should have said

I’d like to challenge this assumption, firstly because if there are good reasons then I’d value being enlightened about them, and secondly because if there aren’t good reasons then it seems to be implying “assume we don’t want to MILU”, which defeats the point of the discussion.

Does that resolve the remaining issues related to that sentence?

@rhendric

@tomjaguarpaw

“laziness causes difficulty reasoning about time and space usage of Haskell programs” is a very common refrain from Haskell detractors in online discussions, and dispelling this myth is one of the most important hurdles to overcome if we want Haskell to be adopted more widely.

‘Laziness doesn’t cause problems; using laziness causes problems’ strikes me as a very fine hair to split, which makes me think I’ve misunderstood you. Telling a new Haskell adopter not to make anything lazy unless they already know the reason they need it is functionally identical to telling adopters not to use laziness, because of course they aren’t going to know why they might benefit from it—they’re new!

This particular issue is quite subtle. To reiterate and clarify further, my main goal of promoting MILU is to establish a shared understanding of a characterization of programs which largely eliminates the performance and memory usages downsides of laziness whilst largely preserving the compositionality benefits. In particular I want to dispell the reputation that Haskell has that it is hard to reason about performance and memory usage because Haskell is a lazy language. Here are some examples from Algolia’s Hacker News search:

I often hear about performance/memory usage pitfalls with Haskell laziness

– https://news.ycombinator.com/item?id=1456979

purely functional design … makes it hard to reason about performance (especially memory, and most especially if you throw laziness in the mix).

– https://news.ycombinator.com/item?id=38419647

the drawbacks [of laziness] are significant, performance, memory usage, and debugging can all be a real pain

– https://news.ycombinator.com/item?id=35803884

In Haskell, laziness … can cause … nondeterministic performance, memory usage, GC pressure. “Space leaks” can also occur …

– https://news.ycombinator.com/item?id=29192708

I believe this reputation significantly reduces the chance of curious people trying out Haskell, and improving this reputation would have massive benefits for the community as a whole.

Now, regarding the part of my comment that you quoted above, reputedly, the performance and memory usage of Haskell code is hard to reason able because of laziness per se. I am trying to challenge this by responding “no, it’s because of inappropriate laziness that you didn’t want and weren’t benefitting from anyway”.

So I don’t think I’m trying to split a hair, but I am trying to thread a needle. On one side are non-Haskellers who think that being lazy by default makes Haskell essentially unusable. On the other side are (a subset of) Haskellers who think that challenging anything to do with laziness is blasphemy (I’m not referring to anyone engaged in recent discussions here). I’m trying to take a middle path by suggesting that the whole discussion can be finessed by appropriate design of data types.

@rhendric

If this were a cheap (< 1 day of work) experiment to try, I’d do it and report back.

Yes, fair enough.

@rhendric

pairs and Maybes and Eithers that would need to be swapped for strict counterparts out of one of the packages that do this (and, inevitably, need to get missing instances and missing API functions reimplemented

On this specific point, I developed strict-wrapper: Lightweight strict types to make exactly this kind of thing easier. By its nature there shouldn’t be any missing API functions, because the whole point is lightweight conversion to the lazy version. (I know for a fact there are missing instances though. I should add them.)

@rhendric

Unsatisfying conclusion, I know. But that’s why I think it’s important to tell Haskell beginners about what deepseq can do for them. Because real-world Haskell programming will often involve years-old projects with hundreds of modules that can’t all be converted to strictness on a hunch, and ‘make it work’ comes before ‘make it right’ and ‘make it fast’.

There’s a lot left unspecified there. Who are these beginners, how are they learning, what do they have to delay learning if they learn about deepseq instead (if anything)? It’s very hard to make a precise claim without knowing much more context. Instead, here’s a precise situation that I hope is easier to debate:

When Optimiser performance problems - #10 by emiruz was posted, it would have been most helpful to the poster, and to the community as a whole, if someone had replied

Yes, Data.Vector can store thunks. Use Data.Strict.Vector instead.

and the discussion about space leaks and laziness had ended there.

I claim yes, because it’s a simple solution that extends to the vast majority of situations that new users will encounter and it avoids overwhelming them with “an eye-watering number of methods” that will just confuse and disappoint them (and, I believe, lead to attrition from Haskell).

Regarding the Purescript situation, using force seems better than doing nothing, and also seems better than an invasive investigation if there aren’t the resources to perform that investigation. This suggests that it’s good for Haskellers to learn about and use force sometimes. Where we draw the line is open for debate. I made the claim above to help the debate.