that's too vague. Most OO PLs don't actually use messages in any way under the hood (except maaaybe ruby? I hear things but haven't peeked at the MRI code) and use messages as a "conceptual framework" but let's be honest - is calling a method owned by object A.do_something(B::target_type, C::parameter_type)... What sort of a message is that?

moreover, plenty of FPs (I'm looking at you erlang) use message passing all over the place, as, arguably the most important feature of the language, with things that vaguely look like objects (gen_servers) but I would not really call erlang an OO language, except maybe to joke to an OO programmer that an FP is truer to the original intent.

Inheritance / encapsulation / polymorphisim are kind of vague too.

actually, Alan Kay said Erlang was most like his concept of OO.

Ruby has some nice hooks for when an object doesn't have a method, at which point you can dynamically resolve it. Much advice in the OO world and its principles are really just to do with message routing, and a lot of Design Patterns are about how to do it when the type system fights you

but even if you are stuck with your C++/Java/C# type languages, then I think it is still useful. I've often seen in the first 10-15 minutes with "traditional" advice that set off down a path of design that ultimately causes a lot of struggle between OO and the typing system, most often because of naming things too early warping the mental rather than recognizing traits of interactions.

IIUC Kay had a live organisms in mind, passing biochemical signals at will, which Erlang matches quite snug.

It's so odd because when people talked about OO I imagined something live and parallel, kinda like Kay/Erlang buuut it was so far from that.

The first OO language, Simula 67, was exactly like that.

True, I almost forgot. Wasn't the model a bit slow (relatively speaking) at the time ? Maybe that's why it disappeared for a while.

Simula 67 was designed for simulations (hence the name), it wasn’t general.

Actually, the first OO language was probably SketchPad, but it’s object model isn’t very recognizable compared to textual OO language.

I think Ruby qualifies as true OO (in the Alan Kay sense) because messages are first class entities that can be explicitly manipulated. This makes it trivial to implement lots of OO patterns that require a significant amount of boilerplate in other languages. For example, a proxy.

Erlang makes messages an even more central element, as the whole language is built around the concept of inboxes and asynchronous message passing (synchronous message passing being a special case).

Better type systems are in vogue now, for really good reasons. But I wish we don't ignore lots of good ideas from dynamic languages like Erlang or Mozart/Oz. Every time I open CTM or SICP I find great insights I had already forgotten.

could you explain "messages are first class" a bit more? what does that look like in Ruby?

Avdi Grimm has an explanation [0] more worthy than what I was managing to conjure up.

[0]: https://www.rubytapas.com/2012/10/17/episode-011-method-and-...

Interfaces or bases classes where all methods are pure or empty are often used to implement messages in awkward ways in mainstream OOP languages as the languages lack proper union types.

I assume you pass pointers around to share data? How do you handle cleanup?