Well, I sort of disagree. True, for the individual, there is not 
tradeoff in having images. This is like for the individual, there is no 
tradeoff in having sound proof ear muffs. When you want, you can remove 
them and talk to people, when you want, you can put them on, and have 
some peace and quiet.

The problem is that when everyone has them, it might be difficult to 
find someone to talk to.

The analogy is deeper than it looks - how much code, how many projects, 
are preserved, but unshared, sealed in their own little images?

As was demonstrated last ESUG, this makes for wonderful archeology. 
However, textual scripts that do not preserve too much context, but are 
just code, are in many ways easier to share with other people. 
Therefore, they are better memes than images are.

Of course, this is far from being a state of affairs we can't change. 
Just using Monticello makes it much much easier to share code, in many 
ways easier than sharing code using other, file based versioning 
systems. But Monticello, while not that complicated in itself, is not so 
trivial to use as ChangeSets, or saving the image.

So someone looking for the right environment to learn, should learn 
Squeak, but also Monticello. And for those of us that live in Squeak 
already, we should make it easier to live without those ear muffs.

Daniel

Lex Spoon wrote:
> Overall, a better question is why Ruby and other dynamic languages do
> *not* support ongoing images and image snapshots?  Why *should*
> programmers be content to reboot their programs all the time?  There is
> no tradeoff involved once you have dumped static typing.  It's a pure
> win. Programmers can "use" it when they like--i.e., they decline a
> gratuitous reboot--and they can use file-based stuff as their programs
> mature and their abstractions crystalize.
> 
> I only know one compelling explanation for this development:  The
> original PARC implementations had it, and no Smalltalker afterwards
> would tolerate less, but it's still too difficult and too strange even
> for the rest of the world's best language designers.  Kudos to Alan Kay
> for prioritizing such a useful and sadly uncommon feature, and kudos to
> Dan Ingalls and Ted Kaehler and many others down the line for
> implementing such a difficult feature.  I wish more language
> implementors would follow their lead.
> 
> 
> -Lex
>