2008/6/28 Damien Pollet damien.pollet@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.