I agree
And what is an image if not a clever cache.
So why the following scenario would not work (dave thomas was  
describing it somehow at ESUG in 2002 ) and dave simmons S#
was basically it (certainly GNU Smalltalk bootstrap too):
	- have a tiny core
	- load the packages from a script
	- save your cache

to deploy remove the tools and other development packages.

On 26 févr. 07, at 13:18, Ralph Johnson wrote:

> Given the current state of things, it is important to have tools for
> shrinking.  I've been programming in Smalltalk for 20 years, and I've
> seen lots of different tools.  My conclusion is that the "shrinking"
> model is flawed, and it would be better to focus on making Squeak
> "growable".
>
> If you develop in an image and have no way of getting all your code
> out of an image then you are in trouble.  Images are fragile.  You
> can't merge images.  If you want to give your code to someone else, or
> if they want to give it to you, one of you has to move code out of the
> image and give it to someone else.  So, it is important to keep your
> code in files, whether as .cs files or in Monticello.
>
> If your code is in files, there is no argument against growing an
> image.  Sure, you will develop in a huge "dev" image.  But it is built
> out of components and many of those components are not used by your
> application.  It is a lot easier to shrink a build script than to
> shrink an image.  You could have a tool that automatically shrinks
> your build script by deleting packages one by one and seeing if your
> application still runs all its tests.
>
> Shrinking an image is hard work and not for the faint of heart.  I
> always tell my students to build their application first and worry
> about shrinking at the end.  That is because they will be a lot better
> at Smalltalk at the end of the project than at the beginning, and so
> they will be better able to learn to shrink their image.
>
> -Ralph
>
>