Whither Squeak?

Juan Vuletich jmvsqueak at uolsinectis.com.ar
Fri May 19 17:04:02 UTC 2006


Hi Cees,

As you asked, I'll try to refrain from becoming "opiniative".

I think your diagnostic is great. Incidentally, I said this on the Morphic 
list two days ago:

"I'm a bit disappointed that after some initial interest, nobody seems to be
interested in my objectives for Morphic anymore. I want to simplify, clean
and remove stuff. But nobody except for me sent any contribution in that
direction. ... And I see people believing that for Squeak to be 'serious' or
something, we need native widgets or migrate to wxWidgets or such. So
my ideas don't seem popular anymore.

I also believe that we are having serious problems in setting the direction
for Squeak. Even though we all agree we want a small basic image with
optional stuff in SqueakMap, every release gets bigger and bigger. The
community has people with very different interests and it's not easy to
satisfy all of them. And we are failing at setting teams for these different
areas, with the objective of REMOVING their stuff from the basic
distribution, to manage it outside the image. People seem to think that if
something is taken off the image it won't be maintained anymore. I think
this is not true. A package is maintained if and only if some guys with
enough knowledge and interest take care of it, be it in the image or in
SqueakMap."

In my experience in MorphicSplitters and Morphic Stewards teams, it is
entirely possible to remove unwanted stuff, but it is very hard to make
parts unloadable and loadable back easily and cleanly. My Morphic
Splitting efforts are close to a dead end, because of this and lack of time.
The only hope is that each part is handled by people who cares about it,
or simply discarded.

By now, it's obvious. I'm for the "Retry" option:
"- 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)."
But I would be specific on what goes into the image. If something has a
proven team backing it, but it is not truly essential and can be managed
outside the image, then it should not be loaded.
I mean: Traits should go into the image, but not all of the available 
browsers,
and perhaps not even SqueakMap support. Better if not even Morphic is
there.

Cheers,
Juan Vuletich
----- Original Message ----- 
From: "Cees De Groot" <cdegroot at gmail.com>
To: "The general-purpose Squeak developers list" 
<squeak-dev at lists.squeakfoundation.org>
Sent: Friday, May 19, 2006 4:43 AM
Subject: Whither Squeak?


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

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



-- 
No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.1.392 / Virus Database: 268.6.0/342 - Release Date: 5/17/2006





More information about the Squeak-dev mailing list