Seminar with Alan Kay on Object Oriented Programming (VPRI 0246)

I think this is a fair assessment. I agree that Smalltalk is by far not a complete solution to the problem of building and maintaining complex system but "only" an attempt. I found that message passing is an elegant approach to have interoperability on a very basic level. But when protocols and interactions between objects get more complex, it becomes more difficult retain control and comprehension of the evolving system, thus fundamentally better approaches and methods are needed than what is present in a typical Smalltalk system. You might be interested in watching Alan Kay's seminar on object-oriented programming, in which he sketches some ideas on how to modularize an OO system, notably, using a kind of specification language to describe the functions/needs of components and letting the underlying system figure out how to hook them up and deliver messages automatically (as opposed to the direct message passing style in traditional Smalltalks). The relevant part can be found here [1], but I found the entire talk worth watching, since a whole set of issues with OOP and Smalltalk (difficulties in finding and reusing components, weak generality) is being touched upon. Unfortunately, as far as I know, none of the critical ideas have been crystallized into a new kind of Smalltalk - which would be more focused on working on sets of components instead of individual objects/classes (or paraphrasing Alan Kay, making "tissues"). [1] ▶ this video

Most Alan Kay's presentations I've seen were worth watching. Tons of great ideas in each. They really improved how I reason about systems. There is this famous talk from OOPSLA 1997: link If you want to see what "practical" OOP looked like in the 80s, this is a good video: ▶ this video

This video contains many serious misrepresentations. For example, it makes a claim that Alan Kay only started talking about message-passing only in 2003 and that it was a kind of backpedaling due the failures of the inheritance-based OOP model. That is a laughable claim. Kay had given detailed talks discussing issues of OOP, dynamic composition and message-passing in mid-80s. Some of those talks are on YouTube: ▶ this video Also, earlier versions of Smalltalk did not have inheritance. Kay talks about this is his 1993 article on the history of the language: link Dismissing all of this as insignificant quips is ludicrous.

> His messages are directed to specific objects, whereas in a biological system, enzymes and the like are dumped into the bloodstream indiscriminately without a specific target. he actually goes into this in one of his (many) talks where he explains what some next steps might be for objects to "sense their environment" and message into the ether so-to-speak very similar to how you describe [0] [0] ▶ this video (he starts talking about that around 12 mins)

That's interesting. Thanks for the paper. I skimmed through it, but I did not get every detail, since it's been a long time I worked with languages like ML or Haskell and my formal background is a bit rusty at the moment. I do like the premise that, if I understood correctly, (1) you want to specify your computations with the most suitable representation(s) and you want them to be inter-operable. Also, (2) I find it interesting how the tension between pattern matching on explicit representations and abstract data types with information hiding can be reconciled. On a less formal side, the Personal Information Environment done at Xerox PARC, extended Smalltalk with perspectives, which addresses point (1) from a different angle [1], but the multiple perspectives system is bolted on and requires tooling. Also the scope is a bit broader, since PIE also addresses the integration of non-functional artifacts (documentation and so forth). I don't know if that can be done more cleanly without rethinking the entire object and interaction model. Taken (1) a bit farther, you end up with a configuration language (that Alan Kay discussed in a Seminar) and the system is responsible for delivering appropriated objects to the methods (or processes). For larger systems I consider that as a must, because without that kind of modularity your components accumulate all sorts of different contexts, which makes it difficult to understand the evolution of the system or take requirements out of the sys

An "everything app" is just an operating system. There is nothing to picture, we've been having them since the 1950s [1]. We could imagine some new way of operating over systems: for instance the Alan Kay original meaning of object-orientedness [2], or instead of a compiled binary to have some stable diffusion model + large language model which hallucinates the OS on the go [3]. But that's not what the quantifiably greediest person on the planet has in mind, by "everything app" they just mean "everything must be controlled by me, not by you". [1] link [2] ▶ this video [3] link

Some of the ideas that were translated to reality are covered here: ▶ this video Some of them never got fully translated to reality at Xerox because of various reasons (e.g. memory limitation of hardware at the time). This is worth a read: link

>Can we extend that logic to classes or interfaces? This was one of the main ideas behind the original definition of OOP. The original notion of "object" was very similar to our current notion of "service": ▶ this video Objects received messages, including messages sent over the network. There was not supposed to be a clear distinction between local and remote services - by design. A lot of inter-computer stuff could be/was handled transparently.

I'm watching some OOP videos from mid-eighties right now. Can't shake the feeling that the original notion of OOP was solving the same problems as microservices try to solve today, but with far more elegance and more coherent theoretical framework. (Example: ▶ this video )