> that suggests we got OOP wrong, very wrong.
Alan Kay very clearly states that people "got it wrong" and that OOP was supposed to be about messaging. ie: He intended for it to be one thing, but it isn't that thing.
> I'm sorry that I long ago coined the term "objects" for this topic because it gets many people to focus on the lesser idea. The big idea is "messaging"
> The key in making great and growable systems is much more to design how its modules communicate rather than what their internal properties and behaviors should be. [..]
http://wiki.c2.com/?AlanKayOnMessaging
https://computinged.wordpress.com/2010/09/11/moti-asks-objec...
I agree that these are Kay's thoughts and also agree with his take on what it should be. But I think the reality is more complicated than it simply being something that evolved away from his grand dream. It's more that there was a soup of ideas floating around during that time that came together as OOP and the combination that became dominant was something else. For instance Simula was already using inheritance prior to Kay's message passing proposal.
He may have coined the term, but he doesn’t own it, nor should we feel beholden to his vision dating back to 1972.
What I said was if the primary reason for micro services is hiding of state, then we got OO wrong, because OO, even the much maligned J2EE style of OO, can do that for us if we want hiding of state and message passing.
Another possibility is that microservices do much more for us than hiding of state and limiting communication to message-passing.
At my 9-5, we use Elixir to write our services and have a few Actor-based Scala services too, so my feeling is that we actually are doing OO fine, and that there’s something else that makes microservices compelling at scale.
> If we need microservices to accomplish isolation of state, that suggests we got OOP wrong, very wrong.
That’s the last sentence, which summarizes my point.
As for Dr. Kay, his exact words were saying that to him at the time OO was certain concepts and nothing more.
I have never interpreted that to mean that languages or systems that do more than hiding state and message passing are wrong, just that if we say something like “OO requires inheritance,” he would disagree with our definition of OO.
After all… Smalltalk itself has a lot more than hiding of state and message passing. Would anyone claim that Dr. Alan Kay would say Dr. Alan Kay was doing OO wrong?
I think there are good reasons to design microservice architectures, but if the argument is “Let’s break up our monolith so we can hide state,” I’d say that we can go ahead and just use our existing OO tools to achieve that.
It does, but that's because there are different flavors of OOP. Alan Kay's original take on OO was closer to the actor model than what grew into the mainstream spin on OOP with inheritance and the rest.
If you take 10 steps back and squint, microservices & the actor model start to look pretty similar.
I don't think there's any question about that.
The only language that really seems to get this right is Erlang (and Elixir).
And I suppose Smalltalk, but I don't think even Smalltalk takes it as far as the Erlang VM.
https://softwareengineering.stackexchange.com/questions/3019...
Dr. Alan Kay would like a word. This is literally the premise behind OO:
> "OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things."—Dr. Alan Kay
Outside of "extreme late-binding," which is a fascinating topic in its own right, isolating state is exactly the point of OOP. If we need microservices to accomplish isolation of state, that suggests we got OOP wrong, very wrong.