Agreed. While I think matz is a great language designer, I loved Alan Kay's philosophy. I'd like some language that is OOP centric in nature, fast, has an elegant syntax and learns from erlang's model (elixir isn't it unfortunately, but some ideas it got right).
If you want OOP than, yes, Elixir isn't it... maybe Pony? Curious what else you don't like about Elixir though besides not being OOP... it's definitely got messaging!
I don’t want OOP. I just want the language to include a system for imposing constraints that prevent entire categories of bugs and make it easier to safely do large scale refactoring.
It’s really hard to go back to living without this once you’re used to it.
Coq, Idris, et. al. are over there if that's what you really want, but there is probably good reason why no "real world" programs are written in languages with proper type systems.
For one, there's little ability to avoid message passing in our modern world. You can take it out of the language, but that just means pushing it to another abstraction (e.g. sockets), and all the same lack of type safety comes right back.
I loved Smalltalk when I had to learn it for my first job out of college. Clean and clear OO with a flexible, play-inside-of-your-code runtime. Unfortunately the Smalltalk community is pretty small.
So imagine my delight when I found Ruby in 2005. It took the best of Perl and the best of Smalltalk and gave it a much better syntax than either, plus it had a massively growing community.
Ruby breaks a lot of the rules for what people claim they want (or should be allowed) from a programming language these days, but for me there’s still no more joyful and easy programming language to express my ideas.
Not all the best parts of Smalltalk, otherwise a IDE based experience with a JIT compiler would be there from the early days, that is an integral part of Smalltalk experience as developer.
I like this article a lot but if you want to dig deeper and understand some of the negative consequences of Ruby's approach, you might like these two articles I wrote:
Love Ruby. Wish I could use it more often. Always end up reaching for Python in day-to-day because of how mature and well-docunented the libs are.
Anyone who likes this kind of stuff, highly recommend Metaprogramming Ruby [2] by Paolo Perrota. Great look into Ruby innards and inspiring code examples. Gets me pumped
It handles 98% of all loops I write, meaning I don't have to manage state (even for things like treating things like circular data). I find it removes many of the stupid errors I make when iterating over data, especially when I need nested loops and conditional accumulation.
I find it so provoking that someone implemented foreach and went "yes. That should be enough for everyone!"
Looping in Ruby is the opposite of awful. You only have to define an `#each` method in your class and include the `Enumerable` module, and you get a plethora of composable methods to iterate and accumulate in every which way. I find it nothing short of brilliant.
Yet, iterating over several collections and accumulating values is awkward.
It is not that it is easy to implement the iteration protocol, it is that the construct for looping universally sucks. Even the awful loop macro from common lisp runs laps around most other facilities. Racket's is even less powerful, but is miles better than what python offers.
Ruby can do some destructuring, but not enough to actually be useful.
It may be somewhat awkward; zipping collections to iterate over them in unison makes the first one (the sender) seem special, while it not necessarily is. And accumulating more than one value isn't always straightforward; you usually have to reduce explicitly. But it's so much better in the general case!
Like the example you showcase your macro with. In Ruby it would be:
You can see what it does at a glance, you don't have to immerse yourself inside the directives to follow the logic. And when you can't do that, declaring iterators and accumulators outside a loop and then iterating and accumulating "by hand" yields code not so different than your more complex examples.
def partition (arr)
yes = []
no = []
arr.each do |elt|
if yield elt
yes << elt
else
no << elt
end
end
[yes, no]
end
Your example of the flatten and grep will build two intermediate arrays before summing. That's inefficient.
I would also reach for higher order functions for most things, but when you need things to be fast that is not how you would do things. You would express it with nested for loops and ifs, and you would have to juggle state all by yourself. That is my main critique of looping constructs: they only cover the absolute simplest case, and then you are by yourself.
The partition example is not a particularly nice implementation of partition. It is there to show that you can write non-tail recursive loops, meaning you can use it to do tree walking and such. Using mutation, like your example, would make it prettier, but would make the code unsafe with schemes call/cc. Even a traditional named let (tail recursion) would be prettier.
For the record, if you want to avoid the creation of intermediate arrays, you can:
lst.lazy.grep(Array).flat_map(&:itself).sum
Not as clear, because the standard library doesn't have a `#flatten` method for lazy enumerators.
But the point is the interface, not the implementation. Efficiency doesn't mandate assembly-like DSLs. Your interface could be as clear and clean as Ruby's and produce fast, inlined code by the power of macros. Ruby doesn't have macros, so chaining lambdas is the best it can do.
Ruby also has call/cc. None of the iterating methods has any provision to make them "safe" from it. They aren't safe from modifications to the iterated collection either. I think it makes sense; being forced to accumulate using only linked lists and having to be constantly on guard to support a rarely used quirky feature is a bad tradeoff IMO.
I dont think interfaces is the point. As it is now in ruby you have to pick between comfort and speed when you can have both.
Continuation safety has never been a thing in ruby, so caring about it doesn't make much sense regardless of the presence of call/cc.
And lastly, neither my loops nor others I have mentioned only accumulate into lists. My loops a re in the most general sense a left fold, although right folds are possible to write as well. I provide accumulators for just about any data type available, and writing a new one yourself is pretty easy. You can express lazy loops with it as well.
All without sacrificing performance. Any performance in most cases. I haven't written much ruby since the 1.9 days, but back then I remember having to rewrite the nice .each{}.blah.blah into for loops. I could prototype in a nice way which was nice, but in the code I ended up shipping I had to juggle state using for loops because the thing I prototyped ended up being a bit slow.
I use map, filter and friends in scheme all the time, but when those are insufficient or too slow I don't have to resort to named lets. I can just use the loop macro which compiles to a named let.
You can iterate over strings and lists and arrays at the same time. You can do destructuring. You can accumulate values in every part of the loop, so if you have subloops you can accumulate values in the outer and inner and every intermediate loop and most important: it builds no intermediate results meaning it will be much faster.
Yes, you can do all that in ruby, plus you can choose to do it lazily such that chaining operations uses generators or by copy at any point so maybe this is a classic case of lispbian hubris.
Listen, my gripe isn't with ruby in particular. It is with every language out there.
Doing it that way is still going to be slower than doing it eagerly with a manual loop. I am not saying ruby should do away with the other ways of doing it. I am saying that ruby - and just about every language out there - should have a powerful looping facility that lets you do it fast without losing comfort.
If I - a non-programmer - could implement it using macros in scheme there is really no excuse for other languages to have such sucky foreach-like constructs.
For the vast majority of situations my goof-loop has no performance penalty compared to rolling the loop yourself. That is what none of the ruby examples I have been given can do. Using zip is not an acceptable way of iterating over 2 collections at once, at least not if you want to pretend to be efficient.
I don't think what I did is particularly good compared to something like the iterate macro, and all I want is for other languages to do better because I rarely have the pleasure of using scheme when doing coding.
Point is simply: No language is special or exceptional. If a language has yield, you can invert to your hearth's content. Even with lambdas/blocks you can invert by calling it in your loop. Speed is left to the efficiency of your jit or typed compilation. For example SBCL is able to compile incrementally by specifying types.
Adding to this: using laziness compared to a while loop in cases where you will process the whole array is just pure overhead.
Heck, testing now on 3.4.4 a while loop is faster than using each. Summing a million numbers (to make the overhead of the different approaches as clear as possible) shows that a while loop is almost 2x faster.
This is what my complaint is about. Why is the fast path so painful to use in so many languages?
Laziness is not free. An eager loop will be faster than a lazy construct, especially languages where the laziness isn't really a first class construct. Like ruby.
Rewriting the code you wrote (or was it the other guy? I am making food so I cant really check) to avoid intermediate collections as a for loop will be faster, especially if you can avoid creating those array pairs.
I am not saying ruby stinks. I am saying it - and just about every other language - is making it unnecessarily hard to write fast code.
> But Python also looks up methods at runtime. Does that mean Python also does message passing? Not quite.
I don't think Ruby's "message passing" is fundamentally different from Python's "method calls". Ultimately, both languages implementations are very similar: both look up methods by name in a hash table and then call them.
IMO "message passing" is just an alternative metaphor for what Ruby does when you type `object.name`. The metaphor fits Ruby but not Python, because the languages do three things differently:
- Ruby only looks for `name` in `object.class` (and its superclasses), whereas Python first looks in `object` itself
- If Ruby finds `name`, it's guaranteed to be a method whereas in Python it could be a different kind of value
- Ruby immediately calls the method once it's found, whereas Python (generally) doesn't - instead it returns a binding to be called later
This means that in Ruby, `object.name` is always calling a method defined on `object.class`, with `self` set to `object`. That can be re-interpreted as "sending a message" to `object.class`.
In Python, `object.name` is a more general value lookup - maybe the result will be callable, maybe not.
> both look up methods by name in a hash table and then call them.
Except Ruby doesn't? cue `method_missing`. If you take only trivial examples you're not going to see much difference, this starts to show when you involve more advanced situations e.g with inheritance, and then you're drilling into singleton classes.
> Ruby immediately calls the method once it's found, whereas Python (generally) doesn't - instead it returns a binding to be called later
Again incorrect, `foo.bar` in Ruby and Python are two very fundamentally different things.
Python returns a binding to a method because it's an attribute accessor; when you throw inheritance into the mix it ends up that that attribute is inherited from the parent class, bound to the instance (which really in python means pass `self` as first argument), and - schematically - adding `()` after that ends up calling that bound method. If there's no attribute that's a no method error. It's all very C-ish and make believe, barely a notch above Go structs and their functions. The closest parallel in Ruby would be `foo.method(:bar).call()`
By contrast Ruby is going to send the :bar message along the inheritance chain, and if someone can respond it's going to invoke the responder's code, and surprise surprise method_missing happens only if it has exhausted inheritance but it's itself a method-slash-message; Oh and by the way the message passing is naturally so lazy that you can actually modify the inheritance chain -in flight- and inject a parent responder right before calling `super`. The whole notion of `binding` is a very concrete construct, way more rich that simply "hey I'm passing self as first argument". It becomes even more strange to "C&al. folks" when you start to involve singleton classes and start to realise weird things like Ruby classes are merely instances of the class Class and it's all instance turtles all the way down and all stupidly simple but you gotta have to wrap your head around it.
I surmise that so many differences and surprises have with Ruby are because most languages have some ALGOL legacy and Ruby is a conceptual heir to Smalltalk (and LISP†); the whole concept of open classes being another one: nothing is ever "finished" in Ruby!
Most of the time you don't have to care about these differences, until you do.
† While code isn't quite S-expr data in Ruby, there are more than enough first-class facilities that you can create and inject code entirely dynamically without resorting to `eval`ing strings.
Nice summary. I've been using Ruby both professionally and not for going on 20 years and I just today learned about singleton_class when attempting to build something like Rails' view helpers from first principles.
Each chapter kind of builds up on the previous one. It's still WIP and far from complete but what's there has helped me onboard a few people to Ruby already.
You might be interested in the Classes and Ancestry chapters.
> If Ruby finds `name`, it's guaranteed to be a method whereas in Python it could be a different kind of value
This is the big difference, Ruby objects have no members other than methods, external entities cannot read data from the object only call methods; the object controls how it responds.
There's ways that seem to bypass this in Ruby, but they are cooperative, relying on calling other methods on the object, like accessing instance variables by calling object.instance_variable_get(:@foo).
But here you refer to implementation details. Isn't the point about message passing that objects themselves communicate with one another through such messages? And in turn, messages can also be assumed to be small objects. I don't think any of those implementations really fulfil that as a meaning. Or perhaps I misunderstood Alan Kay here. He drew inspiration more from biological cells and communication pathways therein. Naturally biology can not be mapped 1:1 onto in-silico hardware, that wouldn't even make sense either - but for instance, erlang's model appears to me closer to different objects happily communicating with one another in a very flexible, safe, fault-tolerant manner. I don't think it is the implementation detail that is about message passing. I also don't think "sending a message" is the confinement either - it's an important but, but does not appear to capture all that is meant with a "message". A message could be many things, including objects that themselves could change at any moment in time again. I see it more as an intrinsic part of communication at all times.
> This means that in Ruby, `object.name` is always calling a method defined on `object.class`, with `self` set to `object`. That can be re-interpreted as "sending a message" to `object.class`.
Ruby Instances can have their own methods and override methods separate from their class.
More precisely, Ruby instances each have a (empty initially) “singleton class” that comes before their “regular” class in method resolution order, and to which methods can be added.
I have found that chaining things in Smalltalk get immensely painful after just a couple elements. Unlike most other languages, I find myself reaching for silly little var names for lots of different things I would normally just let flow.
Really? To each their own, but honestly, I found smalltalks way of chaining things to be one of the most elegant parts of what is admittedly a syntactically-simple language (the old "fits on a postcard" thing).
With Smalltalk, with regard to return values or chaining, you get to have your cake and eat it too.
Your methods CAN return sensible values which don't necessarily have to be the original object. BUT, if you just want to chain a bunch of sends TO A PARTICULAR OBJECT, you can use ;, and chain the sends together without requiring that each intermediate method returns the original object.
That combined with the fact that chaining sends requires no special syntax. You just write them out as a single sentence (that's what it feels like), and you can format it across multiple lines however you wish. There's no syntax requirements getting in the way.
Just finish the whole thing with a dot. Again, just like a regular sentence.
And if you find precedence or readibility becoming confusing, then just put stuff in parens to make certain portions clearer. There's absolutely no harm in doing do, even if in your particular use case the normal precedence rules would have sufficed anyway.
Smalltalk
complex method chaining;
again (as mentioned previously)
reads like English.
In Ruby, methods called mainly for side effects rather than return value conventionally return the object itself, and so can be chanined by:
an_object.a_method.another_method
but, sure, it's less elegant (or at least less terse) than Smalltalk for the specific case of chaining invocations of methods with meaningful return values which are called for their side effects while discarding the return values.
I think this misses the point. `times` is "better" than `for` because it's declarative, reads like English, etc. Which of course are opinions, but the implementation details (messaging passing or not) are irrelevant.
Example: Swift and Kotlin can do `Int#times` and don't need message passing to get it done.
> but the implementation details (messaging passing or not) are irrelevant.
I'm the author here. While I agree that the implementation details do not matter for _most_ developers, I wanted to learn Ruby with an understand of how things are implemented.
In my previous post[1], I go into why I've always felt I didn't need Ruby since I knew Python, and I spent time learning Rust instead. It felt redundant to learn a second dynamically typed programming langauge that offered no advantage in performance. I started working at Chatwoot, where we use Ruby, and I had to pick up Ruby for the job. I didn't want to be satisfied with a "user-level" knowledge of the language and instead wanted to rip its internals apart so I can learn why it does the things it does.
Call it a preference on how I want to learn things.
A while back I tried out SuperCollider for programmatic music generation... I distinctly remember thinking, "this language feels like some weird awkward blend of Smalltalk and Ruby".
Somehow I hadn't thought of the two as similar or related to each other.
Anyway, certainly you can write in this style in Python, since functions are first-class objects. It just has limits on its anonymous functions, and doesn't happen to provide a `times` method on integers (at least partly because the old parser would have struggled with seeing `10.times` and thinking "this should be a floating-point number, but `t` isn't a decimal digit").
>>> class rint(int): # r for Ruby, of course
... def times(self, func):
... for i in range(self):
... func(i)
...
>>> rint(3).times(print)
0
1
2
> In Python, Java or C++, calling object.method() asks the compiler to find the method in the class and call it.
This is incorrect, as noted later. In Python, the lookup occurs at runtime. It also checks the object first, in most cases.
... The writing keeps anticipating my objections and then sort of correcting them and leaving something else not quite right. So trying to edit as I read has been frustrating. The point being, I just don't buy the philosophical difference that the author is trying to draw.
In Python the reason you're dealing with "attributes" rather than "messages" is because functions are first-class objects, which entails that they'll be treated the same way as ordinary data. A method call is two separate steps — the method-lookup and the actual attempt to "call" the result — which also has the implication that you can cache a "bound method" for later use. (By comparison, Ruby lets you "cache" the symbol, which in Python-think looks like some kind of magic string that tries to look itself up as an attribute name on other objects.)
But, I contend, this doesn't meaningfully change how the language is used overall.
> By including Enumerable and by implementing each, we get access to so many methods that we didn’t need to manually implement.
Okay, but in Python `map` and `filter` are just builtin functions, and you can use list comprehensions and `functools.reduce`. It's just a difference between external and internal iteration.
Implementing objects as closures interpreting messages passed as parameters is exactly how many Scheme programmers (myself included) wrote "babby's first object system" in Scheme. Such an object system is also presented in SICP.
> Leaving the handling of the loop to the method allows us to add behaviour to loops that are controlled by the object and not by the user. This is a nice way to add side-effects.
No, it's an absolutely horrible way to "add side-effects" which, usually, is already a horrible idea in its own right.
> Asking an object to iterate over itself allows objects to develop interfaces that dictate how to iterate.
That's true in pretty much any language? And since you need to know which iteration interface you need to use, it's not that much of an advantage.
> And now, when I see: `10.times { |i| puts "i = #{i}" }` I do not see a loop anymore.
Yeah, because it's not a loop: it may or may not run that block 10 times. Seriously, when a programmer's intention is "run something 10 times", the resulting expression arguably should not be "send that something to someone who, hopefully, will execute it 10 times".
Strongly disagree. THE ENTIRE ETHOS of Smalltalk & Ruby is to leave things up to the object you're communicating with, rather than the call/send site.
Sure, you may not like that mindset, in which case, smalltalk/ruby are ABSOLUTELY not for you. You want something else.
Which is totally fine. Part of the reason behind the Cambrian-explosion of higher level programming paradigms since the 1960's is precisely because there are multiple ways to skin a cat, and different ways resonate with different folks.
Like Alan Kay himself said, it wasn't about objects, but about messaging. [0]
[0] https://lists.squeakfoundation.org/pipermail/squeak-dev/1998...
Agreed. While I think matz is a great language designer, I loved Alan Kay's philosophy. I'd like some language that is OOP centric in nature, fast, has an elegant syntax and learns from erlang's model (elixir isn't it unfortunately, but some ideas it got right).
If you want OOP than, yes, Elixir isn't it... maybe Pony? Curious what else you don't like about Elixir though besides not being OOP... it's definitely got messaging!
A robust static type system is what was missing for me, at least last time I looked.
Static typing and messaging (OOP) don’t exactly fit together. If you want OOP, you are fundamentally beholden to dynamic typing.
I don’t want OOP. I just want the language to include a system for imposing constraints that prevent entire categories of bugs and make it easier to safely do large scale refactoring.
It’s really hard to go back to living without this once you’re used to it.
Coq, Idris, et. al. are over there if that's what you really want, but there is probably good reason why no "real world" programs are written in languages with proper type systems.
For one, there's little ability to avoid message passing in our modern world. You can take it out of the language, but that just means pushing it to another abstraction (e.g. sockets), and all the same lack of type safety comes right back.
I loved Smalltalk when I had to learn it for my first job out of college. Clean and clear OO with a flexible, play-inside-of-your-code runtime. Unfortunately the Smalltalk community is pretty small.
So imagine my delight when I found Ruby in 2005. It took the best of Perl and the best of Smalltalk and gave it a much better syntax than either, plus it had a massively growing community.
Ruby breaks a lot of the rules for what people claim they want (or should be allowed) from a programming language these days, but for me there’s still no more joyful and easy programming language to express my ideas.
Not all the best parts of Smalltalk, otherwise a IDE based experience with a JIT compiler would be there from the early days, that is an integral part of Smalltalk experience as developer.
I like this article a lot but if you want to dig deeper and understand some of the negative consequences of Ruby's approach, you might like these two articles I wrote:
https://journal.stuffwithstuff.com/2013/01/13/iteration-insi...
https://journal.stuffwithstuff.com/2013/02/24/iteration-insi...
Oh this looks good. I'm the author of the original post. Thanks for this. And thanks for reading.
Wait I just realized you're Bob Nystrom. Weee.
Love Ruby. Wish I could use it more often. Always end up reaching for Python in day-to-day because of how mature and well-docunented the libs are.
Anyone who likes this kind of stuff, highly recommend Metaprogramming Ruby [2] by Paolo Perrota. Great look into Ruby innards and inspiring code examples. Gets me pumped
Author here.
That's one of the books I'm reading now!
Leaving the comfort of lisp, I have started to wonder: why are all the looping facilities in other languages so awful?
Standing on the shoulders of giants, I made this little abomination: https://rikspucko.koketteriet.se/bjoli/goof-loop
It handles 98% of all loops I write, meaning I don't have to manage state (even for things like treating things like circular data). I find it removes many of the stupid errors I make when iterating over data, especially when I need nested loops and conditional accumulation.
I find it so provoking that someone implemented foreach and went "yes. That should be enough for everyone!"
Looping in Ruby is the opposite of awful. You only have to define an `#each` method in your class and include the `Enumerable` module, and you get a plethora of composable methods to iterate and accumulate in every which way. I find it nothing short of brilliant.
Yet, iterating over several collections and accumulating values is awkward.
It is not that it is easy to implement the iteration protocol, it is that the construct for looping universally sucks. Even the awful loop macro from common lisp runs laps around most other facilities. Racket's is even less powerful, but is miles better than what python offers.
Ruby can do some destructuring, but not enough to actually be useful.
It may be somewhat awkward; zipping collections to iterate over them in unison makes the first one (the sender) seem special, while it not necessarily is. And accumulating more than one value isn't always straightforward; you usually have to reduce explicitly. But it's so much better in the general case!
Like the example you showcase your macro with. In Ruby it would be:
You can see what it does at a glance, you don't have to immerse yourself inside the directives to follow the logic. And when you can't do that, declaring iterators and accumulators outside a loop and then iterating and accumulating "by hand" yields code not so different than your more complex examples.Your example of the flatten and grep will build two intermediate arrays before summing. That's inefficient.
I would also reach for higher order functions for most things, but when you need things to be fast that is not how you would do things. You would express it with nested for loops and ifs, and you would have to juggle state all by yourself. That is my main critique of looping constructs: they only cover the absolute simplest case, and then you are by yourself.
The partition example is not a particularly nice implementation of partition. It is there to show that you can write non-tail recursive loops, meaning you can use it to do tree walking and such. Using mutation, like your example, would make it prettier, but would make the code unsafe with schemes call/cc. Even a traditional named let (tail recursion) would be prettier.
For the record, if you want to avoid the creation of intermediate arrays, you can:
Not as clear, because the standard library doesn't have a `#flatten` method for lazy enumerators.But the point is the interface, not the implementation. Efficiency doesn't mandate assembly-like DSLs. Your interface could be as clear and clean as Ruby's and produce fast, inlined code by the power of macros. Ruby doesn't have macros, so chaining lambdas is the best it can do.
Ruby also has call/cc. None of the iterating methods has any provision to make them "safe" from it. They aren't safe from modifications to the iterated collection either. I think it makes sense; being forced to accumulate using only linked lists and having to be constantly on guard to support a rarely used quirky feature is a bad tradeoff IMO.
I dont think interfaces is the point. As it is now in ruby you have to pick between comfort and speed when you can have both.
Continuation safety has never been a thing in ruby, so caring about it doesn't make much sense regardless of the presence of call/cc.
And lastly, neither my loops nor others I have mentioned only accumulate into lists. My loops a re in the most general sense a left fold, although right folds are possible to write as well. I provide accumulators for just about any data type available, and writing a new one yourself is pretty easy. You can express lazy loops with it as well.
All without sacrificing performance. Any performance in most cases. I haven't written much ruby since the 1.9 days, but back then I remember having to rewrite the nice .each{}.blah.blah into for loops. I could prototype in a nice way which was nice, but in the code I ended up shipping I had to juggle state using for loops because the thing I prototyped ended up being a bit slow.
I use map, filter and friends in scheme all the time, but when those are insufficient or too slow I don't have to resort to named lets. I can just use the loop macro which compiles to a named let.
How is that different from select map and reduce in ruby?
You can iterate over strings and lists and arrays at the same time. You can do destructuring. You can accumulate values in every part of the loop, so if you have subloops you can accumulate values in the outer and inner and every intermediate loop and most important: it builds no intermediate results meaning it will be much faster.
Yes, you can do all that in ruby, plus you can choose to do it lazily such that chaining operations uses generators or by copy at any point so maybe this is a classic case of lispbian hubris.
Listen, my gripe isn't with ruby in particular. It is with every language out there.
Doing it that way is still going to be slower than doing it eagerly with a manual loop. I am not saying ruby should do away with the other ways of doing it. I am saying that ruby - and just about every language out there - should have a powerful looping facility that lets you do it fast without losing comfort.
If I - a non-programmer - could implement it using macros in scheme there is really no excuse for other languages to have such sucky foreach-like constructs.
For the vast majority of situations my goof-loop has no performance penalty compared to rolling the loop yourself. That is what none of the ruby examples I have been given can do. Using zip is not an acceptable way of iterating over 2 collections at once, at least not if you want to pretend to be efficient.
I don't think what I did is particularly good compared to something like the iterate macro, and all I want is for other languages to do better because I rarely have the pleasure of using scheme when doing coding.
I see the implementation of lazy zip here. But maybe by ruby you mean some other language.
https://ruby-doc.org/core-2.7.0/Enumerator/Lazy.html
Point is simply: No language is special or exceptional. If a language has yield, you can invert to your hearth's content. Even with lambdas/blocks you can invert by calling it in your loop. Speed is left to the efficiency of your jit or typed compilation. For example SBCL is able to compile incrementally by specifying types.
Adding to this: using laziness compared to a while loop in cases where you will process the whole array is just pure overhead.
Heck, testing now on 3.4.4 a while loop is faster than using each. Summing a million numbers (to make the overhead of the different approaches as clear as possible) shows that a while loop is almost 2x faster.
This is what my complaint is about. Why is the fast path so painful to use in so many languages?
Laziness is not free. An eager loop will be faster than a lazy construct, especially languages where the laziness isn't really a first class construct. Like ruby.
Rewriting the code you wrote (or was it the other guy? I am making food so I cant really check) to avoid intermediate collections as a for loop will be faster, especially if you can avoid creating those array pairs.
I am not saying ruby stinks. I am saying it - and just about every other language - is making it unnecessarily hard to write fast code.
> But Python also looks up methods at runtime. Does that mean Python also does message passing? Not quite.
I don't think Ruby's "message passing" is fundamentally different from Python's "method calls". Ultimately, both languages implementations are very similar: both look up methods by name in a hash table and then call them.
IMO "message passing" is just an alternative metaphor for what Ruby does when you type `object.name`. The metaphor fits Ruby but not Python, because the languages do three things differently:
- Ruby only looks for `name` in `object.class` (and its superclasses), whereas Python first looks in `object` itself
- If Ruby finds `name`, it's guaranteed to be a method whereas in Python it could be a different kind of value
- Ruby immediately calls the method once it's found, whereas Python (generally) doesn't - instead it returns a binding to be called later
This means that in Ruby, `object.name` is always calling a method defined on `object.class`, with `self` set to `object`. That can be re-interpreted as "sending a message" to `object.class`.
In Python, `object.name` is a more general value lookup - maybe the result will be callable, maybe not.
> both look up methods by name in a hash table and then call them.
Except Ruby doesn't? cue `method_missing`. If you take only trivial examples you're not going to see much difference, this starts to show when you involve more advanced situations e.g with inheritance, and then you're drilling into singleton classes.
> Ruby immediately calls the method once it's found, whereas Python (generally) doesn't - instead it returns a binding to be called later
Again incorrect, `foo.bar` in Ruby and Python are two very fundamentally different things.
Python returns a binding to a method because it's an attribute accessor; when you throw inheritance into the mix it ends up that that attribute is inherited from the parent class, bound to the instance (which really in python means pass `self` as first argument), and - schematically - adding `()` after that ends up calling that bound method. If there's no attribute that's a no method error. It's all very C-ish and make believe, barely a notch above Go structs and their functions. The closest parallel in Ruby would be `foo.method(:bar).call()`
By contrast Ruby is going to send the :bar message along the inheritance chain, and if someone can respond it's going to invoke the responder's code, and surprise surprise method_missing happens only if it has exhausted inheritance but it's itself a method-slash-message; Oh and by the way the message passing is naturally so lazy that you can actually modify the inheritance chain -in flight- and inject a parent responder right before calling `super`. The whole notion of `binding` is a very concrete construct, way more rich that simply "hey I'm passing self as first argument". It becomes even more strange to "C&al. folks" when you start to involve singleton classes and start to realise weird things like Ruby classes are merely instances of the class Class and it's all instance turtles all the way down and all stupidly simple but you gotta have to wrap your head around it.
I surmise that so many differences and surprises have with Ruby are because most languages have some ALGOL legacy and Ruby is a conceptual heir to Smalltalk (and LISP†); the whole concept of open classes being another one: nothing is ever "finished" in Ruby!
Most of the time you don't have to care about these differences, until you do.
† While code isn't quite S-expr data in Ruby, there are more than enough first-class facilities that you can create and inject code entirely dynamically without resorting to `eval`ing strings.
Nice summary. I've been using Ruby both professionally and not for going on 20 years and I just today learned about singleton_class when attempting to build something like Rails' view helpers from first principles.
Thanks. I've been trying to put these bits in a succinct format:
https://lloeki.github.io/illustrated-ruby/
Each chapter kind of builds up on the previous one. It's still WIP and far from complete but what's there has helped me onboard a few people to Ruby already.
You might be interested in the Classes and Ancestry chapters.
> If Ruby finds `name`, it's guaranteed to be a method whereas in Python it could be a different kind of value
This is the big difference, Ruby objects have no members other than methods, external entities cannot read data from the object only call methods; the object controls how it responds.
There's ways that seem to bypass this in Ruby, but they are cooperative, relying on calling other methods on the object, like accessing instance variables by calling object.instance_variable_get(:@foo).
But here you refer to implementation details. Isn't the point about message passing that objects themselves communicate with one another through such messages? And in turn, messages can also be assumed to be small objects. I don't think any of those implementations really fulfil that as a meaning. Or perhaps I misunderstood Alan Kay here. He drew inspiration more from biological cells and communication pathways therein. Naturally biology can not be mapped 1:1 onto in-silico hardware, that wouldn't even make sense either - but for instance, erlang's model appears to me closer to different objects happily communicating with one another in a very flexible, safe, fault-tolerant manner. I don't think it is the implementation detail that is about message passing. I also don't think "sending a message" is the confinement either - it's an important but, but does not appear to capture all that is meant with a "message". A message could be many things, including objects that themselves could change at any moment in time again. I see it more as an intrinsic part of communication at all times.
> This means that in Ruby, `object.name` is always calling a method defined on `object.class`, with `self` set to `object`. That can be re-interpreted as "sending a message" to `object.class`.
Ruby Instances can have their own methods and override methods separate from their class.
More precisely, Ruby instances each have a (empty initially) “singleton class” that comes before their “regular” class in method resolution order, and to which methods can be added.
Author here, I'd already shared it here.
https://news.ycombinator.com/item?id=45644349
Thank you for this article. It makes it easier to explain to newcomers to Ruby why not to use the `for` keyword.
You might like my other post too
https://tech.stonecharioteer.com/posts/2025/ruby-blocks/
Thanks for reading. I didn't expect to hit HN Front page a second time this month!!
And
https://news.ycombinator.com/item?id=45681023
7 minutes of Pharroh Smalltalk for Rubyists: https://www.youtube.com/watch?v=HOuZyOKa91o
Pharo
https://pharo.org/
Even something as basic as "if" is done with message passing and blocks in Smalltalk.
There's a method named "ifTrue:ifFalse:" in Smalltalk (with each ":" expecting an argument, in this case, a block).
You can also chain messages and make phrases: `anObject aMethod; anotherMethod; yourself.`
The Ruby equivalent has repetition: `an_object.a_method; an_object.another_method; an_object`
or requires a block: `an_object.tap { _1.a_method; _1.another_method}` (and we usually use newlines instead of ";")
I have found that chaining things in Smalltalk get immensely painful after just a couple elements. Unlike most other languages, I find myself reaching for silly little var names for lots of different things I would normally just let flow.
Really? To each their own, but honestly, I found smalltalks way of chaining things to be one of the most elegant parts of what is admittedly a syntactically-simple language (the old "fits on a postcard" thing).
With Smalltalk, with regard to return values or chaining, you get to have your cake and eat it too.
Your methods CAN return sensible values which don't necessarily have to be the original object. BUT, if you just want to chain a bunch of sends TO A PARTICULAR OBJECT, you can use ;, and chain the sends together without requiring that each intermediate method returns the original object.
That combined with the fact that chaining sends requires no special syntax. You just write them out as a single sentence (that's what it feels like), and you can format it across multiple lines however you wish. There's no syntax requirements getting in the way.
Just finish the whole thing with a dot. Again, just like a regular sentence.
And if you find precedence or readibility becoming confusing, then just put stuff in parens to make certain portions clearer. There's absolutely no harm in doing do, even if in your particular use case the normal precedence rules would have sufficed anyway.
In Ruby, methods called mainly for side effects rather than return value conventionally return the object itself, and so can be chanined by:
but, sure, it's less elegant (or at least less terse) than Smalltalk for the specific case of chaining invocations of methods with meaningful return values which are called for their side effects while discarding the return values.I think this misses the point. `times` is "better" than `for` because it's declarative, reads like English, etc. Which of course are opinions, but the implementation details (messaging passing or not) are irrelevant.
Example: Swift and Kotlin can do `Int#times` and don't need message passing to get it done.
> but the implementation details (messaging passing or not) are irrelevant.
I'm the author here. While I agree that the implementation details do not matter for _most_ developers, I wanted to learn Ruby with an understand of how things are implemented.
In my previous post[1], I go into why I've always felt I didn't need Ruby since I knew Python, and I spent time learning Rust instead. It felt redundant to learn a second dynamically typed programming langauge that offered no advantage in performance. I started working at Chatwoot, where we use Ruby, and I had to pick up Ruby for the job. I didn't want to be satisfied with a "user-level" knowledge of the language and instead wanted to rip its internals apart so I can learn why it does the things it does.
Call it a preference on how I want to learn things.
[1] - https://tech.stonecharioteer.com/posts/2025/ruby/
Dynamic types in Swift do use message passing. Int/NSInteger is a struct/value type, but NSNumber is a dynamic type that would receive a message.
Damn, I'm a fulltime Ruby blogger now?
A while back I tried out SuperCollider for programmatic music generation... I distinctly remember thinking, "this language feels like some weird awkward blend of Smalltalk and Ruby".
Somehow I hadn't thought of the two as similar or related to each other.
Anyway, certainly you can write in this style in Python, since functions are first-class objects. It just has limits on its anonymous functions, and doesn't happen to provide a `times` method on integers (at least partly because the old parser would have struggled with seeing `10.times` and thinking "this should be a floating-point number, but `t` isn't a decimal digit").
> In Python, Java or C++, calling object.method() asks the compiler to find the method in the class and call it.This is incorrect, as noted later. In Python, the lookup occurs at runtime. It also checks the object first, in most cases.
... The writing keeps anticipating my objections and then sort of correcting them and leaving something else not quite right. So trying to edit as I read has been frustrating. The point being, I just don't buy the philosophical difference that the author is trying to draw.
In Python the reason you're dealing with "attributes" rather than "messages" is because functions are first-class objects, which entails that they'll be treated the same way as ordinary data. A method call is two separate steps — the method-lookup and the actual attempt to "call" the result — which also has the implication that you can cache a "bound method" for later use. (By comparison, Ruby lets you "cache" the symbol, which in Python-think looks like some kind of magic string that tries to look itself up as an attribute name on other objects.)
But, I contend, this doesn't meaningfully change how the language is used overall.
> By including Enumerable and by implementing each, we get access to so many methods that we didn’t need to manually implement.
Okay, but in Python `map` and `filter` are just builtin functions, and you can use list comprehensions and `functools.reduce`. It's just a difference between external and internal iteration.
Implementing objects as closures interpreting messages passed as parameters is exactly how many Scheme programmers (myself included) wrote "babby's first object system" in Scheme. Such an object system is also presented in SICP.
Finally we have the following Scheme Koan:
https://people.csail.mit.edu/gregs/ll1-discuss-archive-html/...
Amazing. I've heard both sayings before, but not the koan. Yet I somehow meditated upon it without knowing!
> Leaving the handling of the loop to the method allows us to add behaviour to loops that are controlled by the object and not by the user. This is a nice way to add side-effects.
No, it's an absolutely horrible way to "add side-effects" which, usually, is already a horrible idea in its own right.
> Asking an object to iterate over itself allows objects to develop interfaces that dictate how to iterate.
That's true in pretty much any language? And since you need to know which iteration interface you need to use, it's not that much of an advantage.
> And now, when I see: `10.times { |i| puts "i = #{i}" }` I do not see a loop anymore.
Yeah, because it's not a loop: it may or may not run that block 10 times. Seriously, when a programmer's intention is "run something 10 times", the resulting expression arguably should not be "send that something to someone who, hopefully, will execute it 10 times".
Strongly disagree. THE ENTIRE ETHOS of Smalltalk & Ruby is to leave things up to the object you're communicating with, rather than the call/send site.
Sure, you may not like that mindset, in which case, smalltalk/ruby are ABSOLUTELY not for you. You want something else.
Which is totally fine. Part of the reason behind the Cambrian-explosion of higher level programming paradigms since the 1960's is precisely because there are multiple ways to skin a cat, and different ways resonate with different folks.