This is the main difference between a Smalltalk system and a conventional
system.  In all other environments for the most part you need to start your
application with no objects, and create each and every one explicitly.  Even
if you load them from a data file your application needs to create them each
time it runs.  This creates multiple representations of the same
information.  It exists both on the disk and in RAM in different forms.
Keeping those two forms in sync becomes a major undertaking and a large
source of errors.  There is no GC for objects on disk for example.  Only the
GemStone database provides live objects that are persistent and active
without explicit run-time recreation.  Of course it is Smalltalk based as
well.

Michael

> Well not quite the same. In Smalltalk all existing objects in the
environment would get the new behavior so > one can add new methods to
"live" objects. This distinction can't be overstated.  Language to language
> comparisons can be useful but comparing a grove of orange trees to an
individual apple often isn't very
> helpful and can sometimes be very misleading. If you take time to wander
in the grove of the Smalltalk
> environment for a bit, you'll start to see things differently. You may in
fact find  situations for which 
> Smalltalk isn't the best tool to employ, but it probably won't be because
of a language feature. In my
> experiences, it usually is because of a schedule/level of expertise factor
or  something to do with the
> politics of the decision-makers. 

> Cheers,
> Laurence