Hacker News Reader

I'm not an OCaml or Haskell expert, but I expect that laziness makes performance harder to reason about?

Edit: but in this case, apparently the book was written for a course at Cornell where they teach both functional and imperative programming using the same language.

View on HN

In my experience, reasoning about (or maybe being able to manage) memory consumption is more of an issue for fully lazy languages.

Having worked on a code-base written in a lazy (Haskel-like) FPL where the architecture relied heavily on laziness, the least pleasant issue to deal with was sudden and obscure explosions in memory consumption.

Which would of course have a big impact on performance so maybe this was your point also.

That’s been my experience. Across the spectrum of languages I’ve found certain features such as dynamic memory, managed memory, memory safety, evaluation model, etc all have an impact on the transparency of understanding time and space characteristics. I spend most of my time in assembly and C, but love the sheer ranges of language options we have today. I put Haskell in the “Miranda” branch of languages which I love for tackling some problems but day to day but I’ve never got a handle on how that translates into predictable characteristics of the generated code.

Reply on news.ycombinator.com