> > I'm wondering why andreas does not tell us his point of 
> > view on that.
> 
> yes, please.  :)

Simple. I think that all'y'all (thanks Jeff!) are barking up the wrong tree.
Look at eToys. Kids in fifth grade are able to master them even though
players have 500 methods IN ADDITION TO those in Morph and Object and the
kids are essentially dealing with all of them. Given this, isn't it time for
y'all to admit that you're more like these kids in fifth grade then one
might think?! ;-)

Or, put differently: The problem is not "cruft in Morphic", it isn't
"uglyness". That's an overly simplified point of view on the problem since
it didn't start out that way. It ended up there because of the way it was
exposed to all'y'all kiddies (including myself) not being able to protect
its own critical notions in any way.

To me, this is the logical result of many of the shortcomings of Smalltalk.
For example, subclassing for using the framework. When we subclass a
framework class like Morph in Smalltalk we do not *use* that class but
rather we *modifiy* it. We are able to access unprotected instance state
(look at the ridiculous comment in Morph>>bounds) we are able to override
system critical methods in incompatible ways. Even the tutorials (like the
one up at Squeak.org) teach you that it's okay to break the framework in
order to use it (in this concrete example, it lacks calls to any of the
"super" methods even though this is required by the framework).

Given this, any attempt to "clean up" Morphic is doomed to fail if it does
not address the "usability issues" for the programmer. The best you can hope
for is a temporary effect but any newbie can (and therefore will!) write
code that breaks the framework. Some of this code will either be cool or
needed enough so that someone else is going to use it and you'll end up
exactly where we are right now. 

Documentation, tests, etc. will (while being useful) not solve this problem.
After all, we *want* people to play with this stuff, don't we? And if we
want people to play with it then it should be easy to use in "the right
way".

eToys do exactly this. They provide an environment which is extremely
convenient for the kids to use and boy, many a time I have wished that
Squeak would be more like eToys. Bridging this gap, making the "system
level" part of Squeak more like eToys is the thing that needs to be done. In
particular in the UI area since that's what most people will look at and
play with first, so it's the place where strong fences are most needed
(present in eToys). Pretty much everything else will come naturally. Of
course, such an environment would no longer be "Smalltalk" - but in order to
protect the critical system notions we simply HAVE to get rid of it or at
least some of its intrinsically dangerous notions when it comes to an open,
easily usable, and still robust environment.

Bottom line of this: Morphic is cool. Neither the designers nor the users
are to blame for where it ended up in Squeak. Squeak (Smalltalk) itself is -
by not providing any means to build the right "fences" into the framework.
So my essential feeling here is: If you want to fix Morphic, then fix
Smalltalk. Morphic is simply a place where it shows many of its intrinsic
shortcomings for all'y'all kiddies.

Cheers,
  - Andreas