hi mike

> - back ward compatibility is the enemy of progress
> I'm saying this even though I have to deal with it when maintaining 
> squeakland, the community that is as far from programming as it can 
> get in this context. In order to stay "stable" for this community we 
> didn't update to a new release for two years (lots of updates though).
> My network rewrite broke lots of packages too and so will future 
> refactorings. As long as they make sense (reference to Beeper here 
> ;-)) we should live with it.
> Does anybody remember Dave's and Alan's keynote urging us Smalltalkers 
> to get off our buts and start innovating again? Three years ago!

but with the system as it is now this is quite difficult.  but this is 
already a bit easier than before (cf systemNotifier, new compiler...)

> - my often repeated design philosophy
> Perfection is achieved not when there is nothing more to be added
> but when there is nothing left to take away
> Antoine de Saint-Exupery

Me too :)

> People probably have noticed my resistance against including things 
> like RB into the base image. It adds an almost unbelievable number of 
> classes to the system, duplicating most of the system core classes. We 
> definitely do not want that IMHO. We need a clean, lean, mean core 
> that things like RB can run on top of. And, btw, RB code is a little 
> gray along the temples as well by now ;-)

Not that much if you compare with the current average quality of squeak 
code.

But mike we cannot afford to rewrite it now and we deserve to have a 
better (rename class functionality).
So what we can do is use the best tools we have and later when we have 
the time rewrite them. For now we are quite
ridiculous compared with standard java ide for that level.


> Things like Squat point in the right direction. We need one button 
> class, not 20, maybe one to three Stream classes, not I don't know how 
> many. Etc pp...
>
> Now is the time to break the system and rebuild it. Our legacy is 
> basically 30 years old, time to move on. But, the danger is to jump 
> the wrong gun. I still very vividly remember the modules disaster, 
> adding a not well understood system change that broke everything 
> without showing a way out.
> Projects within my responsibility like squeakland and others use the 
> stable version of squeak anyways. People who are on the alpha stream 
> complaining that their production code breaks need to look up again 
> what "alpha" means in programming.
>
> Last, but not least: I don't think monticello based on the current 
> philosophy of package info is ready for prime time yet. As long as I 
> can't package a single class or method easily I'm not willing to 
> accept this as the default packaging system. And I sincerely hope that 
> none of you considers writing a package info class to package a single 
> method as a feasible approach.

so in that case we should not have package in the base image. I think 
that everybody talked a lot recently but few
people really tried to do the work of marcus.

>
> OK, all take a deep breath now ;-)
>
> Michael

Stef