Re-doing Morphic ( Was: Re: Traits prototype image )

Nathanael Schärli n.schaerli at
Mon Feb 10 15:51:05 UTC 2003

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

I agree with Andreas. In fact, I'm just about to do some more work on
refactoring the collection and stream hierarchies, and also here, many
shortcomings of the language are more than obvious.

Traits help to avoid some of them, but as I said earlier, they are just
a _small_ step into the (hopefully) right direction. That's why we are
currently working on a really exciting extension that should solve most
of the conceptual limitations we have identified while working with
these hierarchies. More to come...


> -----Original Message-----
> From: squeak-dev-bounces at 
> [mailto:squeak-dev-bounces at] On 
> Behalf Of Andreas Raab
> Sent: Montag, 10. Februar 2003 13:16
> To: 'The general-purpose Squeak developers list'
> Subject: RE: Re-doing Morphic ( Was: Re: Traits prototype image )
> > > 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 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

More information about the Squeak-dev mailing list