A counter-example is Emacs.  Emacs has *tons* of code available for it,
and yet it all tends to work nicely together with any subset of the
modules loaded.  And Emacs doesn't even have namespaces!  It's all done
by hand.

I don't know why it works out, but it certainly does, somehow or another.
It's at least *possible*.

-Lex




Paul Fernhout <pdfernhout at kurtz-fernhout.com> wrote:
> 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