Self

jecel at lsi.usp.br jecel at lsi.usp.br
Mon Nov 8 20:21:14 UTC 1999


First of all, though my posts here might lead someone to believe that I
am a Self advocate infiltrated in the group, that is not quite the case.
I have encouraged several people to try Squeak over the past few years,
but have not made a similar effort for Self so far (unless you count my
trainees). I do use Self more than Squeak, and some people have preferred
to follow my example and ignore my advice.

I really enjoyed Alan's evaluation of Self, and want to make some comments
on it. About Henrik's own comments on it, I would just say that you get
Self by removing things from Smalltalk, not adding stuff to it.

Let me briefly state my biases: all my work is directed towards making
systems that are easier for first time programmers (specially students
and teachers). I like to work with "live" objects instead of dead code,
which is why I find the image segment idea so interesting - you can ship
something like "play with me" windows instead of fileIns.

> 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.

I guess I didn't understand this since I just agree with the "representing"
part. Self 4 hides its real metasystem in C++ level objects which can't
be accessed from Self (it is hard to be more protective than that), but
then it presents the user with a totally fake metasystem based on a set
of primitive calls and mirror objects. Hmmm, I think I am talking about
implementation level things while Alan is complaining about things like
parent slots, right?

>      For example, classes don't have to be put in opposition to prototypes.
> Both are great ideas and both are needed.

We agree, here.

> 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).

Exactly - I just don't want classes to get in the way. I also don't mind
declaring types as part of cleaning up a program, as long as I don't have
to do it before I start.

I don't think classes are needed everywhere, though. As long as they are
a good concept for the program, they should be reified as a real live
object. But what about classes in, for example, Little Smalltalk? They
can't have their own state (other than the list of instance variables and
the method dictionary) or class methods (they are all just instances
of Class). I welcome classes as long as they represent class-like ideas,
and not low level implementation details.

> 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),

And when trying to do concurrent things I really envy the extra abstraction
that Actor systems have (of behavior replacement as the only side-effect
operation).

> 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.

But getting instances from other, but identical instances is at the same
level as copying (think of cells reproducing - do we really need factories?).

>      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,

But that is what make Forth so good at what it does (small scale, closed
systems created by individuals). I agree it is a major pain and a good
reason to avoid it, but it is also what makes it what it is. That is
why I don't like hybrid languages - you can't steal just some good ideas
and expect to get the advantages of the original.

> both CLOS
> and Self have visible inheritance mechanisms, etc.

There is an advantage to visible inheritance that hasn't been explored
yet: dynamic inheritance. Unfortunately, no Self implementation has done
a good job with this yet, so people have stayed far away from using it
so far.

>      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.

You can't have power without danger. It is indeed a challenge to find
the right balance.

> 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.

If there is something that is obviously not right in Self, it is "copy down
slots". John used them extensively in his Self Morphic system, so if his
taste is anything like mine it must have been painful. In Smalltalk, a
subclass gets a copy of the instance variables declared in all of its
superclasses and then adds its own. In Self, an object uses any data
slots in its parents directly - it doesn't get its own copies of them.
But often, you want it to have its own copies (the famous 2D to 3D point
example everyone always gives is wrong - you don't want the 3D point to
use the X and Y from the 2D point but instead to have its own X and Y
like it would in Smalltalk). Since the language can't handle this common
situation, the programming environment steps in with its kludgey copy down
slots.

Now programming environments are a matter of taste - I prefer to spread
out a dozen or more outliners in front of me to the traditional multipane
browsers, which other people are completely lost without an "anchor" like
what the Smalltalk System Browser offers.

Regards,
-- Jecel





More information about the Squeak-dev mailing list