considerations on beautiful and efficient code (on Ruby and algorithms and blocks)

[stefanosc]

Hello @jessitron First of all thank you very much for your presentation, I watched the video and took a look at this repo. I am relatively new to programming: I started studying Ruby a couple of years ago and by now I would say I am rather experienced (I love going deep). I am also keen to learn more about the FP paradigm, at the moment I am still quite new to this.

I noticed a couple of points that you may appreciate considering.

I love how you used lazy I find it a very neat feature of Ruby.
In looking at the rest of the code in stock_stats.rb I noticed that it needs to loop through the entire collection for each piece of the pipeline, namely:

here

total = BookInStock.sum_prices(all_books)

here

qty = all_books.count

and here

errorCount = all_errors.count

My considerations would be:

• Is it really necessary to loop through the entire collection for each feature we add?
• Could we not rewrite the code for example by passing all the "features" we need (methods / funtions) to the loop so that it all gets done only in one iteration?
• Do you see any important FP principle that would need to be considered?

Then, in your comment on the other conversation of this repo, I noticed you asked a question that hasn't not been answered:

• and why "Prefer blocks to lambda/Procs"?

A few weeks ago I posted a comment on linkedin to a rather interested post: Why blocks make Ruby methods 439% slower My comment (it's the 3rd and last one, sorry no URI for comments on linkedin!) further clarifies the great analysis posted on omniref and I would say it's the perfect answer to your question on blocks and lambda/Procs

I know this is an old repo and I understand If you "moved on" in the meantime, and don't have much time to answer. I would love to hear your thoughts!

[jessitron]

Wow thanks!

Your considerations are very accurate. In my work I usually ignore performance considerations in favor of exploring "how could this be useful?" figuring, if it's useful, only then it will be worth digging into performance.

About doing all the work in one iteration: absolutely, you're right. This is something people are doing. Reducers and transducers in Clojure do this, Java 8 streams do this. They build up a function, and then only when someone asks for the answer is the function executed, and only one iteration happens. No intermediate sequences are instantiated.

For digging into FP, you might try the book Functional Programming in Scala - it's more about high-level functional concepts and rigorous typing than about Scala. It shows the side of Scala that's most opposite of Ruby. If you work through that you'll have two very different perspectives to program from.

Thanks for the link, too. That's a great explanation in your comment.

[stefanosc]

@jessitron great to hear from you, thank you for your response!

I know almost nothing about clojure but took a quick look at reducers and transducers and it looks pretty awesome. I am currently stretching into python (and studying algorithms) for another project, but I have in my "todo" to learn FP ! Thank you for the book recommendation, it's funny that I came across it the other day while exploring new interesting readings.

If I was in Chicago area I would love to attend SICP Chicago w/ Dave Astels it is organized by fellow DevBootcamp alumni (I was in one of the last cohorts of last year..) And LambdaJam (that's how I found you!) sounds awesome too.

I am moving to the Bay Area, so I will see if there are similar initiatives around SF, if you have any suggestion please let me know.

Again, thank you for your response. Have a great day