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'm sure I'd get some things about python wrong.  (I find it notable how few people there are that are actually familiar with both).The standard alternative to `for` in ruby does involve `each` and blocks... but definitely doesn'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!But the basic principle stated "Instead of passing data back to the for loop (Python) you pass the code to the data (Ruby)" -- is more or less accurate.blocks -- syntactic support in the language for cleanly passing a single in-line defined lambda/closure object as an argument -- are possibly the thing that are most special to ruby.> Python builds on for-like constructs for all kinds of processing; Ruby pushes other kinds of data processing work to methods.OK, maybe, although not totally sure what you mean.> 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:Um. I'm not sure where the author is getting this. It is certainly possible, as shown, but definitely not common to implement `select` or `map` or other methods provided by Enumerable directly on your custom class. It is a bit more common to implement `each` alone and let the `Enumerable` mixin provide the rest.  But even that I'm not sure how "common" I'd call it.> 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.OK, true. The author is getting the details wrong, but I guess their overall picture is still right?