Sorry about editing out most of what you wrote, but it is the only way I
can get a reply out this year...

Paul D. Fernhout wrote:
> >>>[Us paper]
> [new ideas from the 1980s]

Exactly - people are so impressed that the stuff from the 1970s is
finally reaching most programmers that they forget that there was some
neat stuff done after that.
 
> [problems: common object ID across all layers]

If you want collaboration you need to share object IDs. This will get
you some of the good stuff that people now get by using databases.

> [debugging - the patapata solution]

Self had already done this:

> http://web.media.mit.edu/~lieber/Lieberary/Softviz/CACM-Debugging/Kansas/Kansas.html

So the suggestion to do it differently in Us was an attempt to see if
viewpoints would make it cleaner. The paper shows a shiny new hammer and
then looks around for nails it could be used with :-)

> >>[patapata and documenting intent]
> > [loose objects vs catalogs]
> 
> Good points. I'll need to think about them. One of the PataPata decisions 
> was to reference parents by *name* rather than *pointer*. In self, key 
> objects can have names, but they are still referenced by pointer. The 
> PataPata choice gave me a little more flexibility in some ways I think -- 
> by adding yet another layer of "late binding" to the system. (And 
> accompanying overhead, of course).

A reasonable system has several different ways to bind objects. As Brad
Cox liked to say, you need soldered parts, parts that are screwed
together, parts that snap together and so on. Pointers are like solder,
while names are a more loose coupling.

> [Squeak on Java alternatives]

You might want to talk with Klaus Witzel to see if you two aren't doing
the same thing.
 
> [community around a new Squeak?]

That is something I thought a lot about back in 1998. And I watch
closely the community's reaction to stuff like Coke or Slate. What I
concluded was that there are several rather different groups. The
largest group is the eToys users and they are extremely under
represented here. There is a tiny "use Squeak to build something better"
group but most people here are in the "we need a great open source
Smalltalk-80" (there is a lot of overlap, of course). So I don't see how
you can change things and not lose a significant part of this
(squeak-dev) community.

> Increasing complexity is easy; moving it around in tradeoffs is harder; 
> reducing it is hardest and generally require a leap of the imagination.
> Sorry to say it, but Squeak still seems pretty complex to me, and moreso 
> than ten years ago. :-)

Which is why it is a good thing that the version of Neo Smalltalk I am
working on right now is 16 bits. When you only have 32K objects total
simplicity is not optional.

In another message in this thread you mentioned the story that Java was
started only because Sun couldn't get a reasonable license from
Parcplace. I have heard this a few times before but don't believe it -
Sun had a good Smalltalk for free in the form of Self and it would have
been easier for them to reshape that to their needs if they had
seriously considered going in that direction.

-- Jecel