Dear Andreas,

I was attracted to Squeak because of Morphic, and I am pleased with it,
all in all. But that only means that I have found it less frustrating
than other ways of doing graphic objects. :-) As a Newbie, maybe I can
offer a somewhat different perspective.

> To me, this is the logical result of many of the shortcomings of Smalltalk.
> For example, subclassing for using the framework. 

I ended up subclassing, but only because the framework did not provide
the functionality I needed, or else the documentation did not clearly
tell me how I could do what I wanted to do.

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

Isn't that a major motivation for doing that?

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

I'm not sure that's a problem. You don't say, well, let's not clean the
house because it'll just get dirty again. Also, Squeak evolves.

I have not been here long, but I am impressed by the community spirit
here. :-) If the newbie writes new code that is well documented and
tested, and then accepted by the community, what's the problem? In the
evolutionary process some code will survive, some code will die.

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

As I suggested above, if Squeak has good documentation and testing, then
it is natural to expect new code to conform to those standards. If not,
well....

Best regards,

Bill Spight