Hacker News Reader

Comment by MBCook | Hacker News Reader

Is be curious to know how big a problem laziness is in real applications. Is it mostly a non-issue because in a web app things tend to be short requests or do you end up having to use seq and force strictness in many places?

View on HN

By and large you can ignore laziness without issue. Multi-threading is, ironically, one of the first places you might see an issue as you must guarantee where evaluation occurs and how far.

Other than that the major risk is of a space leak. In a web service model you generally won't write the sever or the database connection and therefore will be masked from long-running memory hog computations.

I'm sure it depends on your programming style, but my experience is that you can almost always ignore laziness and focus on getting your work done.

Haven't run into issues with laziness yet, but, as you guys pointed out, our use-case is very short-lived. We can likely get away with some sloppiness here and there because of it. I'm sure I'll still get burned by this at some point, but at least I'll be expecting it to some extent.

It depends on what you're doing. I've been doing Haskell full-time for the last five years and the vast majority of the time I haven't had to think about laziness. But there have been a handful of places where I did need to think about it. It's certainly possible that those situations will be much more common in some types of work. But I think if you average over the whole software industry you probably won't need to think about it very often.

We[1] used to think that you do not need to worry about lazyness, too - but ran into massive issues with large memory usage and massive GC pauses. We introduced a policy that all fields of a data type must be strict (no Lists, no Maybe, no Either, ..., all custom strict types). That solved the issue for us.

[1]: http://cpmed.de/

Reply on news.ycombinator.com