Dean,

your thoughts are interesting and provocating. They have triggered some
thoughts in my brain...

Swan, Dean wrote:

> 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.

Why is the <stdio.h> module in the C world so successful?
Since it has a well defined *interface*.

It is *not* sufficient to divide a big system into modules, it is necessary
to get a clear definition of their interfaces to the world!
Then a change in the interface suggests more or less compatibility problems,
but not improvements and bug fixes inside a module.

Thinking loud: what about working at tools for
viewing/defining/changing/detecting interfaces first, and then putting this
concept as a subconcept into the modules concept?

> 
> The whole concept of "software components" is IMO a fantasy propagated by
> media hype that ignores all the realities of real world engineering.

I wouldn't be so hard: it depends.
One example: Squeak itself uses interfaces to external code modules to be
portable between many platforms...

> 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 th
> e last 12 years or so).

Statement:
There is one important difference between hard- and software: hardware
interfaces evolve much faster.

(Some doubt remains: Is this true?)

> 
> 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).

Squeak already consists of multiple 'modules', mostly without well defined
interfaces. And it becomes worse, if there is no fight against.

> 
> 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.

To how many platforms has the 'flexible, reusable platform approach' been
applied (to get their theoretical benefits)?

In any case: your example is glaring and the latter approach has won there.

But there are other possible reasons for failure of the 'flexible' approach:
e.g. just to manage 'hundreds of developers' could be a nightmare.

> 
> 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)".

I'm against to try to get an "Eierlegende Wollmilchsau" (means 'something to
do all and very different tasks', to quote a nice German expression), but
I'm for working towards better definitions of interfaces and a more
modularized system.

> 
> 							-Dean Swan
> 
> 
> 

Greetings,

Stephan

PS: Your mail without line breaks at 76 chars or so wasn't very easy for me
to reply to with good readability... (admitted: my mail client (Mozilla)
could be better, I've solved the problem by forwarding the mail to myself
and copy/pasteQuoted the line breaked result (since replying to or using for
copy/pasteQuoted the original one resulted in quoted *not* line breaked
lines, which is very ugly)).



> 
> 
> -----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.
> 
> 
> 


-- 
Stephan Rudlof (sr at evolgo.de)
   "Genius doesn't work on an assembly line basis.
    You can't simply say, 'Today I will be brilliant.'"
    -- Kirk, "The Ultimate Computer", stardate 4731.3