[Squeakland] Etoys: The Good, the Bad, and the Ugly (was Re: Whither Squeak?)

[Alan Kay]

Hi Markus --

Good list!

But a better way to look at Etoys is that it was supposed to be a subset of 
a more comprehensive system for all programmers (as comprehensive as 
Smalltalk but a more advanced set of ideas). So, if we were to make a 
better system and do a special children's interface for part of it, that 
would be a better way to deal with "bad and ugly".

Cheers,

Alan

  At 05:16 PM 5/23/2006, Markus Gaelli wrote:

>On May 23, 2006, at 9:49 PM, Alan Kay wrote:
>
>>A good exercise (and very useful) would be just to build a new (and
>>much better) Etoys in your new Morphic. There is nothing sacred in
>>the current version of Etoys.
>
>Hi,
>
>having some fun Etoys experience myself (http://www.emergent.de/ etoys.html)
>I compiled a list (should I say Set ;-))
>  "Etoys: The good, the bad and the ugly"  - (to be criticized,
>prioritized and extended of course)
>
>Good:
>- Forces one to unify GUI + Model, which often does makes sense
>(think naked objects)
>- Allows visual programming using tiles
>- Comes with a rich set of toys
>- Is prototype based (good for exploring)
>- types variables by examples
>- holders/playfields are very powerful (iteration, inclusion...)
>- Generates Smalltalk Code in the background
>- Nice concept of halos
>- Connectors...
>- Quite transparent parallelism
>- Is translated to many languages
>- Net Morphs are coool
>- Nebraska (if it works) is nice too
>- Recorded sounds can be used as tiles
>- scripts allow parameters (though I seldom needed this)
>- Hardware Support (forgot the name, but this japanese people
>converting external measurements into sounds, which is in turn
>translated into sound...)
>- Is Used!
>- Comes with some simple sensors (overlaps, color sees...)
>- Constraints of Etoys allow some creativity
>- Kedama
>
>Bad:
>- Not easy for end user to extend with smalltalk code (e.g. some
>frustrated lisp programmer could not add midi to Etoys)
>- Limited set of events (will be better with Etoys2 ak Tweak)
>- Traces of turtles are pixels not objects (want to create some
>vector graphic with turtles...)
>- No notion of matrices ak 2D Fields
>- projects only storable as binaries (would be cool if commands would
>be logged en passant while creating a project...)
>- Squeak Plugin not widespread
>- some properties are not available (why can't I treat every player
>as a holder?)
>- Cannot extend with scripts which deliver booleans, always have to
>make a variable for that (maybe ok though)
>- Tiles create code, but code does not create tiles
>- Not yet available for 3d (croquet programming with Etoys would rock)
>- No bracketing of arithmetic expressions
>- preceding rules of Smalltalk and not of high school mathematics
>- Some tiles don't accept input (eg random...)
>- No debugger for etoys (difficult, but maybe fruitful)
>- "Genetive Programming" (first script any object, then say, that
>e.g. this script actually should affect the player at cursor...)
>- Connectors too much hidden
>- Strange organization of method categories (eg. misc...)
>- siblings can't be broken, copies can't be "siblinged"
>- No tasks, riddles with possible solutions online
>- no physics engine
>- Tweak, ak Etoys2 seems still to be slow
>- Projects in Projects are not publishable
>- Cells in Matrices should know about their neighbors
>- No use of midi
>- maybe Kedama could be integrated better
>
>Ugly:
>
>- mangling of EToys code everywhere in Squeak (though I strongly
>favor further inclusion of "the best etoys currently available" in
>the kitchen sink image
>
>Ok, got that of the list now...
>
>Cheers,
>
>Markus
>
>
>>
>>Cheers,
>>
>>Alan
>>
>>----------
>>
>>At 04:36 AM 5/23/2006, Juan Vuletich wrote:
>>>Hi Daniel,
>>>
>>>I used MudPie for splitting Morphic. As I said in another message,
>>>I failed at making Etoys and MorphicExtras easy to unload and load
>>>back. This is because for fixing the bad dependencies without
>>>needing two versions of many core methods (i.e. methods not in the
>>>package we are removing). Doing this carefully is way too much for
>>>me (and for anybody, I guess). Squeak is too big!
>>>
>>>My experience with MudPie was excellent. It is great for spotting
>>>those dependencies. It works great, and when I needed some help,
>>>or new features, Daniel helped me a lot, and implemented many of
>>>my suggestions. Thanks, Daniel! And I can say: MudPie does work in
>>>3.9.
>>>
>>>The problem was not lack of tools like MudPie. I could think of a
>>>tool that could automate the generation of some of the code needed
>>>for removing dependencies. But I don't think that would be a good
>>>solution. The only way to clean code is by understanding it. So,
>>>to me the problem is: too much work, too little time.
>>>
>>>Cheers,
>>>Juan Vuletich
>>>
>>>----- Original Message ----- From: "Daniel Vainsencher"
>>><danielv at tx.technion.ac.il>
>>>To: "The general-purpose Squeak developers list" <squeak- 
>>>dev at lists.squeakfoundation.org>
>>>Sent: Saturday, May 20, 2006 7:42 AM
>>>Subject: Re: Whither Squeak?
>>>
>>>
>>>>Hi Ralph
>>>>
>>>>Improving design:
>>>>------------------------------
>>>>One of the problems is that Squeak did much of its growth without
>>>>any explicit package system. As a side effect, these systems
>>>>usually enforce a-cyclic dependencies. Cyclic dependencies
>>>>(considering just compilation-time-obvious dependencies, like a
>>>>method in one class refering to a parent) are rampant in Squeak
>>>>(see references to Morph), making it difficult to decompose.
>>>>
>>>>I wrote some code to aid finding, reducing and keeping down the
>>>>incidence of such dependencies, called MudPie[1] (available from
>>>>SqueakMap, I don't guarantee it works 3.9, but will if there's
>>>>interest). DanI wrote some other modularization aid code. Some
>>>>people have looked at these efforts, for example Juan, and tried
>>>>to use them - I'll let them speak about their usefulness and/or
>>>>problems. I would call neither tools, since they didn't include a
>>>>real UI and such, which is sufficient cause for them to never
>>>>have become widely used.
>>>>
>>>>Package system:
>>>>--------------------------
>>>>I believe that the management of the code of Squeak in tool
>>>>supported packages is a critical component of any solution - this
>>>>is the only way to keep the boundaries up to date. So the
>>>>existance of MC exists makes this task somewhat feasible, but
>>>>there have been various problems with its use to manage the whole
>>>>image.
>>>>
>>>>- Performance (loading updates to the image using MC is much
>>>>slower than loading changesets).
>>>>- System changes (like introducing Traits) require going through
>>>>various intermediate stages, but MC itself only model merging the
>>>>code in order to reach the final stage to be loaded.
>>>>- Workflow:
>>>>-- Support for cherry picking is very basic in current MC (which
>>>>MC2 should improve).
>>>>-- MC is quite workflow agnostic, but maintaining Squeak does
>>>>require some workflow (people write fixes, other people merge
>>>>them), and maintaining it as a set of packages requires even more
>>>>of it (coordination of entry of package changes into the official
>>>>release). Right now we use a combination of SqueakSource, Mantis,
>>>>and email, glued together by (what seems to me like) lots of
>>>>overhead.
>>>>
>>>>
>>>>Daniel Vainsencher
>>>>[1] listed in http://www.informatik.uni-trier.de/~ley/db/journals/ 
>>>>cl/cl30.html
>>>>>On 5/19/06, Cees De Groot <cdegroot at gmail.com> wrote:
>>>>>>  the tools have
>>>>>>performance problems when trying to manage the whole image.
>>>>>
>>>>>Can you be specific?  What tools?  Can you give stories of how
>>>>>tools failed you?
>>>>>
>>>>>>On a more philosophical stance, Squeak has grown organically. And
>>>>>>anything organic tends to get fuzzy, maybe even almost fractal,
>>>>>>borders between the various parts. Try separating a leaf from its
>>>>>>stem, on the cell level, for starters...
>>>>>
>>>>>Squeak is a bit more extreme than others, but not a lot.  As Fred
>>>>>Brooks said, all successful large systems started as successful
>>>>>small
>>>>>systems.  Organic growth is typical, not atypical.  Refactoring
>>>>>is a
>>>>>lot of hard work and Squeak doesn't have people being paid to do
>>>>>this
>>>>>kind of work.  But I find it hard to believe that Squeak is
>>>>>worse than
>>>>>Word, or Gnu EMACS, or any other large system that has been
>>>>>around for
>>>>>a long time.  The difference is that Microsoft pays people a lot of
>>>>>money to modularize Word.  It goes though periods of organic
>>>>>growth,
>>>>>and then periods of modularization as they try to reuse code across
>>>>>projects or within Word.  Most software does this.
>>>>>
>>>>>This is why I think modularizing Squeak is an interesting project,
>>>>>because we can learn lessons from it that will apply to all
>>>>>software.
>>>>>So, we need to write about what we are doing, the problems we
>>>>>discover, and the lessons we learn.
>>>>>
>>>>>Squeak hasn't needed to be modular enough for people to do the
>>>>>work to
>>>>>make it so.  Now it does.  (Well, it probably has for several
>>>>>years,
>>>>>so "now" means "the last few years".)
>>>>>
>>>>>-Ralph Johnson
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>--
>>>>No virus found in this incoming message.
>>>>Checked by AVG Free Edition.
>>>>Version: 7.1.392 / Virus Database: 268.6.1/344 - Release Date:
>>>>5/19/2006
>>
>>
>>