3 ms·

Your question is interesting from the perspective that the actor model could be seen as the precursor to modern object oriented programming. Both the actor mode

Your question is interesting from the perspective that the actor model could be seen as the precursor to modern object oriented programming. Both the actor model as defined by Carl Hewitt and the early object computational models as they are defined by Alan Kay (Smalltalk) originated during the same period and are based on similar philosophies of computation. However, on the object oriented model track, due to practical reasons, its definition descended into a single-thread dispatch system with full message delivery guarantees. Locality was dropped (due to singletons) and the distributed model was not maintained. Method dispatch systems were later added, but could be considered a kludge. This also explains the mismatch between remote systems calls (SOAP, REST, etc.) and the internal language. Ideally, these would be the same. With our modern systems design constraints, especially given distributed systems, we need to revisit those early decisions. The Actor model is a good blueprint for our designs. It is fundamentally decentralized, locality is enforced and at-most-once message delivery is assumed. These allow us to design and implement distributed algorithms which would be hard to implement using traditional OOP methods.

dkn 7y ago
I think this is a great summary, and also highlights much of what Joe Armstrong talked about when comparing Erlang to other OO languages, and his earlier decisions to design Erlang to work in the same way whether in a single-node or multi-node environment.
sakian 7y ago
Aren't they connected by the idea of active objects? https://en.wikipedia.org/wiki/Active_object https://en.wikipedia.org/wiki/Active_object
- RossBencina 7y ago
  Based on the description in your Wikipedia link there is a relationship for sure -- but I don't see a strong connection. Here's how I see it: An Active Object is essentially an OO encapsulation of a worker thread. It provides clients with a synchronous call interface where all results are resolved asynchronously (e.g. using futures for results). Internally, the Active Object converts client requests into asynchronous operations, enqueues the operations, and executes them on a private worker thread using object-specific dispatcher logic. In an OO system, not all objects are required to be Active Objects. So there may be a mixture of synchronous and asynchronous execution. In contrast, in an Actor system all communication is via asynchronous messages and there is no inherent requirement for multiple concurrent threads of execution. Active Objects use a mechanism such as futures to return results. On the other hand, if there is a request-reply message exchange in an Actor system, both the request and the reply will be separate messages. The client would receive the result of a computation by receiving a message. The relationship I see between Actors and Active Objects is that both require some kind of queue for dispatching operations (since Actor behaviors are never re-entrant). Active Objects convert synchronous calls into asynchronous operation requests, whereas Actors use asynchronous messages for _all_ inter-entity communication. I agree with the GP that event loop programming is the closer OO analogue of Actors.
wwweston 7y ago
If I'm only following about half of what you're saying (I'm familiar with Smalltalk and the OO model, I don't know what the actor model is, I don't know what "locality" means), what's a good place for me to start?
- anthony_doan 7y ago
  I learn about Actor model via Elixir/Erlang. A good place to start is perhaps learning Elixir and eventually move to OTP and it's actor model. Actor are just processes in Erlang/Elixir (underlying implementation is a thread that doesn't share anything) that isolate logic (self contained) and if it goes down it doesn't take any thing else down. So it's OO that way. It helps that functional paradigm good practices is small compose-able function that does one thing. You compose these functions into a logic and wrap it in these processes and treat them like objects.
Ari_Ugwu 7y ago
Thanks a lot for this quick summary. Computer science can be such a semantic jungle.

dkn 7y ago

I think this is a great summary, and also highlights much of what Joe Armstrong talked about when comparing Erlang to other OO languages, and his earlier decisions to design Erlang to work in the same way whether in a single-node or multi-node environment.

sakian 7y ago

Aren't they connected by the idea of active objects? https://en.wikipedia.org/wiki/Active_object https://en.wikipedia.org/wiki/Active_object

RossBencina 7y ago
Based on the description in your Wikipedia link there is a relationship for sure -- but I don't see a strong connection. Here's how I see it: An Active Object is essentially an OO encapsulation of a worker thread. It provides clients with a synchronous call interface where all results are resolved asynchronously (e.g. using futures for results). Internally, the Active Object converts client requests into asynchronous operations, enqueues the operations, and executes them on a private worker thread using object-specific dispatcher logic. In an OO system, not all objects are required to be Active Objects. So there may be a mixture of synchronous and asynchronous execution. In contrast, in an Actor system all communication is via asynchronous messages and there is no inherent requirement for multiple concurrent threads of execution. Active Objects use a mechanism such as futures to return results. On the other hand, if there is a request-reply message exchange in an Actor system, both the request and the reply will be separate messages. The client would receive the result of a computation by receiving a message. The relationship I see between Actors and Active Objects is that both require some kind of queue for dispatching operations (since Actor behaviors are never re-entrant). Active Objects convert synchronous calls into asynchronous operation requests, whereas Actors use asynchronous messages for _all_ inter-entity communication. I agree with the GP that event loop programming is the closer OO analogue of Actors.

wwweston 7y ago

If I'm only following about half of what you're saying (I'm familiar with Smalltalk and the OO model, I don't know what the actor model is, I don't know what "locality" means), what's a good place for me to start?

anthony_doan 7y ago
I learn about Actor model via Elixir/Erlang. A good place to start is perhaps learning Elixir and eventually move to OTP and it's actor model. Actor are just processes in Erlang/Elixir (underlying implementation is a thread that doesn't share anything) that isolate logic (self contained) and if it goes down it doesn't take any thing else down. So it's OO that way. It helps that functional paradigm good practices is small compose-able function that does one thing. You compose these functions into a logic and wrap it in these processes and treat them like objects.

Ari_Ugwu 7y ago

Thanks a lot for this quick summary. Computer science can be such a semantic jungle.