When I learned Haskell in college I was blown away by how laziness enables cool things like dealing with infinite lists or more performance even though the UX is exactly the same. (Apparently with Ruby there is the slight hint of adding the lazy method in between)<p>Later I found out laziness in the whole system by default leads to some difficult issues, which quite a few people seem to agree with. Simon Peyton Jones (Haskell co-creator) apparently has said "The next Haskell will be strict". (<a href="https://news.ycombinator.com/item?id=14011943">https://news.ycombinator.com/item?id=14011943</a>)
Really cool visualization and neat to learn about lazy enumeration!<p>Excuse me while I go back through my code and make sure I’m using lazy enumeration wherever I’m iterating over large collections….
Lazy enumeration can also save memory, because you aren’t storing entire collections during intermediate steps, and it works with infinite/unknown size collections. Such as streaming data.<p>Some examples:<p>I wrote a utility gem a while ago that lets you lazily intersect, union, etc various potentially infinite streams of data. <a href="https://github.com/maxim/enum_utils/">https://github.com/maxim/enum_utils/</a><p>I also used lazy enumeration for traversing the wordmap in my no-RAM static storage gem. <a href="https://github.com/maxim/wordmap/">https://github.com/maxim/wordmap/</a>
So in Ruby, `map` and `select` are eager-by-default, but you can just write `lazy.map().select()` to make the <i>whole chain</i> lazy? That's really nice - much better than Python 2, which was also eager-by-default and you had to change every function call to make it lazy (`map` => `imap`, `filter` => `ifilter`).<p>Python 3 changed to being lazy-by-default. I assume that improves CPU/memory usage, but in some cases it does have less predictable behaviour. I can see why Ruby, with its goal of "developer happiness", would choose to retain the predictable behaviour of eager-by-default.
I was expecting a visual comparison towards the end of the article, where you would be able to click a button and both the eager and lazy versions would start executing simultaneously, one displayed next to the other, and you would clearly see that the lazy one completed earlier. This would make it even more obvious how the lazy one is faster.<p>Nevertheless, this was great.
Java Streams and Kotlin Sequences provide similar iterator capabilities. Iterators are great for this lazy performance but can sometimes be difficult to debug. Especially if you are nesting many iterators, then extracting the underlying collection can be complicated. But necessary in many workflows.