Self

Alan Kay Alan.Kay at disney.com
Sun Nov 7 17:52:43 UTC 1999


Henrik --

Your wish is my command ...

There are many excellent ideas in Self and we should celebrate all such
attempts at making better languages and programming environments. As you
mentioned, some of them were early themes in OOP and in the development of
Smalltalk -- but it doesn't matter so much where good ideas come from as
much as them being good, and for them to appear.

I was one of Alan Borning's thesis advisors and one of the specific plans
for Thinglab was for it to explore the idea of prototypes as "exemplars" of
their instances. I was very happy to see Self try a prototype based
approach as well.

Also, the earliest Smalltalks made no distinction between "instance
variables" and "methods", and many different forms were proposed for how to
make them one idea (not all were implemented), including the idea of a
uniform slot structure. Also, in Smalltalk-72, variables were objects and
could be talked to directly, etc.

So, there are many things to like about Self. The aspects of Self I found
less appealing were those that dealt with meta-issues like "classness",
inheritance, underlying frameworks, reflection, etc. Here I felt that Self
was too LISP-like, and didn't do a great job of either protecting its
metasystem or of representing it.
     For example, classes don't have to be put in opposition to prototypes.
Both are great ideas and both are needed. Why "classness" if you have
prototypes? Because the abstraction of a class tells you really useful
things about its instances (that is to say, "types" are a great and
necessary idea, but they can't be allowed to get in the way). Just as
assigning to a variable is one metalevel deeper than getting a value from a
variable or a function (and should therefore be protected by some metafence
like an encapsulation abstraction), it is also the case that getting
instances from another structure is a metalevel deeper than just copying,
and it needs to be protected and aided by an abstraction.
     This is not to say that these deep ideas shouldn't be maleable at some
level of the system, it's that they shouldn't be gratuitously visible to
the vagaries of programmers who are in a debugging frenzy. One of the
reasons I don't like FORTH e.g. is that it has a visible stack, both CLOS
and Self have visible inheritance mechanisms, etc.
     In sum, I believe that anything that can be changed in one place, but
felt later at many places is "meta" and needs to be carefully handled,
otherwise a mockery is made of the attempt to look at a piece of code and
unambiguously understand what it says.

I remember being very surprised that John Maloney expressed happiness and
some relief when he joined us at Apple and started to use the ancient ideas
of Smalltalk again. I don't think it was because the old ideas in Smalltalk
are still the frontline great ideas -- they've at least slipped to "good"
by now -- but it was because he was back in the total environment that Dan
Ingalls and other Smalltalkers created to write large amounts of real code
in.
     That brought home to me yet again just how much of a language is its
practical environment, and how much people like Dan have meant to Smalltalk
because of their willingness to not just do the big exciting experimental
features, but to do the hundreds and hundreds of little things that make
the excitement sustainable.

That being said, I'm still very interested (as are Dan and the rest of SC)
in improving Smalltalk as a language qualitatively. I'm hoping we can get
started sometime next year after we round off the current phase of our
plans.

Cheers,

Alan

----------

At 8:22 AM -0800 11/7/99, Henrik Gedenryd wrote:
>> I think I saw a note from one of the Squeak
>> luminaries (Alan?) that Self could have been Smalltalk-80's natural
>> successor.
>
>I'd like to hear Alan's and Dan's thoughts on Self.
>
>And btw, the Self project did not invent prototypes. For instance, ThingLab
>has them, and Henry Lieberman had a paper on prototypes ("delegation") in an
>early OOPSLA.
>
>Henrik
>
>< = > .





More information about the Squeak-dev mailing list