Sorry but I disagree.
The fact that 3.3a modules were not usable is just due to the lack of
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
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 does
not interest them at all. Having modules, I prefer packages for code
grouping issues is key the future of Squeak. Look at how daniel manages
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
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
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. You
code, publish your code and hop you able
to REBUILD your image. I'm also able to load your code and all the
dependent packages. Without having nightmare to know
which changeset should be loaded and why my system is getting unstable
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
coffee breaks
with the mouse on the right line of the debugger but not for
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 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@xxxxxxxxxxxxxx]
Sent: Thursday, October 24, 2002 8:15 PM
To: squeak-dev@xxxxxxxxxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxx>
To: <squeak-dev@xxxxxxxxxxxxxxxxxxxxxxxxxx>
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.
Dr. Stéphane DUCASSE (ducasse@xxxxxxxxxxxx)
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
