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
