I think Erlang has the most developed version of Alan Kay's original conception of OOP. Here are Kay's words:
> Erlang is much closer to the original ideas I had about “objects” and how to use them. (https://qr.ae/pYTn7A)
But the he says this, which I really appreciate:
> However, another way to look at this is to consider “What Is Actually Needed” (WIAN) and realize that much more is needed beyond what we are programming in today.
I've always thought the essence of Kay's vision for OOP as designing software such that the basic unit of abstraction carries the same power (universal computation) as the whole, a process which he refers to as "the basic principle of recursive design", while taking a cue from the most powerful such system known to us (biology).
> "the translation of this model into machine terms for me 25 years or so was that these biological cells acted a lot as though they're on a network, you can think of it as a crossbar switch or a Ethernet type network in which every object can send to every other object and each one of these is a lot like a mini computer. In fact it is very difficult in a good object-oriented system to find out where the hardware stops and where the software begins and this notion of a little computer in the large here is something that is worthwhile considering when making very small things. Now there is a principle in design that people came up with many years ago, it's called the basic principle of recursive design and the idea is make the parts have the same power as the whole [...] now another thing that crossed my mind when I was pondering these ideas back in the 60s was why if that is such a powerful idea, why is it that we take a very powerful idea like a computer and dilute it immediately in most programming languages by dividing it up into data structures and procedures. Data structures don't have the same power as a computer, they're static [...] procedures don't have the same power as computers because they can't remember state, they have to have something additional [...] what if you didn't do that? What if the only subdivision you ever made in a programming language was a subdivision of a computer into a computer, you're never allowed to subdivide the computer into something that was less than a computer [...] that means that each subdivision has to be something like a black box that has inside of it some mixture of state and process. From the outside, you can only invoke behavioral attributes rather than invoking method attributes"
2. here he refers to the abstraction as "virtual computers" and talks about how a focus on pragmatics leads one astray (makes one wonder how much this has cost us, ex: how often do we think of objects as virtual computers in mainstream 'OOP'?), https://youtu.be/kgmAwnNxdgw?t=7279
> "again it's pragmatics that hurts the idea, it's the simplest idea that there is, that if you have a computer, you can do any computation, you can represent any data structure, so it should be a complete, instant deduction that oh if I want to make a computing system I should just make virtual computers because that will allow me to define anything else and I have a universal way of doing it and people still don't use what they call OOP today to do that. They just can't see it and there's something about a computer, even today when they are a lot smaller where the pragmatic reality of the computer constrasted with what it is virtually or what it is semantically [...] one of the ways to look at it is one of the biggest problems in programming in every era [...] people get caught up with the pragmatics and the number one problem with optimization and pragmatics is that once you put that hat on, and we can all do it, it is almost impossible to design [?]"
---
I definitely agree that of the widely accessible programming languages today, Erlang is the closest (though still short) reification of Kay's vision and the fact that it converged on the same design (mostly) independently should lend credence to the fact that it's a powerful idea:
- messaging: only means of communication between processes is message-passing, how information propagates
- local retention and protection and hiding of state-process: each process is like a self-contained virtual machine with its own completely isolated stack & heap, strong isolation & encapsulation
- late binding of all things: process behaviour is dynamic and unconstrained, it decides what actions to take or not in response to an incoming message at runtime including changing itself which allows extension without modifying existing code (ex: hot code reload)
I can also definitely appreciate Kay's challenge to consider “What Is Actually Needed”, which to me potentially points to the 'meaning-making' aspect as a missing piece of the puzzle on which we've made little to no progress. This is an open and hard problem and I suspect Kay's own views on the interpretation (https://news.ycombinator.com/item?id=11945722) and preservation (https://tinlizzie.org/VPRIPapers/tr2015004_cuneiform.pdf) of information are somehow related to this :)
Containerized microservices can be considered independant objects. They are way heavier on resources than Erlang green threads though.
Akka offers similar capabilities. Late binding can be replaced by a tech agnostic exchange format such as json, xml, etc. This way, you can change a part of the system without affecting the other. The trade off is that by having statically typed language, you have to separate the packages strategically ; with Erlang, you can just swap an Erlang file with another and that's it ; same thing with Smalltalk.
I agree with you, all these things looks a lot more like what Alan Kay said about OOP !
the way you describe it reminds me of Erlang and actors.
How is that relate to your definition of OOP?
Great question!
I think Erlang has the most developed version of Alan Kay's original conception of OOP. Here are Kay's words:
> Erlang is much closer to the original ideas I had about “objects” and how to use them. (https://qr.ae/pYTn7A)
But the he says this, which I really appreciate:
> However, another way to look at this is to consider “What Is Actually Needed” (WIAN) and realize that much more is needed beyond what we are programming in today.
There's still more work to do!
I've always thought the essence of Kay's vision for OOP as designing software such that the basic unit of abstraction carries the same power (universal computation) as the whole, a process which he refers to as "the basic principle of recursive design", while taking a cue from the most powerful such system known to us (biology).
Some favourite instances of him covering this:
1. On the inspiration and central idea, https://youtu.be/QjJaFG63Hlo?t=845
> "the translation of this model into machine terms for me 25 years or so was that these biological cells acted a lot as though they're on a network, you can think of it as a crossbar switch or a Ethernet type network in which every object can send to every other object and each one of these is a lot like a mini computer. In fact it is very difficult in a good object-oriented system to find out where the hardware stops and where the software begins and this notion of a little computer in the large here is something that is worthwhile considering when making very small things. Now there is a principle in design that people came up with many years ago, it's called the basic principle of recursive design and the idea is make the parts have the same power as the whole [...] now another thing that crossed my mind when I was pondering these ideas back in the 60s was why if that is such a powerful idea, why is it that we take a very powerful idea like a computer and dilute it immediately in most programming languages by dividing it up into data structures and procedures. Data structures don't have the same power as a computer, they're static [...] procedures don't have the same power as computers because they can't remember state, they have to have something additional [...] what if you didn't do that? What if the only subdivision you ever made in a programming language was a subdivision of a computer into a computer, you're never allowed to subdivide the computer into something that was less than a computer [...] that means that each subdivision has to be something like a black box that has inside of it some mixture of state and process. From the outside, you can only invoke behavioral attributes rather than invoking method attributes"
2. here he refers to the abstraction as "virtual computers" and talks about how a focus on pragmatics leads one astray (makes one wonder how much this has cost us, ex: how often do we think of objects as virtual computers in mainstream 'OOP'?), https://youtu.be/kgmAwnNxdgw?t=7279
> "again it's pragmatics that hurts the idea, it's the simplest idea that there is, that if you have a computer, you can do any computation, you can represent any data structure, so it should be a complete, instant deduction that oh if I want to make a computing system I should just make virtual computers because that will allow me to define anything else and I have a universal way of doing it and people still don't use what they call OOP today to do that. They just can't see it and there's something about a computer, even today when they are a lot smaller where the pragmatic reality of the computer constrasted with what it is virtually or what it is semantically [...] one of the ways to look at it is one of the biggest problems in programming in every era [...] people get caught up with the pragmatics and the number one problem with optimization and pragmatics is that once you put that hat on, and we can all do it, it is almost impossible to design [?]"
---
I definitely agree that of the widely accessible programming languages today, Erlang is the closest (though still short) reification of Kay's vision and the fact that it converged on the same design (mostly) independently should lend credence to the fact that it's a powerful idea:
- messaging: only means of communication between processes is message-passing, how information propagates
- local retention and protection and hiding of state-process: each process is like a self-contained virtual machine with its own completely isolated stack & heap, strong isolation & encapsulation
- late binding of all things: process behaviour is dynamic and unconstrained, it decides what actions to take or not in response to an incoming message at runtime including changing itself which allows extension without modifying existing code (ex: hot code reload)
My favourite illustration of these is Joe Armstrong's Universal Server (https://joearms.github.io/published/2013-11-21-My-favorite-erlang-program.html)
I can also definitely appreciate Kay's challenge to consider “What Is Actually Needed”, which to me potentially points to the 'meaning-making' aspect as a missing piece of the puzzle on which we've made little to no progress. This is an open and hard problem and I suspect Kay's own views on the interpretation (https://news.ycombinator.com/item?id=11945722) and preservation (https://tinlizzie.org/VPRIPapers/tr2015004_cuneiform.pdf) of information are somehow related to this :)
Agreed.
Containerized microservices can be considered independant objects. They are way heavier on resources than Erlang green threads though.
Akka offers similar capabilities. Late binding can be replaced by a tech agnostic exchange format such as json, xml, etc. This way, you can change a part of the system without affecting the other. The trade off is that by having statically typed language, you have to separate the packages strategically ; with Erlang, you can just swap an Erlang file with another and that's it ; same thing with Smalltalk.
I agree with you, all these things looks a lot more like what Alan Kay said about OOP !
“Peering”. Ok. Sorry for the initial misread.