Dan Ingalls wrote:
>> [Mention of difficulties slimming image]
> People will tell you this is the problem with the unified image approach, 
> but I disagree.  The problem is simply that we haven't drawn appropriate 
> lines between the various parts of the system, so when you cut one out,
> you're left with dangling dependences.  

The deeper issue is management of complexity. In a Smalltalk sense, it
is that a "module" providing a certain functionality typically consists
of multiple classes that need to cooperate to get things done (thus a
Smalltalk class really isn't a "module" in any meaningful sense). 

Of course this is made worse by the fact that subclassing or copying a
whole bunch of classes in Smalltalk is a lot of work, so it is easier to
patch new functionality directly into the old classes as a practical
matter, as was done with the C code generation stuff added to the parser
classes.

One can manage complexity by hand in Smalltalk (being very careful about
how modules are created). You can do it in assembler or C by hand as
well. Modula or modern Lisps or even Delphi Pascal at least address this
issue somewhat by having modules or units providing some sort of defined
functionality and having defines interfaces. One can also do somethign
like this by using something like ENVY (with its application and the
extension concepts). 

But in practice it is very hard to do it in Smalltalk by hand when a lot
of developers are working together -- see my "SystemDictionary>>version"
post where I cite:
SystemDictionary>>version
        "Answer the version of this release."
        ^ EToySystem version , ' of ' , EToySystem versionDate

The issues were put very eloquently by Les Tyrrell and others (esp. in
his 
  Re: Belling the cat of complexity (was: Ship it with Squeak)
  Resent-Date: 30 Jun 2000 23:20:05 -0000) 
As long as a monolithic big image is what people download and what is
supported as part of the mainline, testing for a shippable app is a
nightmare, because a pruned image is a new (untested) image and has to
be retested. Building up from a solid core is the only realistic path to
reliability. 

I feel strongly on this complexity management issue -- enough to start
wondering whether it would be better for my own efforts to pick another
cross-platform solution that has a stable core (MzScheme?) and add on
Squeak like functionality. I guess "SystemDictionary>>version" is making
me despair at realizing how deep the Squeak complexity problem has
grown. Squeak has lots of great ideas and great work, but it's the
"building your house on sand" concept. If you want your house to stand,
either move it onto rocks or put in deep piles underneath. Either is a
lot of work. It's easier to just add on to a house someone else already
built on a rock.

I understand the value to SqueakC to have everyone banging on the big
image SqueakC uses its own work. But I think in the end you and many
other Squeakers would be better served by having a slim image as the
mainline system, with everything possible (including Morphic) being
loaded as needed. A convenience kitchen sink image is OK; just always
build it from the slim core for each release.

(And ideally that core image should be built via the ANSI declarative
approach but that is another rant.)

> I think that real value would come from declaring this as a project, 
> with a goal of having maybe 20 discardX methods that really worked 
> and that wouldn't get out of date in the next month.  

I just can't see this really being a good solution. It will get out of
date immediately in a new release and produce lots of difficult to
maintain code. This is because every remove method will have to be
written by an expert (or someone becoming one) on that subsystem (and
every other subsystem that uses it).

-Paul Fernhout
Kurtz-Fernhout Software 
=========================================================
Developers of custom software and educational simulations
Creators of the Garden with Insight(TM) garden simulator
http://www.kurtz-fernhout.com