That is an important distinction yet I prefer to think of message-passing a bit more generally. There are different kinds of message-passing, the one that avoids spooky action is just one of them, a good one but still not the only one.

Say I look over my cubicle wall and see you and "send" you a paper-airplane. The paper-airplane is the message, I can assume you will become aware of it having landed on your cubicle. Perhaps there is a question written on the paper. Because I have good eyesight I can spookily already see your answer without you having to send that paper-airplane back to me. It's still message-passing even though it is spooky.

The real distinguishing feature of "message passing" I think is that the recipient is free to interpret the messages they receive, and that no-one else can, that no-one else can modify the "mental state" of the message-recipient than they themselves, as a response to the messages they receive.

I think I must be missing a detail, because it feels to me like your spooky example of peeking over the cubicle wall is in direct conflict with the idea that nobody can modify an object's mental state except by passing objects to it.

If you're really only allowed to communicate by passing messages, then, to me, that would imply that there's some sort of "no peeking" rule.

Say I send you a mutable object as an argument of a message / method-call while holding on to that same object in some variable as well. You modify that object without telling me. Does that mean you are spookily communicating with me?

I would say no because you are not communicating with me at all. I am unaware that you have modified the object.

I can ask that object about its state and that way detect that somebody has changed it. But how can I ask it about its state? Only by sending it a message/calling its method, IF I am using an "Object-Oriented Language".

There is nothing spooky about multiple observers having access to the same shared mutable object, is there? They can still only extract information from it by - sending a message - in an Alan Kayesque Object Oriented language.

But in a hybrid language like JavaScript where I can directly read and write and even delete fields of an object it is spooky, this value was just here and now it is no longer and I don't know why because somebody else somewhere deleted that field.

Gotcha. I think, then, that the devil is in the details. That Erlang ets module I mentioned elsewhere does something like this, where it creates an entity that acts as a shared mutable data store, but communication with it still happens by message passing, so you still get certain guarantees. Notably, if you query it for some information and then get your response back, that response's contents aren't going to change on you. So the behavior's really more like querying a database than getting a pointer to a mutable data structure.

There's maybe a "letter of the law vs spirit of the law" thing going on here, too. Having an object that just implements an array feels like it's violating the basic idea, even if you are technically only communicating with it by passing messages. I'm pretty sure the original vision was that objects would represent interesting entities from the business domain and not just be heavyweight analogues for basic data structures.

Yeah, I don't think that ever could work. And that's kind of a problem. At best, what you would have is a system where different parts have "names"/ids but there's no guarantee that a named object is going to actually be present and so each object has to be able to handle the situation when the object isn't there.

There are plenty of Erlang programmers out there who, I'm guessing, would happily tell you that it works quite well.

(Just don't ask them about the ets module.)

Ruby works like that, and it works just fine, unless you're dealing with developers that are intentionally trying to mess with your head.

The reality is that most of the time when the world is dynamically changing, there are reasons for it.

E.g. the typical Ruby example is an ORM where the methods available reflects the database schema of the database you just connected to. Whether you get an exception because the method you expected doesn't exist, or get an exception because some generated method got an error from the database doesn't matter: You need to deal with it either way.

All that changes in practice is the name of the error condition you need to handle.

What's a reference, though? In actor based messages, you can pass the mailbox id, which is not a memory reference, but semantically a "reference" to the object encapsulated by the actor.