"OOP to me means only messaging, local retention and protection and
hiding of state-process, and extreme late-binding of all things."
So this means that languages like Swift, for example, are not OOP?
hiding of state-process, and extreme late-binding of all things."
So this means that languages like Swift, for example, are not OOP?
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.
Swift claims to be protocol-oriented, actually. [0] is a video about it from Apple's WWDC in 2015.
https://blog.metaobject.com/2015/06/protocol-oriented-progra...
I agree with the article that POP is OOP in a very real sense. As the article puts it: "The simple fact is that actual Object Oriented Programming is Protocol Oriented Programming, where Protocol means a set of messages that an object understands." This I 100% agree with.
But the fact of the matter is that many people do not consider the message-passing to be what defines OOP these days. I'm not saying these people are right, but rather that the common usage of the term does not align with the original use. When people teach OOP today, they teach it in terms of inheritance and methods and access modifiers. I don't think the word "message" even came up in this context once in my undergraduate studies.
I think Swift's usage of the term "protocol-oriented programming" is to distinguish themselves from the modern concept of OOP. If they said "Swift is an OO language, but we try to avoid classes and inheritance where possible", the developers trained in programs like mine would lose their minds because to them the two are one and the same.
So I don't think it's a "marketing claim" in the sense that I don't think they're using it to say "Ooh, look, we developed a whole new paradigm of programming!" Rather, I think they're trying to distinguish themselves from languages like Java (the current paragon of OOP it seems) which are 100% based on inheritance and encapsulation and couldn't care less for passing messages (explicitly).