Some Smalltalk about Ruby Loops
tech.stonecharioteer.com
Some Smalltalk about Ruby Loops
1–10 of 59 posts
Re: Some Smalltalk about Ruby Loops
#2Author here, I'd already shared it here.
Re: Some Smalltalk about Ruby Loops
#3Author 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.
Re: Some Smalltalk about Ruby Loops
#4> 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".
Re: Some Smalltalk about Ruby Loops
#5> 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.
Re: Some Smalltalk about Ruby Loops
#6Like Alan Kay himself said, it wasn't about objects, but about messaging. [0]
[0] https://lists.squeakfoundation.org/pipermail/squeak-dev/1998...
Re: Some Smalltalk about Ruby Loops
#7I 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.
Re: Some Smalltalk about Ruby Loops
#8Like 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).
Re: Some Smalltalk about Ruby Loops
#9> 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 `obj…
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.
Re: Some Smalltalk about Ruby Loops
#10I 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.