Hacker News Reader

Comment by theseoafs | Hacker News Reader

I see no reason why strictness would have pathological performance problems. If you don't need to compute a value, dinner compute it. No performance problems.

I also see no reason you would need laziness for 5% of programming problems. That seems absurd given that the overwhelming majority of programmers have gotten along without it for 50 years.

View on HN

Most programmers use laziness all over the place, they unfortunately have few tools for introducing it, and thus don't recognize it as such.

For example in C/C++ your only ability to introduce laziness is via manual thunking, if, or the logical conjunctive (&&), and disjunction (||) which have non-strict semantics. For example you often see the idiom of:

    if (x != NULL && x.foo == bar) { ... }

Which relies on (&&) being lazy in its second argument. Lazy languages allow one to write things like && and if without needing them baked in. For example:

    until :: Bool -> a -> a -> a
    until b t f = case (not b)
      True -> t
      False -> f

>I see no reason why strictness would have pathological performance problems. If you don't need to compute a value, dinner compute it. No performance problems.

You just answered your own question. "If you don't need to compute a value, then don't compute it" is laziness.

>That seems absurd given that the overwhelming majority of programmers have gotten along without it for 50 years.

No they haven't. Most programmers don't understand it, but they tend to use it on a regular basis.

> You just answered your own question. "If you don't need to compute a value, then don't compute it" is laziness.

No -- "laziness" is saying "the programmer wants us to compute this value, but we don't need it just yet, so we're going to create a thunk that will sit on the heap until it's evaluated or garbage collected". Strictness is doing what the programmer says, which involves the programmer deciding what does and does not have to be computed while he's writing the program.

Perhaps I was not clear. You stated the very reason for laziness: to not compute things you don't need computed. There are many cases where it is very beneficial to be able to determine this at evaluation time, rather than when writing the code. Hence laziness, and hence it being used all the time in most mainstream languages.

You say it's used all the time -- so how about you give an example of a "lazy" solution to a problem in, say, C?

foo || bar

I implement laziness "manually" all the time in Objective-C.

For example, imagine something happens which invalidates a property which must be calculated (say, a bounding box for a graphical object).

Instead of immediately recomputing it, just set it to nil, and only recompute it the next time the property is actually accessed.

This way you can harmlessly invalidate it multiple times without doing a potentially expensive calculation (which just gets thrown out by subsequent invalidations).

That's not laziness, that's just cache invalidation.

It's fair to say that it's laziness, in my view. That sort of thing is just a manual implementation of what laziness would do in a particular situation. The closure that the thunk would hold is essentially diffused into the object that contains the lazy property.

Java example:

    if (logger.isDebugEnabled())
        logger.debug("..." + ...);

A fast sorting algorithm in Haskell degrades gracefully to a (faster) selection algorithm when you don't ask for the whole thing.

In other words, "sort lst" gives you a sorted list, but "take 5 (sort lst)" gives you the first five elements, without sorting the rest of the list.

SomeObjec *getObject(){ if (!theObject) theObject = createObject();

return theObject; }

Reply on news.ycombinator.com