Tim Rowledge wrote:
> 
> In message <8525690E.0067B178.00 at intlnamsmtp20.us.pw.com> you wrote:
> 
> > Thanks for your reply. However, I believe that my point #2 and #3 still refer to
> > different aspects of tailoring the Squeak environment.
> Believe me John, I understand the problems all too well having suffered
> the need for many years!

The primary reason I object to Stripping as opposed to Construction is that
you give up all testing you may have done- no matter how much you trust
the stripper, the result is NOT the code you tested, and if you are going
to wait until after stripping to test then you are giving up lots of
component level testing that could have been done.  If you are not going to
test at all, then stripping is fine.  But if you want to be able to establish
some level of certainty about the fitness of your system, you have to test,
and you have to test the system that you are going to deploy, not the one that
you have prior to "packaging" that has all the development tools in it.

So, it's not that I think you shouldn't be stripping things out- indeed,
that would be a part of the modularization effort in many cases.  What
is important is that the resulting stripped component is NOT the component
that might have been tested before stripping, and must be re-tested in
order to re-establish its fitness for use.  Again, if you have no interest
in testing your software prior to distribution it's not much of an issue.
( for the record, the stuff I've made available is definitely User Beware-
but I've never claimed otherwise.  But at some point wouldn't it be nice
to have an IMAP client that I could certify to you as having met whatever
standards are applicable, and to what extent, as opposed to "I have an
IMAP client.  It works in my image.  Good Luck" ).

Also, I believe you will discover that compilers in other languages such
as C++ do not actually remove code in the way you might be thinking- a library
linked into your code is linked in its entirety, not just bits of it.  This
is done for exactly the reasons I point out above. ( Admittedly, I'm going
out on a limb with this statement as I haven't used anything other than
Smalltalk for about 6 years, but I'm pretty certain this is true ).

I don't see this as a competition between the "Program-Time" and "Run-Time"
mindsets, though.  I see it more as an issue of whether a delivered
system is supposed to be granting the full power of a programming environment
to what most developers would consider end-users.  There's nothing wrong
with doing that in contexts where it makes good sound sense for the end-users
to have that kind of power, however much of it you wish to make available.
But there are cases where a system should not have that kind of power, and
in those cases it would be nice to have the means to control very explicitly,
without guesswork, and to a very fine degree, exactly which bits of power
the end-users get.  Either you have that, or you are telling potential
developers that they should not use Squeak because it is more important
to the Squeak community that everyone who gets anything built using
Squeak have as much power as the organization which built the delivered app,
so much so that we are giving that organization's customers the power to
open up the application and change it to suit their own personal whims.
Again, in some contexts there's nothing wrong with that at all, and even
highly desireable. But not in all of them.  We can support both.

That being said, let it be clear that the thing which lured me into
the Smalltalk world was precisely the notion that the users would be
the gods of their own software world.  Not a bad vision, and one that
I happen to agree with in many ways.  Especially when I get e-mail
viruses from reading the mail using certain "closed" products.  And I
can't tell you how many times I've tried to initiate a walkback on
some non-Smalltalk commercial application to find out what on Earth it
was doing that was taking so long, so that I could go in and fix the
damned thing.

But on the other hand, that power is undermined when the user cannot tell
what state their world is actually in without having to expend unpredictable
and quite possibly enormous amounts of personal effort to make that
assessment.  The existing tools within most Smalltalks just don't cut it
once we get beyond a few hundred classes in a few dozen categories.
By the time you reach a few thousand classes, the situation is not good
at all.  More is needed in order to have the same level of control as
one might have had back when the image only had 100 classes.  That will
be a challenging goal, but one that will have to be hit head-on if
we are to truly have all of these distributed repositories lying around
the globe ( does anybody remember my mentioning this years ago? I thought not).



- les