Whither Squeak?

>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.
>
> 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"
>><[hidden email]>
>>To: "The general-purpose Squeak developers list"
>><[hidden email]>
>>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 <[hidden email]> 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
>>>
>>
>
>
>
>
>
>
> --
> 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
>
>

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