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