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