Sorry for being away the last few days (work related).  I didn't intend to 
throw grenade in and then just leave. :)

To start off I decided to address this point first:

>
>On Aug 30, 2006, at 8:35 AM, Ramon Leon wrote:
>
>I agree that Smalltalk has excellent tools for sifting through the  source 
>code. However, this can be a barrier to entry for newcomers.  We need a 
>constant supply of new blood, otherwise Smalltalk will  wither and die.
>

Or maybe just tread water when it should be leading the pack.  These
two possibilities are pretty much equivalant in my mind.

>Also, I  hate being isolated from the rest of my desktop. I'm a mac  user. 
>I like my mac. I like my mac apps. I wish Smalltalk could be  part of that 
>environment. Visual Works gets a few points here. At  least it looks like a 
>native interface (Though, the UI doesn't behave  in a consistently native 
>manner--which can actually be more annoying  sometimes. And it doesn't run 
>on intel macs yet.).
>

You points on the environment look are certainly valid (though I don't mind
it personally).  As far as isolation from the rest of the desktop, let's 
look
at how everyone else does it.

In Java, C++, Ruby, Python, et. al. how does one build an application?
1. Determine what your application consists of (or what you think it does)
2. Identify what code has already been written in this area (and hopefully 
us
      squeakmap like app to download/install it)
3.  Forevermore remember to import/#include/re/whatever to get the code
     you want visable to your system
4.  Develop the code (glue together the components, try new components, etc)
5.  Package it up and deliver it to the customer.

Now many times you wont identify what you need in step 2, you will see some
*possibilities*.  You may have to try out several of them to see what will 
work.
When you change one implimentation for another you have to remember to go
and remove all the references to the previous component.

How does smalltalk do it?  The same as above, just remove step 3.  The cost 
is
that step 5 gets more complicated.

Stated another way;  the approach used by other languages is start writing 
one
or more files that may use one or more files to build up your application.  
The
smalltalk approach is to build the application from *within* the application
you are writing.  For every new app you write the image *is* effectively 
this
new app until you deploy it.  At which point it becomes the next app you 
will
wright and so on.

Smalltalk is the only one to get it right IMO.  When someone sets out to 
build
a car, airplane, building or whatever they build the peices they need and 
make
schematics to describe the different components.  Once a built component is
used in a product it is gone and must be rebuilt for the next product.  Not 
so
with digital media.  Once we have the component we have it from then on,
no more component assembly required.  Manufacturing companies have
spent lots of money developing special assembly lines to get as close as 
they
can to what we have for free.

Conventional programming languages have this also, but the components
are laying somewhere in a huge garage, you have to go dig all over for them.
In smalltalk you just say "Hammer hitNail" and it is magically in your hand, 
unless
you never went and got one in the first place.  But once you get it you have 
it.

When you build the smalltalk application you get all your classes working 
right,
save the image, then do step 5: remove everything you are not using.  This
seems right to me, it is consistant with the concept of garbage collection: 
it
is faster over all to do cleanup all at once instead of every time you 
change
something (e.g. removing import statements for components that turned
out not to work for you).  And it can all be done programatically, as 
opposed
to the by hand method required with other approaches.  So if something
doesn't get taken out that you thought should have you can go find out why.
More bug protection.

Now, after you deploy the application you start your image up and guess 
what,
the application you just deployed is still there.  So now when you make a 
new
application it is really simple to refactor the common parts together.  I 
did this
with some of my programs in Borland C++ builder.  It worked, but it was much
more complicated then just making a few new classes and doing a little 
refactory.

In fact, *every* application that you or anyone else has written is 
available in
your image.  Including applications for debugging, playing MPEG's and 
everything
else.  But that is ok because these applications will help you build the 
next
application you are working on (well, some will help more then others. :)
and it can be automatically removed before you deploy.

If the image feels isolated from the rest of the desktop it is because you 
have
never been able to do this before. :)