A roadmap for 3.9

Michael Rueger michael at squeakland.org
Sun Dec 12 19:08:03 UTC 2004


Hi all,

coming in late, was off line for a few days and it took me the better 
part of today to catch up.
So, just a few statements from my point of view:

- 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!

- 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

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 ;-)
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.

OK, all take a deep breath now ;-)

Michael





More information about the Squeak-dev mailing list