Making Squeak more like Etoys
Last updated at 8:40 pm UTC on 13 January 2012
Andreas Raab posted the following to the squeak-dev mailing list on 2/10/2003:
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 modify 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.
Alan Kay posted the following comment on Andreas's post, to thesqueak-dev list on 2/13/2003:
Etoys were made specifically for children and specifically for a few hundred projects that would be neat for them to do. Squeak is made for experts and for pretty much every kind of project. The user environment we didn't get done was the one in the middle: etoylike but with very large scope, especially for media. This is the one you need, but it isn't there (yet).
However, we also used etoys to try out a few ideas about object organization and object building. Andreas, being an European, has a better command of English than most of us. Andreas did not say that you should try to do every project in etoys. He did say that there are a lot of very useful ways of thinking about doing projects "in the manner of etoys". Someday there will be "the middle environment" mentioned above. Until then, you really need to do most projects using the expert environment.
See also: Possible areas for eToy enhancement
So when do we get Adult Etoys??
I'm a newbie to squeak trying to get squeak to teach me squeak.
(I've had experience with other languages like logo and forth, but come to squeak with a beginners mind.)
Playing with morphic and etoys is fun until you run into their limitations. Then its back to writing text in workspaces etc.
Etoys does not seem a good space to create anything permanent. But there's this niggling feeling of frustration that their should be.
It gets so close. And its so easy to use (when your within its area of competence.
Morphic is similar. There are things that work just naturally in morphic. And projects can be pokegrappled into morphic with minimum programming. And when that is needed a small amount of code to create a missing widget will generally do the job.
The main time I spend is looking at all the code to learn about what to program to get things done. And learning how to look at the code.
Its hard to bootstrap yourself without hand holding.
Anyway Adult Etoys would be nice.
Adult Etoys update
Now that scratch has come out http://scratch.mit.edu/
In 2009 published the project to make Smalltalk programmable via Scratch blocks.
See the squeak-dev thread starting here:
The possibilities are exciting. wiz
Since 2009 Jens Moenig has spent much more time on extending Scratch itself with a project originally called BYOB and renamed in 2012 to . Brian Harvey of UCB works with him on it.
BYOB version 3.1 includes first class sprites, prototypical inheritance and many other adult features. http://www.chirp.scratchr.org/blog/?p=37#comments