Hint: as I mentioned previously, you don't need a method dictionary, 
classes, inheritance, etc. You don't even need "state" in the way it 
is usually thought of. The essence is that of communicating computers 
as looked at from the outside. If you can make the insides look like 
the outsides "all the way down" then you have something very 
interesting and powerful.

And yes, the original theory of Smalltalk was just this (since even 
the syntaxes used are definable by interior actions of how the 
"computers" recognize and receive messages). The interesting and 
difficult parts here are design decisions about architectural 
conventions that allow the universal mechanisms to be used with 
minimal pain and maximum expression and scalability by humans.

Each of the 4 Smalltalks in the 70s made different choices (plus the 
PIE system of Goldstein & Bobrow), and it's a pity that there have 
been so few experiments since Smalltalk-80 came out of PARC.

But check out some of Mark Lentzner's stuff: Codeworks, Wheat, etc. 
Look at Joe Goguen's ideas about closer analogies to algebras as the 
interface, etc. Ken Kahn's various designs over the years are 
extremely interesting. Several of the designs I did after leaving 
PARC -- Rainbow, and the original Playground (quite different from 
each other and I'm not sure where either set of papers is anymore) -- 
still seem to be interesting to me. David Reed's NAMOS is the basis 
of Croquet. And, of course, Andreas Raab's not too far away Tweak 
design is a *really interesting* set of ideas....

However, there have been many interesting ideas over the years that 
have had little effect because they lacked enough pragmatic reality 
via great implementations (and certainly vice versa: an incredible 
number of systems used today have weak ideas but were implemented 
well enough to spread).

Cheers,

Alan

At 9:42 AM -0800 11/16/03, Rob Withers wrote:
>Hi Alan,
>
>--- Alan Kay <Alan.Kay at squeakland.org> wrote:
>>  Hi Rob --
>>
>>  At 6:19 PM -0800 11/14/03, Rob Withers wrote:
>>  >Alan, these posts are always so stimulating.  Could
>>  >you tell me a little about abstact algebras and how
>>  >you relate them to computers sending messages to
>>  other
>>  >computers?  Is it related to defining languages, in
>>  >some way?
>>
>>  Originally, algebra was a symbolic form of
>>  arithmetic. In the 19th
>>  century, mathematicians realized that there were
>>  lots of other
>>  systems that had some of the properties of numbers,
>>  and they gave
>>  such systems with various overlaps to numbers, names
>>  such as groups,
>>  fields, rings, etc., and algebras. This then became
>>  a useful metaphor
>>  and goal: to try to find common properties of
>>  systems and abstract
>>  them into the simplest schemes that covered all of
>>  them.  So, e.g, a
>>  number of the object-like systems I saw in the 60s,
>>  such as
>>  Sketchpad, used a particular offset in the layout to
>>  find the pointer
>>  to (say) the display subroutine for that kind of
>>  object. Today we
>>  call that polymorphism, but this term is borrowed
>>  from theory of
>>  functions and is not quite right. In any case, once
>>  you have an
>>  inside and an outside, and try to do everything
>>  through embedded
>>  procedures of some kind, you have set up the
>>  possibility for an
>>  "algebra" of meaning that could extend over all
>>  objects. Clearly, a
>>  good job of this cuts down the size and nomenclature
>>  of the concept
>>  space. This thinking was before APL, but not before
>>  Iverson's book
>>  that defined a more comprehensive version of APL,
>>  and it occured to
>>  me that you could go much further than Iverson did
>>  with what I called
>>  "generic procedures".
>
>We have a system of objects in an image, and there is
>an algebra defined for these objects.  These objects
>can be transformed by "primitive" operations.   Is our
>algebra defined by the Interpreter, both it's
>bytecodes and msg lookup mechanism?
>
>So there must be an extended definition of what is an
>object in this system.  An object has identity, state
>and a class, with a method dictionary filled with
>procedures.  Then all functions are recursive in a
>sense, due to the fact that they can invoke any
>primitive operation or recurse with another msg send
>to any visible object.
>
>It has nothing to do with Smalltalk, the language.  We
>can have any number of languages describing functions
>in this algebraic system!  Wow!  I feel like I am
>starting to get the mathematical underpinnings of what
>we really have here.
>
>>
>>  >
>>  >you also wrote:
>>  >
>>  >>  An interesting consequence of this structure was
>>  >>  that protection was
>>  >>  complete in ST-72, and all messages could be
>>  >>  serialized if the object
>>  >>  wanted (we did not bother with this because we
>>  were
>>  >>  working on
>>  >>  different kinds of problems -- but Hewitt
>>  thought
>>  >>  about it a lot).
>>  >
>>  >Could you say a little more about why protection
>>  was
>>  >ensured?
>>
>>  In the very same way that a computer on the Internet
>>  is quite
>>  intrinsically safe -- no outside entity can force
>>  anything because
>>  the computer has to run some of its own code before
>>  anything can be
>>  admitted and acted upon. To hurt a computer it has
>>  to have stupid and
>>  foolable SW. The ST-72 objects were only given a
>>  pointer to the
>>  message and the knowledge that a message was trying
>>  to be sent. They
>>  had to do the rest of the work to receive the
>>  message, and they had
>>  full power to act or not.
>
>ok.  It sounds expensive.  This topic has probably
>been discussed elsewhere - currently squeak can walk
>it's stack and get inside.
>
>
>>  >  Also, I like the implications of serializing
>>  >all msgs.  How did this work in these systems?
>>
>>  As I said, we didn't do very much about this, but
>>  part of the style
>>  that the first Simula used, and the later Hewitt
>>  Actors inspired by
>>  ST-72 were very much concerned about serializing.
>>  Again, thinking of
>>  an object as a computer, it was quite possible to
>>  make objects that
>>  would implement ques, etc., that would handle or
>>  reject messages in
>>  serial order. This is part of Dave Reed's scheme in
>>  his '78 MIT
>>  thesis and in his part of Croquet.
>
>I am reading it again.  I misunderstood "serializing"
>to mean encoding a msg into a flat representation,
>rather than ordering multiple msg sends.
>
>thank you,
>Rob


--