A Few Thoughts About "OOP" by Alan Kay

Introduction "OOP" is now a term for a variety of languages and techniques which have little resemblance to the original ideas and their spirit.

~30 years ago I was asked to write a history for the ACM, and this eventually appeared in their "History of Programming Languages II" conference and book. The best online version appeared in SIGPLAN Notices: http://www.smalltalk.org/ downloads/papers/SmalltalkHistoryHOPL.pdf

Histories are tough because "reality is highly detailed". Summaries have to leave things out -- and not just positive influences, but especially negative influences (one can praise an influence without explaining it, but one should not damn an influence without some explanation -- so I simply left out a lot of things I really disliked).

Given that there is a written history, here I can ignore it and just talk about issues.

I spent most of my teen and twenties years (50s and 60s) working in 6 main areas: math, physical sciences, especially the new molecular biology, languages (mainly English), anthropology, music (mostly jazz playing), and theater (mostly technical theater). My general outlook was an un-organized amalgam of these pursuits. I learned to program in the Air Force in the early 60s and was able to use this part- time to put myself through college.

Like most of us, I both (a) "knew less than I knew" and I (b) "knew more than I knew". For example, I knew that a computer could "simulate anything that could be described", but never connected it to computation itself. I knew that "modularity is good in design" but never connected it in a strong way for programming itself.

When I quite accidentally wound up in the ARPA-IPTO research community in grad school, I started having "reactions"/"ideas" -- this was mostly because the community had already had lots of really good ones, many of which had the side effect of debugging (a,b) above.

It is hard to describe how a "strong community of individuals" can really make progress while sustaining both sides of what seems to be a contradiction in terms. There are other interesting and important examples of this, including how the US was invented via its Constitution (and the Convention that made it), Los Alamos, and later, Xerox Parc, which was derived from ARPA-IPTO.

In any case, that community was the reason for most of its ideas -- Context is worth 80 IQ points! -- and I think of the awards given to individuals in that community as actually the province of the entire community including, especially, its funders.

OOP The history gives a partial account of many ideas in the 60s that were "like OOP" being around, but all were addressed to specific problems and lacked both context and a few essential features needed for unification. For example, there was Sketchpad and Simula, there was "data-driven programming (using pointers to procedures in the data itself), there were various kinds of virtualizations of hardware (in time-sharing processes, and especially in the Burroughs B5000). There were attempts at module schemes at many different levels. There were calls for "protection" of state at many different levels of computing, including the call for "relational data bases". There was the combined initiative of the ARPA community to start to make good on its internal demands for an "Intergalactic Network" by first building a packet switching "ARPAnet". There was a strong interest and increasing use of recursive embedding and its more general cousin "reentrant code allowing separate instantiations", etc.

One way to sum up my reaction to all this after being pushed by circumstance was the trivial realization -- but a hard one to see given "Normal" -- that on the one hand you can divide a computer into data structures and procedures -- "Normal" -- but you can also divide a computer into further computers. The latter would be immensely powerful in a myriad of ways compared to the former because retaining a computer retains universality, whereas neither procedures nor date were universal. The results would be breath-taking if the overheads at small scales could be removed, so the principle could be used everywhere.

Just to take one of many examples: if you wanted to send data "a thousand miles" you had to send a manual or a person with it. If you "sent a computer a thousand miles" you would be sending everything needed, and you would be sending it as the real entity "data" actually is (i.e. data just lies there without code, code just lies there without data, so you should package them together to make a viable thing). This suggests among many things that "data" is a bad idea/concept and should be eliminated. Along similar lines the pernicious but needed notion of "type" -- both for dynamic and static typing -- would be answered much more strongly with these packages.

If you wanted something "like data" you could simulate it, and trap attempts to change it if desired. You could go beyond this to "forget about data" and think more in terms of "knowledge" that is being accumulated over time (this would start to overlap with the way "data-bases" in enterprises are actually handled albeit haphazardly). They are versioned, race-conditions are verboten, etc.

These "computers" would intercommunicate via messages, and ideally should act like servers to each other (i.e. a message should not be treated as an external command, but the receiver of the message should have full control of what to do with a message). This meant that procedure calls would be eliminated in favor of looser coupling and something more like a search for resources.

The "computer boundary" and protection and messages all meant that the messages could have abstract "algebraic" qualities where "requests" could be in generic terms, and the "fulfillment" of a request would be idiosyncratic to the receiver.

Since everything in computing requires definition of some kind, the actual parts of the programming language could be simulated by these general computers -- for example, control structures, could easily be made. New kind of language could easily be made. Keeping the messaging system pure and general would allow many kinds of things done ultimately in many kinds of way to be mixed together and interoperate.

This also means that you get layers of "meta" automatically, and they are still defined in terms of these software computers.

Speaking of "operate", such a system could be its own operating system, and the kernel could be astonishingly small.

It would also be a great basis for real-time interaction because the messaging provides the loosely bound system needed for doing everything on the fly.

A programming system could be just conventions about the messages being sent and received, and this could be distributed because each computer can have its own interpreter for the pure message.

The possibilities for scaling were exciting. Large numbers of many sized computers intercommunicating resembles many different levels of Biology, and just a single human being has ~100 trillion cells (~10 trillion with our DNA, plus thousands of species of micro-organisms for the other 90 trillion).

