Python at Disney
JArchibald at aol.com
JArchibald at aol.com
Fri Mar 9 16:50:33 UTC 2001
=> 3/9/01 8:27:45 AM EST, pdfernhout at kurtz-fernhout.com =>
<< Them's fighting words, but IMHO "shrinking" is a terrible idea that
exposes a fundamental flaw in the system's design philosophy. :-(
Specifically, "shrinking" is a bad idea because it requires the average user
to understand enough about modules they don't want to use to remove them --
and that is a task difficult enough for the module's creator. >>
Paul,
I couldn't agree with you more. #majorShrink was an expedient that Dan
Ingalls worked out a long time ago to enable Squeakers to create a
stand-alone Smalltalk system (without the Squeak additions). At that time
(going back quite a ways) he also produced something call "tiny Squeak" which
was even smaller, probably the first headless Squeak -- this was not really a
Squeak system at all, but a minimal Smalltalk having no windowed tools.
I don't quite understand what various industrious individuals are doing using
majorShrink recently. Certainly some of the recent contributions to the
Mailing List concerning majorShrink are by those who seem to be using it for
(perhaps) strange purposes. I have suggested that the only reasonable use for
shrinking is as a packaging tool.
Nonetheless, Squeak's popularity has led a number of users to create Squeak
based systems with the wish to deliver them in one fashion or another,
without the burden of other facilities which would otherwise be available in
their delivered package. Partly it's a matter of size, but also that of
dependencies.
I would take minor issue with the concept of shinking being a subtractive
description for componentizing Squeak; I don't think that it's that good.
It's just a bunch of code that allow one interesting subtraction to be made
-- no one has spent the time to work out all the details of subtracting each
individual piece. The various methods of the "shrinking" protocol in
SystemDictionary are a little misleading. It is not at all clear what
additional work is needed if you want 1 from column A and 2 from column B
(etc.).
In order to move to a componentized delivery vehicle, we need a several
things: (1) Componentization tools, which enable one to describe accurately
the "additive" (or "substractive") descriptions of Squeak based components,
(2) documentation of the components (or at least a start) in an existing
system: what each component promises to deliver and how they are structured
-- this structure would form a lattice: each component needs to know what
other components it is dependent upon, and which are dependent on it. At the
bottom of this lattice is something like major Shrink or tiny Squeak, or
perhaps just what is needed to make the interpreter work (even below the
compiler) -- at the top of the lattice is an entire Squeak delivery (say 3.0
final), (3) Definition of the "shadow" areas, where _distinct_ code is
necessary to load components which have some interdependencies. An example of
this are the various menus defined within Squeak. They often need definitions
(separate methods) which are determined by what components are being made
available in the "build" at hand, and (4) the most difficult, a "process
technology" which enables the Squeak team (both SqC and outer Squeakdom) to
work into the future with a common model of function delivery. Although CVS
is proposed again and again, and certainly the Squeak community has had major
exposure to such (modern) tools as ENVY, Convergence, Team/V, and now
VisualWorks StORE, each of these seem to be based on a somewhat different
community of developers.
Today we have one core community, Squeak Central, which produces the official
releases. In addition, we have a number of additional efforts, each of which
is persuing some individual line of research. These are often outside the
scope of the official releases. SqC has gradually contracted its involvement
with many of these (presumeably in self defense -- quite understandable when
one views the potential mess that could have resulted with the recent 3.0 -
3.1a deliveries). FWIW, I think the SqC team deserves a round of applause
for what seemed to an outsider like a somewhat nightmarish period.
Nonetheless, it is apparent that in order to maintain cohesiveness, SqC will
often have to limit their interaction with many interesting efforts at
certain times. These are all marks of a success, and I don't think anything
should be done to curtail this trend (Dan I. (and others) have to get some
sleep sometime :-) ). Future success of Squeak will result in even more
threads of activity than there are now. And SqC will have to limit to an even
greater extent which of these threads become part of the official releases.
I would suggest that if Squeak's future is going to capture the excitement of
efforts past, that some mechanisms are going to be needed to address and
assist this componentization and function delivery problem. Your comments
seem to been an appropriate "white paper" on this situation.
I find this a substantial and interesting problem in its own right. If there
are those who would like to do something here, let's make it happen. I'm sure
everyone wants to comment on such efforts, but clearly a group dedicated to
creating new facilities to solve the problem are needed. I'm in, Paul.
Assuming you are too, who else?
Breathe (whew!),
Jerry.
____________________________
Jerry L. Archibald
systemObjectivesIncorporated
____________________________
More information about the Squeak-dev
mailing list
|