Tim Rowledge wrote:
In message 8525690E.0067B178.00@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