Having packaged Smalltalk apps in the past, I agree with this, and would 
remind people that the whole "shrink" metaphor arose out of commercial 
goals -- that is, in order to deploy a Smalltalk "application" built on a 
proprietary platform you needed to remove the compiler and development 
tools to comply with a vendor's license. Since Squeak does not have such 
licensing issues for deployment, the whole "shrink" idea is obsolete IMHO.

Why take a perfectly working application and start potentially introducing 
all sorts of random errors into it at the last minute just to save a bit 
of storage space and network bandwidth (especially these days)? And if 
storage space and bandwidth does matter in your situation even now, then 
building up from a small base (including a text based one) is a much more 
reliable way to produce quality deployable applications.

--Paul Fernhout

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.