Sorry but I disagree.
The fact that 3.3a modules were not usable is just due to the lack of=
=20
push, the fact that the image is a ****messy**** state
with lot of references everywhere, and a too complex module model.

We need modularity. Lot of people are fed up to not be able to=20
logically identify why when there is a new changes in the system
their code breaks. Or to have to remove from the image stuff that doe=
s=20
not interest them at all. Having modules, I prefer packages for code=
=20
grouping issues is key the future of Squeak. Look at how daniel manag=
es=20
RB out of the image. If I want RB I load it.
(even if RB should be the base browser but this is another discussion=
).

You miss a key point: an image is not an entity for deployement and=
=20
code management and there is nothing in packages that
goes against image. These two concepts are NOT ENEMY.
Imagine a small image like in GNU Smalltalk where you can configure=
=20
what you want to have in and a server where you
can select what you want in. You click and hop you get a new image. Y=
ou=20
code, publish your code and hop you able
to REBUILD your image. I'm also able to load your code and all the=
=20
dependent packages. Without having nightmare to know
which changeset should be loaded and why my system is getting unstabl=
e=20
because I forgot to load this tiny cs.

If I do not need Music, eToy, Chess, why do I need them in my image?

Image are cool for developping, I loved them, saving your objects for=
=20
coffee breaks
with the mouse on the right line of the debugger but not for=20
deployement and source code management.

Stef


On mercredi, octobre 30, 2002, at 10:46  pm, Swan, Dean wrote:

> What 3.3a is trying to do with modules is essentially opening the s=
ame=20
> can of worms that has made MS Windows such a maintenance nightmare.=
 =20
> Modules are (more or less) equivalent to .DLLs and may end up with =
all=20
> the associated issues.  I don't know of any "good" solutions to the=
se=20
> problems, but as attractive as the "idea" of modules is, I am=20
> personally content to stick with monolithic images for the forseeab=
le=20
> future.
>
> The whole concept of "software components" is IMO a fantasy propaga=
ted=20
> by media hype that ignores all the realities of real world=20
> engineering.  In "real" hardware product designs, one often finds t=
hat=20
> re-usability is more of a structuring concept than a hard reality. =
 I=20
> don't believe I've ever worked on a hardware design that didn't=
=20
> involve some kind of custom connector that is a "slight" variation =
of=20
> a "standard" connector, for example.  (Just for context, I'm referr=
ing=20
> to everything I've worked on in the last 12 years or so).
>
> I think the concept of a monolithic image constrains the reusabilit=
y=20
> myth to realistic proportions, and makes implementation possible.  =
Too=20
> much flexibility comes at a cost, which usually rears its ugly head=
 in=20
> the form of increased complexity, higher resource requirements, and=
=20
> reduced preformance (relative to a less flexible implementation).
>
> As an example of what I'm talking about, I've worked on a couple of=
=20
> different projects in the last few years where the end product has=
=20
> similar capabilities but one was implemented using a "flexible,=
=20
> reusable platform approach" and the other was implemented using a m=
ore=20
> task specific approach.
>
> The flexible system has a source tree for the "platform" of about 5=
=20
> gigabytes, generates a target image of about 170 megabytes, and nee=
ds=20
> two 300 MHz PowerPC 603e's and 512M of RAM to run.  This system has=
=20
> hundreds of developers working on it.
>
> The "task specific" system has a source tree of about 300 megabytes=
,=20
> generates a target image of about 1 megabyte, and runs on one 66 MH=
z=20
> PowerPC with 16M of RAM.  This system had 4 developers working on i=
t. =20
> 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=
=20
> consider our goals carefully in relation to the questions that Andr=
ew=20
> has raised.  My preference is towards "lean and mean" rather than=
=20
> "incredibly flexible, general purpose (and suboptimal)".
>
> =09=09=09=09=09=09=09-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=
=20
> will be
> moving towards a model in which individual pieces of code are=20
> liberated as
> much as possible from unneccessary constraints on their usage.  Tha=
t 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=
=20
> being
> made by a lot of people in terms of understanding those issues, or =
at=20
> least
> recognizing them.  The days of the monolithic image ( and the inher=
ent
> weaknesses and roadblocks to progress that it represents ) are,=
=20
> 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=
=20
>> count
>> is now up to 16 packages, by 8 different authors. These range from=
=20
>> small
>> framework additions like SharedStreams to large projects that woul=
d be
>> unlikely to ever become available through the Squeak base image, l=
ike
>> Seaside.
>>
>> This opens up directly possibilities to maintain other projects=
=20
>> outside
>> the image too, like Celeste, Scamper and others.
>>
>> All this should reduce the maintainance effort required of SqC, an=
d=20
>> let
>> the community do experiments in various directions without actuall=
y
>> requiring a fork.
>>
>> A case in point - if Henrik's code was first debuted as a SM packa=
ge,=20
>> it
>> would have gotten earlier feedback, it could have been more modula=
r,=20
>> it
>> would have been easier for people to try out and it would have bee=
n
>> 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=
=20
>> advantage
>> of this new option we have as a community, and how we change our=
=20
>> process
>> to fit it in.
>
>
Dr. St=E9phane DUCASSE (ducasse at iam.unibe.ch)=20
http://www.iam.unibe.ch/~ducasse/
  "if you knew today was your last day on earth, what would you do
  different? ... especially if, by doing something different, today
  might not be your last day on earth" Calvin&Hobbes