There are many more implications that are exciting and powerful. For example, one could imagine a message send as a "request for resources/services" of some kind. These messages target *ideas* rather than specific computers, and go to facilities that try to find computers than can help with resources and services.

We could imagine moving these computers in time by versioning rather than updating (this is an old idea of McCarthy's). It is particularly easy to set up using this scheme. Similarly "speculative 'possible worlds' evaluation" is a cousin of these ideas). Recent research (by Alex Warth et al. http://www.vpri.org/pdf/ tr2011001_final_worlds.pdf) shows that it can be taken "into the small" as well as the large.

This is also a way to get the benefits from "functional programming" without the liabilities and distortions.

The basic point of this part of the story is that a "unifying principle" can be the most powerful (or the most destructive) idea we can have, because the limited capacity of our minds is greatly amplified by *not* having too many particulars to mess up our 4±3 dynamic mental slots. Looking for unifying principles (as opposed to "hacks") is a way to advance a field that is way behind in its learning curve.

Practicalities The second part of the story is that any new perspective can often require a lot of design and engineering effort to bring it out of the place where dreams are made into practical existence.

For example, it took some work to get "3" to be one of these computers, and have it be as small and run as fast as prior practice -- and part of the solution came from prior practice in Lisp. In fact, Lisp had quite a positive influence on many parts of the realization of these ideas.

Getting every part of a programming system to be made from "computers", especially when running on "a computer that is not made of computers" took several stages. Lisp showed part of it. Smalltalk took this very far. "The Art of the Metaobject Protocol" takes it the rest of the way. It was quite a feat of systems design -- in both Lisp and especially Smalltalk (mostly by Dan Ingalls) -- to allow errors and debugging to happen without penalty while the system itself is running.

Etc.

"OOP" got popular from the success of the Parc systems efforts, but quickly got turned into "just a label" partly because of misunderstanding, partly from laziness, partly from un-careful optimizations, partly from conservatism. It's important to understand that the released version of Smalltalk (-80, at the end of a chain of designs and implementations, -72, -74, -76, -78) was less "object-oriented" in many important ways than -72. The reasons for this are interesting, but out of the scope of this note. However, it's worth noting the many many times in computing the baby has been thrown out with the bath water for sake of hasty near-term optimizations. Much of the time this has created misfortune.

Suggestions What you are looking at in class today and next week are models of "so-called" "OOP" languages. I suggest -- for extra credit, etc. -- that you realize that in such "OOP" languages method sends are actually done as procedure calls -- and usually for procedural reasons. However, if you think of this as an optimization for a real message send, you could think about the desirable behaviors for real sends (think of the Internet etc). For example, what you might like to get back (in any case) is a "future promise" for what may or may not be computed for you as the result of the send. That promise is most powerfully a dynamic object that can tell you how things are doing at the other end. This is useful not just for scaling conventional designs but also is one route into "possible worlds" programming, where you might have many processes working on your behalf.

What kinds of syntax and semantics would help "real OOP" programming with real messages?

One language to look at today is Erlang, which in some ways is much more like the original Parc Smalltalk --> which was the basis for Carl Hewitt's "Actors" --> which heavily influenced Erlang.

What would programming using large parts of the Internet be like? What changes of emphasis need to be made to think on these scales? For example, how much of a liability do "names" and "naming" become?

How would a system that can hugely scale be implemented on a local machine? You just got done with pattern matching. What kinds of pattern matching could you have objects do on incoming messages? When does semantics become more of an issue than syntax?

Would you want to use "expert system" techniques for intercomputer communication?

At what point do you want to "send ambassador objects" rather than static messages?

What would it mean to "ask for resources" that set up "discovery processes"?

What if the people who did http actually were thinking about their situation. They could have defined a start at programming for the Internet, but they completely missed this because they were only trying to do a few simple things rather than paying attention. What conventions would you come up with to make http really useful?

Etc.

We Are Distorting Mirrors The distortions work both ways, sometimes they look like something new and interesting, sometimes they obscure something good already out there. I mentioned my background in the beginning partly to exhibit here how much the background affected the reactions to the research community I had stumbled into.

Mathematics Models whose parts and processes are made from boundary stipulations. Likes powerful unifying abstractions and doesn't like lots of particulars. *Algebras* (in the pure math sense) as a model for how "to simply while amplifying". "Intensional Logic" (Carnap) as a start on locality. Plato's notion of "Ideals" and their shadows.

Science, especially Biology Cells as self-contained life always in an ecology, some of which are colonies and multicelled organisms (which have only one version of DNA but can have several hundred subclasses to make up the cells needed for an organism). Morphogenesis as an aim.

Language What does it mean to communicate? What does a sender do? What does a receiver do? What kinds of negotiations are needed? What does a specific send mean?

Anthropology Humans think they are individuals -- we are -- but we exist within cultures -- we are more like our cultures than we can even contemplate. To a large extent we pretend, and to a large extent we are our pretensions.

Music Is the music in the piano?

Theater A human interacting with a computer is in a context that has tinges of communication, theatrics and performance. What would it mean to include these in the unification (another note, but worth pondering).