Ruby vs. Python comes down to the for loop
This was definitely written by a pythonist!  If I tried to write it, as a rubyist, I&#x27;m sure I&#x27;d get some things about python wrong.  (I find it notable how <i>few</i> people there are that are actually familiar with both).<p>The standard alternative to `for` in ruby does involve `each` and blocks... but definitely doesn&#x27;t involve defining a custom `each` method on your class... That is a specialty thing that most developers have probably done rarely.  Let alone defining it in terms of `for`, which is just weird!<p>But the basic principle stated &quot;Instead of passing data back to the for loop (Python) you pass the code to the data (Ruby)&quot; -- is more or less accurate.<p>blocks -- syntactic support in the language for cleanly passing a single in-line defined lambda&#x2F;closure object as an argument -- are possibly the thing that are most special to ruby.<p>&gt; Python builds on for-like constructs for all kinds of processing; Ruby pushes other kinds of data processing work to methods.<p>OK, maybe, although not totally sure what you mean.<p>&gt; Ruby keeps going with its methods-first approach, except instead of each we have a new set of methods commonly implemented on collections, as below:<p>Um. I&#x27;m not sure where the author is getting this. It is certainly possible, as shown, but definitely <i>not</i> common to implement `select` or `map` or other methods provided by Enumerable directly on your custom class. It is a <i>bit</i> more common to implement `each` alone and let the `Enumerable` mixin provide the rest.  But even that I&#x27;m not sure how &quot;common&quot; I&#x27;d call it.<p>&gt; Ruby, however, inverts this. Ruby puts object-orientation as the foundation of the pyramid. Ruby contains the messy procedural world in blocks, letting objects work with those procedural blocks.<p>OK, true. The author is getting the details wrong, but I guess their overall picture is still right?