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: fonc-boun...@vpri.org [mailto:fonc-boun...@vpri.org] 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 <l...@loup-vaillant.fr>
To: Fundamentals of New Computing <fonc@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[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]: http://news.ycombinator.com/item?id=5205976
    (This is for reference, you don't really need to read it.)
_______________________________________________
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc



_______________________________________________
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc

Reply via email to