Sounds more like what many people would call event-drive architecture, these days.
People tell me Ruby is message passing, but it doesn't seem to match your description at all.
People tell me Ruby is message passing, but it doesn't seem to match your description at all.
Alan, if you're in the comments section I'd love to hear your thoughts on what you think of the resurgence of functional programming in the modern day and whether anything, other than perhaps languages like Erlang, has approached your original ideal.
I just watched the whole thing, based on just seeing your link.
It does talk about the historical connections between Smalltalk and Erlang, but goes far beyond that to remind us to think more about the bigger problems we need to solve, and get less caught up in doing things just because we have a tool that can do them or other people are doing things that way.
I found it truly inspiring.
Someone asked a similar question when he did an AMA, but the answer wasn't clear to me:
To me, it's the difference between pulling the strings on a puppet (method calling) vs placing a request to a colleague (messaging).
However I don't think anything in the Ruby docs ever claims that it has a message-passing intent. I think the option to write in this style is really a byproduct of duck typing combined with a Ruby object's ability to arbitrarily and dynamically reconfigure its own dispatch table. If Matz really intended a message-passing style, then Object#send would've been split into Kernel#send and Object#receive, and there'd probably be a Message class rather than just using symbols.
Given the new shorthand of object.:name in 2.7 for object.method(:name) one could even argue that Matz is drifting Ruby back towards an early binding style. However I don't see myself using that syntax much outside of block parameters to Enumerable methods and the like.
Overall I think the stylistic options are a strength and we don't particularly need to resolve the dichotomy to write good Ruby.
There is of course the `Kernel#send` method, which implies the model is messages being sent. It's not called `call`.
The fact it isn't invoked for regular method invocation is kinda indicative of Ruby _not_ being a pure message passing language, even if we like treating it that way.
It's definitely Kernel#send. Object defines no instance methods at all.
> Kernel.instance_methods(false).include?(:send)
=> true
> Object.instance_methods(false).include?(:send)
=> false
> Object.instance_methods(false)
=> []
That's a somewhat arcane implementation detail though. What about the meat of the discussion?
If I'm being uncharitable I think applying the term 'message passing' to Ruby is a bit of making something sound more sophisticated and elaborate than it is. They're method calls - it's pretty simple already and doesn't need a complex concept on top of that.
It’s a little tough to compare to an OO language because there are no classes, but all object to object communications are asynchronous messages.
This is the way I think about it as well, the more concise notion is ask don't tell. By don't tell I'm thinking of telling an object to change it's state directly. This distinction can be very, very subtle.
It's a bit more involved than that - modules can be included and prepended. In a sense "re-arranging the which cells are close and further". Also `method_missing` can be implemented. Beautiful in my opinion.
RailsConf 2015 - Nothing is Something
https://www.youtube.com/watch?v=OMPfEXIlTVE
But to me, this simply looks like Functional Programming done in an OOP mess.
Map, filter, flapmap, lambdas, symbols, are all there.
You can easily do LINQ in Smalltalk-80 without any additional library.