Live data from Hacker News

A visual demo of Ruby's lazy enumerator

joyofrails.com

11–20 of 28 posts

Re: A visual demo of Ruby's lazy enumerator

#11
post #10
post #6

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. Some examples: I wrote a utility gem a while ago that lets you lazily intersect, union, etc various potentially infinite streams of data. https://github.com/maxim/enum_utils/ I also used lazy enumeration for traversing the wordmap…

In the worst case, that must have intermediate space requirements equal to the entire collections, right?

I don’t think that can happen because all those functions assume the streams are consistently sorted.

Re: A visual demo of Ruby's lazy enumerator

#12
post #6

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. Some examples: I wrote a utility gem a while ago that lets you lazily intersect, union, etc various potentially infinite streams of data. https://github.com/maxim/enum_utils/ I also used lazy enumeration for traversing the wordmap…

How is it different than a window, rolling window?

Re: A visual demo of Ruby's lazy enumerator

#13
post #11
post #10

Earlier quoted context omitted.

In the worst case, that must have intermediate space requirements equal to the entire collections, right?

I don’t think that can happen because all those functions assume the streams are consistently sorted.

Ohhhhh, nice. Yeah, sorted data is powerful. Thanks for pointing that out.

Re: A visual demo of Ruby's lazy enumerator

#14
post #6

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. Some examples: I wrote a utility gem a while ago that lets you lazily intersect, union, etc various potentially infinite streams of data. https://github.com/maxim/enum_utils/ I also used lazy enumeration for traversing the wordmap…

How is it different than a window, rolling window?

It's probably a version of that. But since data is assumed sorted, memory requirements almost never grow beyond one item per stream.

Re: A visual demo of Ruby's lazy enumerator

#15
post #7

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. Nevertheless, this was great.

Thanks for the feedback. I was thinking along those lines but settled on a version that let you toggle between the two. I’ll keep this in mind for next time though. There are probably a lot of fun variations to explore. Since this post seemed to resonate, I may be motivated to try some more experiments.

I find horizontal/vertical is usually confusing (not to you obviously). Here is an example: https://www.investopedia.com/terms/h/horizontalanalysis.asp Maybe easier to stick with the lazy/eager wording?

Re: A visual demo of Ruby's lazy enumerator

#17
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)

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". (https://news.ycombinator.com/item?id=14011943)

Re: A visual demo of Ruby's lazy enumerator

#18
post #15
post #7

Earlier quoted context omitted.

Thanks for the feedback. I was thinking along those lines but settled on a version that let you toggle between the two. I’ll keep this in mind for next time though. There are probably a lot of fun variations to explore. Since this post seemed to resonate, I may be motivated to try some more experiments.

I find horizontal/vertical is usually confusing (not to you obviously). Here is an example: https://www.investopedia.com/terms/h/horizontalanalysis.asp Maybe easier to stick with the lazy/eager wording?

That’s fair. I acknowledge that terms like "horizontal" and "vertical" may be overloaded or even confusing, in this case, if it’s difficult to see the connection with the visuals. This is somewhat part of the risk in trying to explain a concept in a less-than precise way to introduce a new concept.

Re: A visual demo of Ruby's lazy enumerator

#19
post #17

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) 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 (…

Laziness is great for collections, and modeling the infinite but as a general model for programming it's a little loopy for my taste too ;-)

Re: A visual demo of Ruby's lazy enumerator

#20
post #7

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. Nevertheless, this was great.

Thanks for the feedback. I was thinking along those lines but settled on a version that let you toggle between the two. I’ll keep this in mind for next time though. There are probably a lot of fun variations to explore. Since this post seemed to resonate, I may be motivated to try some more experiments.

Your site is broken...
Post reply on HN