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.
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.
Actually, the first OO language was probably SketchPad, but it’s object model isn’t very recognizable compared to textual OO language.
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.
[0]: https://www.rubytapas.com/2012/10/17/episode-011-method-and-...
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.