2008/6/28 Damien Pollet <damien.pollet at gmail.com>:
> Ex. Pier needs Seaside. If there is a new release of Pier, the Pier
> developers update the Pier package and nothing more. If Seaside gets
> upgraded, the Pier package should *not* have to change/be
> regenerated/whatever until the Pier code is updated.
>

This scenario is quite unlikely in Squeak , but surely it is possible
in general in smalltalk (Spoon addresses that, getting rid of globals
addresses that :)
Once you change a class from which depends the rest, it may require to
update dependent code as well, otherwise it will be broken.
Unless people design things with modularity in mind, but i don't see
many of such packages, which can be used w/o fear that updating them
will not break something else. This is a real main problem of squeak:
bad design which prohibits modularity, not MC or SqueakMap nor CPAN or
other tools.

First, we need a paradigm shift IMO. From solid, single image where
everything is closely tied, to modular system where different parts
does not interfere with others, or if interfere, they play by strict
rules.

We had a lengthly battle yesterday on #squeak IRC channel. It seems
everyone wants better Squeak as we know it. But having different views
on it.

Surely, we can improve our tools, and they indeed need improvement.
This is great, but in the end, if we stay with old paradigm, no wonder
will happen.
Ask yourself, do you want a system, where you can load any code
without any risk, and even if it broken, it will not break the rest of
your system?
Do we want it to be a smalltalk, not a NewSpeak? Or we just wait till
NewSpeak (or another heir of smalltalk will successed and migrate to
it?).

Lets just understand, that to get to new level, we need a quality
shift (change system to become truly modular) , not quantity (make
more or better tools). Only after we do that, squeak can explode with
quantity, because there will be much less things to deal with.
As with Alan's analogy: we have objects which behave as body cells and
they are quite modular. But why, at same time, we deny that group of
cells (package/set of classes) can't be modular?

Make system modular. This is what most of currently elected board
members (including me) had in their platform. This is what, i think
people wanted from us.


-- 
Best regards,
Igor Stasenko AKA sig.