"I thought of objects being like biological cells and/or individual computers on a network, only able to communicate with messages (so messaging came at the very beginning -- it took a while to see how to do messaging in a programming language efficiently enough to be useful)...
OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things...
But just to show how stubbornly an idea can hang on, all through the seventies and eighties, there were many people who tried to get by with "Remote Procedure Call" instead of thinking about objects and messages."
So, while it's true that objects can be viewed as are merely state + behaviour, that was not necessarily the original intent.
Kay also said:
I wanted to get rid of data.
In other words, he didn't want objects to be passing data to each other (directly). He wanted objects to send messages to each other - and the messages themselves might happen to have data inside them, if needed.
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".
For those interested, I'd highly recommend looking into the actor model. I think this represents a closer realization of what Kay intended.
On a larger scale, something like event-driven microservices is also within this line of thinking.
I plan this as a series of posts. At some point I want to write posts "What is OOP?" and "What is FP?". The problem with the definition of OOP is that there is no single right definition. I consider 3 main sources (which have equal rights): Simula (Ole-Johan Dahl, Kristen Nygaard), C++ (Bjarne Stroustrup), SmallTalk (Alan Kay).
I need some time to gather full picture, meantime you can consult with those sources:
Interpretation of OOP as The big idea is "messaging" is pretty close to the idea of actor model:
Sending a message to an actor is entirely free of side effects such as those in the message mechanisms of the current SMALL TALK machine of Alan Kay and the port mechanism of Krutat and Balzer.
— A Universal Modular ACTOR Formalism for Artificial Intelligence, Carl Hewitt et al.
This means that you can do things like send messages to objects written in different languages, transmit object definitions by mail, send messages via SMS, etc. In my opinion this is where a lot of the power of “message-passing” lies, but it’s also one of the least explored aspects.
I would agree that it's a messy topic. OOP gets a bad wrap for easily producing messy code. In my experience, using messaging patterns and isolating code properly can avoid this.
There is such a thing as messy and hard-to-understand FP code too 🙃
There is messy OOP code too.
There is well-structured FP. And well-structured OOP.
I enjoyed your article for pointing this out 👌
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I think it's an even more interesting question to ask "What were objects intended to be in the first place?"
Alan Kay is considered one of the fathers of OOP. Here's his take on what he intended objects to be:
So, while it's true that objects can be viewed as are merely state + behaviour, that was not necessarily the original intent.
Kay also said:
In other words, he didn't want objects to be passing data to each other (directly). He wanted objects to send messages to each other - and the messages themselves might happen to have data inside them, if needed.
In another place, Kay said:
For those interested, I'd highly recommend looking into the actor model. I think this represents a closer realization of what Kay intended.
On a larger scale, something like event-driven microservices is also within this line of thinking.
I plan this as a series of posts. At some point I want to write posts "What is OOP?" and "What is FP?". The problem with the definition of OOP is that there is no single right definition. I consider 3 main sources (which have equal rights): Simula (Ole-Johan Dahl, Kristen Nygaard), C++ (Bjarne Stroustrup), SmallTalk (Alan Kay).
I need some time to gather full picture, meantime you can consult with those sources:
Interpretation of OOP as
The big idea is "messaging"is pretty close to the idea of actor model:I like that first article you linked 👍
This stuck out to me:
I would agree that it's a messy topic. OOP gets a bad wrap for easily producing messy code. In my experience, using messaging patterns and isolating code properly can avoid this.
There is such a thing as messy and hard-to-understand FP code too 🙃
There is messy OOP code too.
There is well-structured FP. And well-structured OOP.
I enjoyed your article for pointing this out 👌