[FoRK] [fonc] Terminology: "Object Oriented" vs "Message Oriented"
eugen at leitl.org
Tue Feb 12 09:20:10 PST 2013
----- Forwarded message from Alan Kay <alan.nemo at yahoo.com> -----
From: Alan Kay <alan.nemo at yahoo.com>
Date: Tue, 12 Feb 2013 08:23:21 -0800 (PST)
To: Fundamentals of New Computing <fonc at vpri.org>
Subject: Re: [fonc] Terminology: "Object Oriented" vs "Message Oriented"
Reply-To: Alan Kay <alan.nemo at yahoo.com>,
Fundamentals of New Computing <fonc at vpri.org>
I think how this happened has already been described in "The Early History of Smalltalk".
In the Fall of 1966, Sketchpad was what got me started thinking about "representing concepts as whole things". Simula, a week later, provided a glimpse of how one could "deal with issues that couldn't be done wonderfully with constraints and solving" (namely, you could hide procedures inside the entities).
This triggered off many thoughts in a few minutes, bringing in "ideas that seemed similar" from biology, math (algebras), logic (Carnap's intensional logic), philosophy (Plato's "Ideas"), hardware (running multiple active units off a bus), systems design (the use of virtual machines in time-sharing), and networking (the ARPA community was getting ready to do the ARPAnet). Bob Barton had pronounced that "recursive design is making the parts have the same powers as the wholes", which for the first time I was able to see was really powerful if the wholes and the parts were entire computers hardware or software or some mixture.
The latter was hugely important to me because it allowed a "universal simulation system" to be created from just a few ideas that would cover everything and every other kind of thing.
During this period I had no label for what I was doing, including "this thing I was doing", I was just doing.
A few months later someone asked me what I was doing, and I didn't think about the answer -- I was still trying to see how the synthesis of ideas could be pulled off without a lot of machinery (kind of the math stage of the process).
Back then, there was already a term in use called "data driven programming". This is where "data" contains info that will help find appropriate procedures.
And the term "objects" was also used for "composite data" i.e. blocks of storage with different fields containing values of various kinds. This came naturally from "card images" (punched cards were usually 80 or more characters long and divided into fields).
At some point someone (probably in the 50s) decided to use some of the fields to help the logic of plug board programming and "drive" the processes off the cards rather than "just processing" them.
So if you looked at how Sketchpad was implemented you would see, in the terms of the day: "objects that were data driven". Ivan gives Doug Ross credit for his "plex structures", which were an MIT way to think about these ideas. Sketchpad also used "threaded lists" in its blocks (this was not a great idea but it was popular back then -- Simula later took this up as well).
So I just said "object oriented programming" and went back to work.
Later I regretted this (and some of the other labels that were also put in service) after the ideas worked out nicely and were very powerful for us at PARC.
The success of the ideas made what we were doing popular, and people wanted to be a part of it. This led to using the term "object oriented" as a designer jeans label for pretty much anything (there was even an "object-oriented" COBOL!). This appropriation of labels without content is a typical pop culture "fantasy football" syndrome.
PARC was an integral part of the ARPA community, the last gasp of which in the 70s was designing the Internet via a design group that contained PARC people (PARC had actually already done an "internetwork" -- called PUP -- with "gateways" (routers) to interconnect Ethernetworks and other networks within Xerox).
It was clear to all in this community from the mid-60s onward that how "messaging" was done was one of the keys to achieving scaling. This is why "what I was working on" had "messages" as the larger coordination idea (rather than the subset of "calls").
At PARC we wanted to do a complete personal computing system on the Alto, which was a microcoded ~150ns cycle CPU with 16 program counters and 64k 16bit words of memory that cycled at ~750ns (where half of this memory was used for the bit-map of the display). The next level memory was not a swapping disk but a slower removable disk with about 2.5MBytes capacity.
The good news was that the Alto was fast enough to run Smalltalk byte codes and bitblt, etc. to allow executables to be small and powerful. The bad news was that it wasn't quite fast enough to do real messaging. The good news was that Smalltalk was powerful expressively, and this allowed the whole size of the system including "OS", language, apps, UI, etc., to be tiny (about 10K lines of program code initially). This allowed us to pretend we had messaging but to actually do procedure calls under the covers and get away with it (one of the ideas was to not manifest a "message" unless someone wanted to see it -- this was part of the magic of Dan Ingalls' design).
So I think the problem with "messaging" was partly that it was the more subtle and invisible idea and this "verb part") got lost because the representational "noun part" got all the attention. (And we generally don't think of noun-like things as "in process".) This is part of the big problem in "OOP" today, because it is mostly a complicated way of making new data structures whose fields are munged by "setters".
Back to your original question, it *might* have helped to have better terminology. The Simula folks tried this in the first Simula, but their choice of English words was confusing (they used "Activity" for "Class" and "Process" for "Instance"). This is almost good and much more in keeping with what should be the philosophical underpinnings of this kind of design.
After being told that no one had understood this (I and two other grad students had to read the machine code listing of the Simula compiler to understand its documentation!), the Nygaard and Dahl chose "Class" and "Instance" for Simula 67. I chose these for Smalltalk also because why multiply terms? (I should have chosen better terms here also.)
To sum up, besides the tiny computers we had to use back then, we didn't have a good enough theory of messaging -- we did have a start that was based on Dave Fisher's "Control Definition Language" CMU 1970 thesis. But then we got overwhelmed by the excitement of being able to make personal computing on the Alto. A few years later I decided that "sending messages" was not a good scaling idea, and that something more general to get needed resources "from the outside" needed to be invented.
> From: Loup Vaillant <l at loup-vaillant.fr>
>To: Fundamentals of New Computing <fonc at vpri.org>
>Sent: Tuesday, February 12, 2013 7:15 AM
>Subject: [fonc] Terminology: "Object Oriented" vs "Message Oriented"
>This question was prompted by a quote by Joe Armstrong about OOP.
>It is for Alan Kay, but I'm totally fine with a relevant link. Also,
>"I don't know" and "I don't have time for this" are perfectly okay.
>Alan, when the term "Object oriented" you coined has been hijacked by
>Java and Co, you made clear that you were mainly about messages, not
>classes. My model of you even says that Erlang is far more OO than Java.
>Then why did you chose the term "object" instead of "message" in the
>first place? Was there a specific reason for your preference, or did
>you simply not bother foreseeing any terminology issue? (20/20 hindsight and such.)
>Bonus question: if you had choose "message" instead, do you think it
>would have been hijacked too?
> (This is for reference, you don't really need to read it.)
>fonc mailing list
>fonc at vpri.org
fonc mailing list
fonc at vpri.org
----- End forwarded message -----
Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org
ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org
8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE
More information about the FoRK