What 3.3a is trying to do with modules is essentially opening the same can of worms that has made MS Windows such a maintenance nightmare.  Modules are (more or less) equivalent to .DLLs and may end up with all the associated issues.  I don't know of any "good" solutions to these problems, but as attractive as the "idea" of modules is, I am personally content to stick with monolithic images for the forseeable future.

The whole concept of "software components" is IMO a fantasy propagated by media hype that ignores all the realities of real world engineering.  In "real" hardware product designs, one often finds that re-usability is more of a structuring concept than a hard reality.  I don't believe I've ever worked on a hardware design that didn't involve some kind of custom connector that is a "slight" variation of a "standard" connector, for example.  (Just for context, I'm referring to everything I've worked on in the last 12 years or so).

I think the concept of a monolithic image constrains the reusability myth to realistic proportions, and makes implementation possible.  Too much flexibility comes at a cost, which usually rears its ugly head in the form of increased complexity, higher resource requirements, and reduced preformance (relative to a less flexible implementation).

As an example of what I'm talking about, I've worked on a couple of different projects in the last few years where the end product has similar capabilities but one was implemented using a "flexible, reusable platform approach" and the other was implemented using a more task specific approach.

The flexible system has a source tree for the "platform" of about 5 gigabytes, generates a target image of about 170 megabytes, and needs two 300 MHz PowerPC 603e's and 512M of RAM to run.  This system has hundreds of developers working on it.

The "task specific" system has a source tree of about 300 megabytes, generates a target image of about 1 megabyte, and runs on one 66 MHz PowerPC with 16M of RAM.  This system had 4 developers working on it.  The end functionalities of these two systems is *very* similar.

I'm not sure what my point is in all of this, but I think we should consider our goals carefully in relation to the questions that Andrew has raised.  My preference is towards "lean and mean" rather than "incredibly flexible, general purpose (and suboptimal)".

							-Dean Swan



-----Original Message-----
From: Les Tyrrell [mailto:tyrrell at canis.uiuc.edu]
Sent: Thursday, October 24, 2002 8:15 PM
To: squeak-dev at lists.squeakfoundation.org
Subject: Re: An uncomfortable question


These are important points- as we move forward, I am hoping that we will be
moving towards a model in which individual pieces of code are liberated as
much as possible from unneccessary constraints on their usage.  That is
going to require a rather significant change in a lot of Squeak's
infrastructure, but I am rather impressed with how much progess is being
made by a lot of people in terms of understanding those issues, or at least
recognizing them.  The days of the monolithic image ( and the inherent
weaknesses and roadblocks to progress that it represents ) are, hopefully,
numbered.

- les

----- Original Message -----
From: <danielv at netvision.net.il>
To: <squeak-dev at lists.squeakfoundation.org>
Sent: Thursday, October 24, 2002 3:41 PM
Subject: Re: An uncomfortable question


> Well, I think something interesting is happening in SqueakMap. The count
> is now up to 16 packages, by 8 different authors. These range from small
> framework additions like SharedStreams to large projects that would be
> unlikely to ever become available through the Squeak base image, like
> Seaside.
>
> This opens up directly possibilities to maintain other projects outside
> the image too, like Celeste, Scamper and others.
>
> All this should reduce the maintainance effort required of SqC, and let
> the community do experiments in various directions without actually
> requiring a fork.
>
> A case in point - if Henrik's code was first debuted as a SM package, it
> would have gotten earlier feedback, it could have been more modular, it
> would have been easier for people to try out and it would have been
> optional, orthogonal to the harvesting work done on 3.3a.
>
> This would have saved us at least one uncomfortable question.
>
> So I think one important thing to consider is how we take full advantage
> of this new option we have as a community, and how we change our process
> to fit it in.