"The big deal was encapsulation and messaging to provide loose couplings that would work under extreme scaling (in manners reminiscent of Biology and Ecology)."
I always tried to decipher Alan Kay's notion of object oriented programming.
Erlang with its active objects seems to me to fit precisely his description.
Active objects = the objects themselves decide when to run a method = receive a message and react to it.
As opposed to java like oop where the objects just sit there passively and are woken up in a blocking fashion by callers from outside.
It appears to me that c++/java etc. flavour of oop uses objects just as a module system, but then has another module/namespace/package mechanism besides that. Two concepts for the same thing essentially, just making the language unnecessarily complicated.
Polymorphism and inheritance were also a big deal for Java and C++, which namespaces don’t provide. That and classes are a way to extend the type system.
Kay may not have had those things as his primary conception of OOP, but Smalltalk fully supports inheritance, polymorphism and type extension.
An object, under OOP, doesn't have to have an associated execution thread, in order to decide when to do what.
Instead, picture an object as a closure over mutable state, where the closure accepts an arbitrary serialized term (the "message") which it can do anything it likes with.
Note how such a "closure object" can call its runtime's timer API to get another message sent to it later. It could even do this in its constructor.
Note also how such a "closure object" can reprogram itself, by holding onto other closures as part of its mutable internal state, and replacing these with other closures [e.g. ones passed in as part of the message] in response to messages.
These two properties together, mean that how a "closure object" responds to a message at a given time, is entirely up to the closure—it can have changed into something that does something entirely different from what its "bootstrap" source code says, at any point since the start of the process. (Just like Joe Armstrong's Erlang "Universal Server" — https://joearms.github.io/published/2013-11-21-My-favorite-e...)
You may find the book "Concepts, Techniques, Models of Computing Programming" helpful.
My understanding of how Erlang is approached in this book is as follows:
- the concurrent declarative/functional computation model has the critical advantage but also limitation of not allowing non-determinism of any sort
- client/server programming without a restricted form of non-determinism is impossible (namely, the server must not need to know from which client the next message will be, which is a form of non-determinism)
- this can be solved by adding a new concept: ports. Ports introduce a restricted form of explicit state, while allowing the rest of the program to be purely functional.
- Erlang is classified as belonging to the computation model that results from adding ports to the concurrent declarative/functional computation model: the Message Passing Concurrent model
- the Object Oriented computation model is different: it is the result of adding explicit state to the (non-concurrent) declarative/functional model. Of course, you can then also add concurrency to the mix. The crucial difference with the Message Passing Concurrent model is that non-determinism is now not restricted to ports anymore, making reasoning about program behaviour way more complicated.
- so, if Smalltalk falls into the concurrent OO computation model, it is both more complex and expressive that Erlang.
> Erlang with its active objects seems to me to fit precisely his description.
He's said exactly this [0]:
> We didn’t even do all of the idea at PARC. Many of Carl Hewitt’s Actors ideas which got sparked by the original Smalltalk were more in the spirit of OOP than the subsequent Smalltalks. Significant parts of Erlang are more like a real OOP language the the current Smalltalk, and certainly the C based languages that have been painted with “OOP paint”.
Your point still stands but, since the field has so many terminologies that are conflated, I wanted to let you know that "active objects" is a specific kind of actor model and Erlang is not an instance of that model. Active Objects is essentially Java but with asynchronous calls, much like using gen_server for everything.
A good paper that untangles the terminology is "43 years of actors: a taxonomy of actor models and their key properties".
Ocaml has both! You have a (very powerful) module system, serving purposes of encapsulation and namespacing, and other more powerful abstractions, and you also have dynamic/message-passing style OOP available to you.
A question: can OCaml’s object system be used to implement a runtime similar to that of Objective-C (things like obj_msgsend)? Or does OCaml’s type system impose restrictions that prevent this level of dynamic operation?
This describes exactly why Erlang scales so well.