Just to add to the previous poster's comments, Alan Kay seems to also consider the internal state of a "cell" (or object) to be private and responsive only to external messaging. If you extrapolate this to a network I personally see a "colony" of objects that are not "aware" of each other aside from their neighbours' messages, and the whole thing starts to seem like it has a lot of the features we see in modern functional programming today. I don't think this is particularly coincidental, since functional approaches are born from lambda calculus and Kay mentions in these emails a desire to incorporate algebras into his objects (aside from the biological nature of this type of cell communication).

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 don't think I've watched it previously, and I don't have the time to now, but I have to imagine Joe Armstrong interviewing Alan Kay would at least touch on that (although from one comment it sounds like they didn't do more than that).

https://youtu.be/fhOHn9TClXY

Watch it!

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.

> 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

Someone asked a similar question when he did an AMA, but the answer wasn't clear to me:

https://news.ycombinator.com/item?id=11940211

Ruby syntax & behaviour is in a hazy middle ground between message passing and method calling. Writing Ruby in a message-passing style feels natural and easy, which is why many Rubyists will recommend it, and doing so enables looser coupling between objects.

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.

> However I don't think anything in the Ruby docs ever claims that it has a message-passing intent.

There is of course the `Kernel#send` method, which implies the model is messages being sent. It's not called `call`.

I think you mean Object#send? I actually think that's misnamed, I think it should be named Object#receive because that's what happens - you're forcing an object to receive a symbol for (by default) dispatch through its method table.

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.

> I think you mean Object#send?

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)
    => []

https://github.com/ruby/ruby/blob/v2_6_2/vm_eval.c#L2163

Fascinating, the docs are misleading on this point. http://ruby-doc.org/core-2.6.2/Object.html#method-i-send because Object includes Kernel and it's just easier to find, I guess.

That's a somewhat arcane implementation detail though. What about the meat of the discussion?

I don't think Ruby is message passing either because the caller determines which method to call, based on the object's method table. #method_missing is just another method to be called by the caller - it isn't an example of the object being able to determine what happens. I think #send is really #call, but I think the name implies someone somewhere thought it was message passing.

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 merely remains to fork and/or invent a language that otherwise looks almost exactly like Ruby but with message passing only.

Elixir?

Elixir has conventional method calls by default, and only optional message passing with a separate syntax. It's definitely not message passing everywhere.

It’s message passing everywhere outside the current object (process).

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.

> To me, it's the difference between pulling the strings on a puppet (method calling) vs placing a request to a colleague (messaging).

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.

Ruby to me seems to follow this description rather well. The "cells" in close vicinity are the objects in ancestor chain. If the "closest cell" - object's class - can't respond to it, next further, which is its parent, will be given chance and so on. Also you can ask object if they know how to respond with `respond_to?`

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.

Here's one talk about 'message' in Ruby:

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.

Smalltalk was also influenced by Lisp work being done at Xerox PARC.

Map, filter, flapmap, lambdas, symbols, are all there.

You can easily do LINQ in Smalltalk-80 without any additional library.