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

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: [VIDEO]

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] [VIDEO]

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: [VIDEO] )

>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": [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.

Some of the ideas that were translated to reality are covered here: [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]

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] [VIDEO] [3] [LINK]

> 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] [VIDEO] (he starts talking about that around 12 mins)