Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>First of all, <a href="http://en.wikipedia.org/wiki/Lazy_evaluation" rel="nofollow noreferrer">lazy evaluation</a> wasn't invented in Haskell, it's incorrect to attribute it like so.</p> <p>Second, Haskell has eager evaluation (the opposite; evaluate when referred) possibilities too.</p> <p>Third, lazy evaluation facilities are easily available in other languages and technologies too; Python's generators (recall the <code>xrange</code> function), Meyers singleton and template instantiation in C++, delayed symbol resolution in runtime linkers -- are all examples of this idea.</p> <p>So anyway, accomodating that idea and corresponding vocabulary will never be harmful to a software engineer.</p> <p>As to the pros &amp; cons, you named the primary ones. There can be named a few more (remember, you can do these in virtually any language with data structures and function calls):</p> <ul> <li><p><a href="http://www.haskell.org/haskellwiki/Tying_the_Knot" rel="nofollow noreferrer"><strong>Recursive datastructures</strong></a>, where you can create, for example, a list value with elements arranged in a cirle, the head being the <code>next</code> element of the "last" one; traversing such a list would yield an infinitely repeating sequence of elements. Probably not the most motivating example, but you can do the same with trees, graphs and so on.</p></li> <li><p>Arranging <strong>control flow</strong> with lazy data structures instead of built-in primitives; think of building <a href="http://en.wikipedia.org/wiki/Coroutine" rel="nofollow noreferrer">coroutines</a> with just lazy lists. This is actually the other side of the coin of more complex and convoluted evaluation order (i.e. one of your <em>contra</em> being an advantage).</p></li> <li><p>Semi-<strong>automatic parallelisation</strong> of computations. This is more of the <a href="https://stackoverflow.com/questions/210835/what-is-referential-transparency">referential transparency</a>'s advantage rather than lazy evaluation; but still, the features fuse together very organically.</p></li> <li><p>Performance-wise, <strong><a href="http://en.wikipedia.org/wiki/Memoization" rel="nofollow noreferrer">memoization</a></strong> often comes to mind when musing on lazy evaluation; although doing it automatically is a hard (probably still unsolved) problem with lots of details and pitfalls.</p></li> </ul> <p>So, basically, if you look at it deeper, every aspect comes with possibilities and trade-offs; your task as a software engineer is to know all of these and choose wisely based on concrete problem details.</p>
    singulars
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
    2. VO
      singulars
      1. This table or related slice is empty.
    3. VO
      singulars
      1. This table or related slice is empty.
    1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload