Whither Squeak?

stéphane ducasse ducasse at iam.unibe.ch
Fri May 19 19:26:36 UTC 2006

> Us board folks have been discussing where to go from here and I
> personally would like to see a lot of discussion on this on
> squeak-dev, so I am going to completely unofficially kick off this
> discussion :-).
> I'll present this as a set of bullets, I think it would be nice if we
> could have a round of brainstorming first to complete these lists
> before becoming opiniative.
> Pressures:
> - Squeak 3.x is so far quite succesful in resisting us applying
> software engineering efforts to it. The reasons are manifold, but two
> major reasons are manpower and available tools, neither is going to
> change any time soon;
> - It looks like squeak-dev is on its own, with the two main projects
> that are using it (SqueakLand and Croquet, of course) effectively
> having forked. There always has been a perceived need to be stable to
> support these projects, but in howfar that is necessary at present is
> open for debate;

this is true that despite our effort (which bound our hand) people  
to fork which I can understand. Now this is nice to see that the  
fixes of SqueakLand and SmallLand
have been retroffited into 3.9

> - There is an awful amount of ideas, and an awful amount of talk about
> what hasn't been done to Smalltalk since Smalltalk-80. Some of these
> ideas were bad, a lot were good but haven't been implemented, and some
> have been implemented. I think the number one reason for not
> implementing good ideas is inertia due to having to support a large
> codebase (see the point about SqueakLand and Croquet).


> Possible solutions (given in "who is General Failure and what is he
> doing on my drive?" style):
> - Abort. Go back to the SqC model and live with a monolithic image (do
> not scale);


> - Retry. Declare Spoon to be Squeak 4.0, declare that that is all that
> is going to be "officially" supported for the time being, and refuse
> to support anything additional that doesn't have a proven team backing
> it (scale up).

I like the idea but with that model so far I would not be able to  
teach or work.

> - Ignore. Keep on following the (distributed) software engineering
> trail, but realize that it may take 5 years before we have a
> modularized, manageable Squeak (scale down).

Yes this is true.
May be we could be much more aggressive, there. So far we have been  
quite conservative
I would dream to remove a lot of old code, but was always afraid to  
break too much stuff.

I think that we can play it from both ways at the same time:
	- Continue and really declare 3.9 is the last compatible release and
	start removing large parts, change the method format....

	- at the same time people continue to build Spoon and at one point
	we should be able to meet = using Spoon as the mini-image.

> I have a clear preference, but I am not giving it until after a bit of
> brainstorming here on the list. I hope that the rest of you will be
> able to show the same restraint :)

Now Cees another question is while this is nice to ask the question  
this is
also nice to ask who is doing to do that?


More information about the Squeak-dev mailing list