About squeak image compatibility (3.6/7/8)
Cees De Groot
cdegroot at gmail.com
Sun Jan 8 20:24:37 UTC 2006
On 1/8/06, Lic. Edgar J. De Cleene <edgardec2001 at yahoo.com.ar> wrote:
> So , who is in charge of Alice ?
> And the all Games ?
> And MorphicWrappers ?
> And many , many orphans ? (today I answer to how load StarBrowser)
No-one. And that's a big handicap these days. Because even if all the
packages are maintained, the integration team has quite a task. But
now they have the burden of keeping all the orphaned stuff in tact...
I'm almost inclined to say "kick it out, if no-one wants to maintain
it it's not worth keeping". This would force the issue, but would risk
that some of the cool goodies are left to rot.
These are currently two very important issues for the community to
discuss and decide upon - compatibility and carrying old code around.
Personally, I'm opposed to either one.
<insert sound of Cees stepping on the soapbox>
Squeak was supposed to be nimble, agile, a sort of heat-seaking
missile that could track new ideas just as fast as you could come up
Current Squeak couldn't be much farther from that (as far as Squeak
goes - obviously, there are development systems out there that are
much, much farther from the goal but I won't drop the "J" word here).
Doing work on 3.9a is as much fun as wading through quicksand.
One reason is that we have handicapped ourselves by mandating that all
packages become maintainable with MC. This is a necessary step to be
able to become more distributed.
However, the other big reason is because of fear. The exact same kind
of fear, I think, that has gotten us beautiful products like C++ or
(oh gosh, the "J" word) Java. Fear that being nimble and agile doesn't
That's why we are carrying stuff around in the image instead of
kicking it out, and that's why we all *know* that the whole I/O system
sucks, and that we *know* how to do it better (Flow and the VW
interface provide ample evidence that it can be done better, I think),
but we are simply, as a community *afraid* of introducing breakage.
We are simply afraid that if we introduce a new, better interface, we
may break old code and this old code will be hard to repair. All other
reasons, I feel, are just dragged into the arena of debate by their
hairs in order to prevent us having to confess this very simple fact.
We have the finest development tools in the world, and we're afraid to
Do you feel silly already? Good ;-).
I say: old, unmaintained code should be ejected from the image. Kick
Alice out. If no-one takes it up, that probably means that it is not
important enough. Kick MVC out. Kick all the games out. Let'em be
adopted or rot. Somehow, I think that this will serve as a
self-selection of interesting code because I am quite sure that
*someone* out there wil have enough interest in Alice to either step
up and adopt the code, or - if it is an end-user - rally for support
to have it maintained. Think voting with your feet...
I say: compatibility is not a major goal. It's nice to have, but
shouldn't become a burden. Because if we introduce major breakage (say
by kicking out everything files and network, loading flow, and
declaring that the next version of Squeak), you have two options:
- Stick with the current version for the duration of your project
(every single Squeak version ever created is still downloadable from
Squeak.org - no-one is putting a Colt .45 to your head shouting that
you must upgrade or die);
- Swallow the 2-4 hours of time and upgrade.
A well-factored project will have only minor impact if, say, the
network layer API changes. If your code really suffers, it was time to
refactor it anyway. Don't blame the maintainers of the files/network
kernel for your bad code, and certainly don't put the burden of your
bad code on their shoulders by opposing compatibility breakage if that
results in a better Squeak...
So. that's out :-). I have painted my arguments in black-and-white on
purpose, because I really want this discussion going. I want to have
some sort of simple policies around maintenance of Squeak, where I
would propose "unmaintained packages are not included" and "backwards
compatibility is not a major goal but compatibility changes should be
well documented and well announced".
More information about the Squeak-dev