A lot of the recent trend towards OOP-bashing comes from bad implementations of OOP, just as bashing design patterns is more to do with badly thought out architectures and overuse of those patterns.<p>In fact, the origins of OOP are basically what we would now call microservice architecture (CSP-inspired languages like Go being a specialisation of this). Each service can be as stateless or as stateful as it needs to be (without shared state) and services should be loosely coupled.<p>That's quite different to most large-scale OOP architectures, but it is possible to code in that style in any OOP language.<p>Heavy reliance on inheritance for code reuse is a whole problem class in itself that again has little to do with OOP and lots to do with the influence of C++.
"OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things. It can be done in Smalltalk and in LISP. There are possibly other systems in which this is possible, but I'm not aware of them."<p>Such a pity that this filtered essence about OOP was lost on me during formative years of learning OO-programming; for no fault of mine! It took me half a decade into professional programming in Java to realize the importance of these key concepts.<p>And the worse part is that most of the books/blogs start OO programming tutorial with examples that try to literally model the problem state using Objects (e.g., "Animals", "Shapes" etc.,).<p>I guess tutorials, classes just focus on these key goals and show how concepts such as "polymorphism", "inheritance" etc., are work towards achieving (or not) them. What generally happens is that one is taught about all these peripheral concepts and students are left to wonder the problems they are trying to solve.
"OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things."<p>Bam. That is it right there. Java really messed this up.<p>Strong static typing and OO is an abomination.
Towards the end:<p><pre><code> 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. Sic
transit gloria mundi.
</code></pre>
Can somebody explain to me what distinction he's drawing here? What's the issue with RPC that's solved by Objects+Messages?
I wonder what he thinks of Erlang, as it's very much about message passing, hiding of process state, and late binding. Of course, this is built at a higher level and it's not turtles all the way down: you don't send messages to numbers to do basic math.
> I wanted to get rid of data.<p>What exactly does he mean by that? How does one get rid of data?<p>> The B5000 almost did this via its almost unbelievable HW architecture.<p>I've heard about the B5000 numerous times here on HN. What was so fantastic about it?
>My math background made me realize that each object could have several algebras associated with it, and there could be families of these algebras<p>Could someone explain what he meant here?
Why Alan Kay came up with object-oriented:<p><i>I wanted to get rid of data.</i><p><i>I didn't understand the monster LISP idea of tangible metalanguage then</i>