[squeak-dev] The future of Squeak & Pharo (was Re: [Pharo-project] [ANN] Pharo MIT license clean)

Göran Krampe goran at krampe.se
Mon Jun 29 00:27:54 UTC 2009


Hi guys!

Bernhard Pieber wrote:
>> If those words didn't convinced you that maintaining & developing a
>> bloated images, instead of separate, well defined modules is road to
>> void, then nothing else can.
> I am afraid you did not convince me. I do think that maintaining a full 
> image is better. 

Please note the huge amount of packages available on SM, SS etc. I am 
not sure who were around at the time, but one REAL problem back then was 
that if you did NOT make it into the image - you were left on the cold 
outside and had to manually maintain your addon package.

But wait... so, ok, if you DID get (your package) into the image then 
SqC at the time spent some of that time *for you* since they could 
relatively easily see if they broke something (class refs, senders of, 
implementors of etc). And hey, they could just try to run it too :)

But they ran a rather small kitchen.

Now, let's imagine putting all of SS/SM into a super mother of a 
kitchen. Lots and lots and lots of packages. Some conflicting with each 
other (oops), some really hard to understand, some left for dead by 
their original authors etc etc.

It just won't fly. Better IMHO to make it easy to live outside the image by:

- Use unit tests. If you are green, you are green.
- Get good build and delivery tools. We have a bunch and more to come.
- Get more advanced tools for managing code between images. DeltaStreams 
is one try on that.
- Perhaps even add some database to the mix for global 
senders/implementors/class refs!

Anyway, all this has been said already. I am sorry, I really don't 
believe in the kitchen sink UNLESS you have a specifically targeted image.

regards, Göran




More information about the Squeak-dev mailing list