Almost no oop languages are actually oop according to Alan Kay.
I think his OOP is closest to what we'd call actors today.
I think his OOP is closest to what we'd call actors today.
Erlang is another story: it would probably be better to call it just actor model. But again, Kay himself says[2] that there is not a lot of difference between actor model and his OOP.
[1] https://www.youtube.com/watch?v=oKg1hTOQXoY
[2] https://www.quora.com/What-is-the-difference-between-Alan-Ka...
It's not just the actor model, though. In the actor model, all the actors are contributors to the conversation. The subjects of conversation are something else. In object oriented programming, the subjects of conversation are the same category of things as the agents of conversation, and may move back and forth freely.
The simplest way to see the difference is to think about how a new contributor to the conversation is added. In the actor model, some actor forks a new actor in response to a message. If I have built up the state to describe a new actor, there is still a step to bring it to life that changes it from one thing to another.
In object oriented programming, when you build up that state, it may become a contributor to the conversation at any point in time and then go back to being a subject of conversation, or do both at once. There is no switch.
* Function calls are messages sent to objects, which can be sent to any object directly with Object#send and received as messages when an object[1] responds to #message_missing.
* Local state is stored in objects as @foo variables. Ruby is a multi-paradigm language, so it's not strict about enforcing the privacy of local state, but that's rarely a big deal. Ruby softly encourages using an OOP message-passing style with e.g. Module.attr_accessor defining simple accessor wrappers instead of reading local state directly.
* The extreme lateness and mutability of binding in Ruby is (in)famous for making ruby slow and hard to optimize.
[1] I don't mean "defined in the class"; changes can be specific to a particular object instance.
obj = Object.new
obj.define_singleton_method(:method_missing) do |method,*args|
puts method.to_s.capitalize
end
obj.hello! # prints "Hello!"Did Simula fit that description fully? I've never seen a Simula program in my life.
If it doesn't use machine learning, it's bad.
If it doesn't use blockchain, it's bad.
Alan Kay's view of OOP is mostly just the actor model. But the actor model, like OOP, does not tell us how to actually build programs. "When do I use an object?" is a question OOP does not answer, "When do I use an actor?" is similarly not answered by the actor model.
Service Oriented Architecture is also effectively the actor model, but with a focus on the persistent process abstraction.
What Microservices does is take the actor model and say:
* Here's how you figure out where the actor abstractions should go, how large they should be, and patterns for interaction
Where microservices soooort of diverges is in its lack of discouragement of synchronous communication. But if you build your microservices using queues, I think you get the right sized actors with all of those benefits, without going down a rabbit hole of trying to structure every single bit of logic as an actor.
AWS's "Cell Based Architecture" is also just actors, but with its own set of patterns for how large to build them.