danielv at tx.technion.ac.il
Sat May 20 10:42:55 UTC 2006
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 (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.
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
- 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.
-- Support for cherry picking is very basic in current MC (which MC2
-- 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.
 listed in
> 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
More information about the Squeak-dev