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;

:)
Smallland
this is true that despite our effort (which bound our hand) people  
preferred
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).

:)
exact!

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

Indeed.

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

Stef




More information about the Squeak-dev mailing list