Could not resist the pun

iTypos expected from iPhone; please forgive

Mobile: 6127434923

On Feb 12, 2013, at 8:50, "Brown, John Mickey" <> 

> Dude….   You said shiny "objects"….    Lol.
> Messaging certainly seems to have a larger focus with multi-core, many-core, 
> and cloud computing concepts (that itself is morphing into shiny objects).
> I also enjoy these history lessons and discussions.
> John
> From: David Hussman <>
> Reply-To: Fundamentals of New Computing <>
> Date: Tue, 12 Feb 2013 11:36:35 -0500
> To: 'Alan Kay' <>, 'Fundamentals of New Computing' 
> <>
> Subject: Re: [fonc] Terminology: "Object Oriented" vs "Message Oriented"
> Alan,
> Thanks for the thoughtful words / history. I am a lurker on this group and I 
> dig seeing this kind of dialog during times when I am so often surrounded by 
> bright shiny object types.
> David
> From: [] On Behalf Of Alan 
> Kay
> Sent: Tuesday, February 12, 2013 10:23 AM
> To: Fundamentals of New Computing
> Subject: Re: [fonc] Terminology: "Object Oriented" vs "Message Oriented"
> Hi Loup
> I think how this happened has already been described in "The Early History of 
> Smalltalk". 
> But ....
> 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.
> Cheers,
> Alan
> From: Loup Vaillant <>
> To: Fundamentals of New Computing <> 
> 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[1].
> 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?
> Thanks,
> Loup.
> [1]:
>     (This is for reference, you don't really need to read it.)
> _______________________________________________
> fonc mailing list
> _______________________________________________
> fonc mailing list
fonc mailing list

Reply via email to