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
>