I just came across this video of Alan Kay delving deep into what "object oriented" really meant, and how it differs from other systems and languages that later claimed to be OO: There's also this similar (shorter and less in-depth) one by Dan Ingalls: A few interesting points that I gathered: * It's not OO without message passing (e.g. you can request an object to do something, but it's not a command like a method-call is). * This is partly so that the "message" remains intact at runtime, rather than being compiled away, so that (for example) you could later substitute different objects that reasons to the same messages, without breaking anything. * Classes and static types are not that important. It's more about the objects and messages * One goal is to get rid of the idea of "control flow" passing from one object to another, and instead have each advertize what it needs or what it's intent is, and let a kernel do the "wiring" automatically. Objects can thus run in parallel, or even in different machines, and the communication / execution is the same. * Modularity actually ends up being much less important than having much smaller systems & code. The OO approach Kay gives (if done right) allows code to be reduced enormously, but at the cost of not being modular. But so what, because the whole thing (whatever it may be) is very simple to understand and maintain and change. * Apparently MVC (model, view, controller) was built-in, and you never need any code for keeping track of or updating what is displayed anywhere. Instead, each object just provides a spec for how it should be drawn or displayed, and the kernel automatically takes care of getting updated views of the object at regular intervals (when it has changed) (I might have some of this a bit wrong, and maybe some of it is specific to SmallTalk. My point here is just to give a hint of what you might find in these videos, and what you might think about if you (e.g. @jdjakub?) want to experiment with an "actual" OO system)

Great find Dan!

One goal is to get rid of the idea of "control flow" passing from one object to another, and instead have each advertize what it needs or what it's intent is, and let a kernel do the "wiring" automatically. Objects can thus run in parallel, or even in different machines, and the communication / execution is the same.

Sounds a bit like the 'wish' idea in Dynamicland: https://rsnous.com/posts/notes-from-dynamicland-geokit/#background-on-realtalk

the original OOP of Alan Kay's design has made something of a comeback in the form of the actor model https://en.wikipedia.org/wiki/Actor_model