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

Alan Kay Alan.Kay at
Mon Feb 10 13:42:19 UTC 2003

Right on! and very well said!




At 1:16 PM +0100 2/10/03, Andreas Raab wrote:
>  > > 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
>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.
>   - Andreas


More information about the Squeak-dev mailing list