I read with great interest Stefan's (and Paul Fernhout's et al) postings 
re: making a small image.

Looking through recent postings, some folks want to remove MVC, some want 
to remove Morphic, some want a minimal system, some want to deploy 
reasonable-sized apps.

With many projects I've worked on,  I've encountered similar needs: "we 
need to make the image smaller", "let's develop a minimal image", "the 
delivered product is too large", "we'd take out the unneeded code if only 
we could identify it".

The earliest suggestion I personally know of to develop a minimal ST80 
image came from Steve Putz while I was at PARC sometime around 1984-5. The 
problem is not new.

The various image strippers, or tree shakers, have problems -- believe me I 
know. I've used tree shakers in three major Smalltalk system,. Heck , I've 
written some of them. Tree shakers suffer from the problems noted in the 
Tales Of Dying Objects postings.  In particular, deep knowledge of the 
system is needed, that knowledge is not easily gleaned, that knowledge is 
easily invalidated in subsequent releases because someone (perhaps you, 
perhaps an unknown person) made a connection between two parts of the 
system without considering how that change would affect the tree shaking 
code. It's sort of like sculpting a block  of marble: in the hands of 
Michelangelo, a great masterpiece emerges. In lesser hands, you are likely 
to get rubble. You did back up your image didn't you?

Tree shakers also suffer because they typically remove entire classes -- 
but sometimes the cruft is  simply methods in "system" classes. All those 
little methods add up -- it's sort of like backpacking. You never put 
anything heavy in your backpack --so why does it weigh 70 pounds the first 
time you pick it up? How can I tell, a priori, if I can safely remove 
Object>>flash? For that matter, how can I tell post priori? Same problems 
for Object>bindingOf: and many other messages in "system" classes.

I suggest we consider moving Squeak to a different style of development -- 
one in which we can deliver stand-alone apps of minimal size and, perhaps, 
still support the free-wheeling style which many have grown accustomed to. 
I freely give credit here to Allen Wirfs-Brock who asked some of these 
questions years ago. Hopefully, Allen will add to this discussion.

What can be achieved? I seem to recall Allen saying that Hello World in 
Allen's Modular Smalltalk was under 64k (contrast that to a C-based 
X-windows  version...).

In nearly every other programming language, you can point to the source 
code (which many be in several chunks) and say "that is my program".  In a 
current Smalltalk system, that task is oddly difficult. When the Smalltalk 
aficionados were showing the ST80 system to neophytes, the most common 
question was "where is the program"? It's hard to answer because the 
programmer has great flexibility in Smalltalk: you can easily 
extend/override a system class; you can rely on a method that you think is 
a system method -- but which came in with the mail reader. You can remove 
methods you deem incorrect from someone else's classes. It''s easy to 
loosed a change from a changeset. Of course, one of the blessings of 
Smalltalk is the lack of boundary between system and user classes. But when 
it gets to be time to release a product, those fuzzy boundaries feel more 
like a curse.

There are those that argue that a source management system will fix these 
problems in Smalltalk. Indeed, I've seen and used several such systems. In 
my opinion, they didn't cut it: too big, too complex, too non-Smalltalk, 
too authoritarian.

So what, in my opinion, would help? The one thing I've heard of (alas, no 
direct experience) was the Firewall project that Allen Wirfs-Brock & Steve 
Messick (and probably others) worked on. Have a development environment 
where pretty much anything goes. And a target environment which starts out 
empty. If the user doesn't say to add class Point to the target, it isn't 
there. Not much different from importing packages or classes in Java. Or 
having include files in C. But, in those languages, I can easily say "this 
is my program." And I can easily make a reasonable-sized executable. Of 
course, we'd still allow you to modify a system class if you needed to -- 
but you'd only be modifying it in the target.

Doing the work this way means you don't remove stuff to make a headless 
system. Instead you add the stuff to make Squeak have a display. You don't 
have fights over whether to remove MVC this month or next, you load it if 
you want.

One very necessary item missing from Java and C is versioning of packages. 
It can be pretty frustrating moving a working Java program from, say, 
version JDK 1.1 to JDK 1.2. Stuff that used to work doesn't. Methods have 
been deprecated. Work-around methods may not have been well thought out. It 
would be so much easier if when you imported package foobar that you said 
you imported foobar  version 1.1. Then, you could continue to import that 
version and your program could continue to work.

So what would it take to make such an environment? Allen and Steve have 
much more experience at it than I. But as a first cut, we would need to 
break the system into small packages -- the packages will have to have 
pre-requisites. Be sure the packages can be compiled -- Squeak is probably 
better off that ST80 where some objects existed in that image as a result 
of executing doIts alone -- the source code was long since lost. Clas 
Object could be much smaller -- extensions for C code generation would be 
in that package, not the base Object. Ditto for Morphic extensions. And 
object segment extensions. And on and on. Build tools and a VM which can 
talk via a simple connection between the development environment and the 
target. Provide a way to squirt classes and individual methods across the 
interface. Debugging would run in the development environment and use the 
simple connection to control execution on the target. Modify the 
programming tools to know which environment they are working on.

This work won't be easy -- as we try to slice and dice the image, other 
folks will be adding stuff in subsequent releases, and the number of funky 
connections between classes will increase. While we're trying to make 
Object small and elegant, other folks will be adding new  (and strange) 
methods. Reminds of a project where I added a database to a quite complex 
Smalltalk-V system. Due to market needs, the team couldn't stop adding new 
features while I did the database work, so I had to track everyone else's 
changes. By the time we reached congruence, Ward Cunningham likened the 
work to doing a heart-liver-lung transplant while the patient and surgical 
team were all running uphill.

Thanks for reading this far. I fear I should go back and tidy up the 
writing and more clearly express ideas, but it's late and I'm tired.

I have some spare cycles coming up. I am seeking others who think this an 
interesting goal to pursue and are willing to commit to making it happen.

Cheers,
paul