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