Stefan,

I've enjoyed your posts on this subject and have mostly held off on commenting. Well, all good things must come to an end and all that, so here's my view on a few issues that I feel are strongly related to each other. Though my views are strong, I suspect that we are probably more closely aligned than the following text would suggest.

Take care!

- les

Stefan Matthias Aust wrote:

Paul,

Some comments on your text heavily influenced by the other answers I read.

...

• Doing odds and ends related to stability and testing

Unit tests for the base image would be nice. Yes. However as most parts of the core system are used in the development tools and are very much interconnected, the whole system is its own big unit test already and this point has a lower priority.

In your world, that may be the case- but some would like to have a better understanding of the reliability of the tools that they use. I happen to think that overall Smalltalk ( and of course Squeak ) usually is pretty good- but I don't have the ability to say that I KNOW that. Squeak in particular is tough to consider as a strong system simply due to the high rate of change it is going through right now. How would you certify that it is a strong system at any given point? Systems in flux, even Smalltalk systems, are much more likely to have more errors in them than systems which are not being changed on a continuous basis. On the other hand, if that system is constructed from independently testable sub-components, you stand a much better chance of being able to keep the error count down as the system evolves. True, we do have some benefit along those lines- classes are a big boon for that. But I think more is needed at a "system of classes" level that is below the "entire image" level.

...

• Namespaces

Would be nice, but not really needed if you want to create shrink-wrap applications as you've then total control over your image. It's more important to have name spaces if you want to create frameworks or other modules that should work in other people's images.

You do not have total control over your image if you cannot tell what belongs there and what can be safely removed without having to personally expend arbitrarily large and unpredictable amounts of effort in doing so.

...

• Image buildable from scratch

Why? While this would be very interesting from a theoretically point of view, I don't need this for application deployment.

Which is more likely to work- a system constructed from independently testable and certifiable sub-modules with known interfaces, or a big ball of mud that was tested and certified but then subjected to a stripping phase where you don't know what all was removed, or for that matter, left behind? It's not an academic problem- it's a real-world issue of being able to state that your system meets a certain level of confidence. Systems which are stripped after testing are NOT certifiable to any level of confidence, as they are no longer the system that was tested. Nor can you map the reliability of an unstripped system onto a stripped system- they are not the same. You are then hoping that your testing on the stripped system will be sufficient to accomplish the same level of confidence that testing on individual components as well as being able to test the fully integrated system would have achieved- that is, you are trying to achieve the same level of confidence without the benefit of component-level unit tests. Also, is it more likely that a stripping process will spontaneously fix errors or create them ?

...

• Producing a small footprint image with all "clutter" removed

Actually, this is more a psychologic thing, I started to realise. If there're no really rigid space considerations, it really doesn't matter whether the image is 2 MB or 5 MB. As always, it depends.

And creating such an image isn't that difficult. One could refactor the current image within 2-3 days to easily reach 1.5 MB for Core+MVC+development tools. Again, I know how to do this.

But you didn't when you started- and it apparently took you several days to figure this out, a time that many would not find acceptable. It makes no difference whether there are "supposed" to be methods to take care of this for you- in your case, apparently they didn't work and before you could get on with the job you had in mind ( packaging the image ) you had to first fix the tools that did the packaging. Those fixes in turn could also be prone to errors, you know- so now you have a stripper of unknown ability chomping through your code. Well, if you read my comments above you know where I'd go with THAT situation.

Besides, if I could construct a packaged application from scratch in 2-3 hours with a known level of confidence, why would I want to spend 2-3 days stripping an image to package an application which I'm pretty certain would not have the same level of reliability?

The only problem is, we first have to shoot the person who had the idea to use the class SoundBuffer from all 1000+ classes of Squeak (instead of some core class) in the image segment code to determine endianness. Just as an example to demonstrate what happens if you don't think in modules and don't obey the module interfaces.

This is symptomatic of a philosophical problem- either you feel that it's ok to build big balls of highly coupled mud, or you don't. If you don't, then you will want the tools you use to have properties that Squeak's tools do not have at this time. However, IMO it is possible to provide those capabilities without undermining the things that we love about Smalltalk.

Then, after the blood dried up, we can refactor and clean up the image without much problems.

Using what? How are you going to decouple the hundreds ( actually, isn't it thousands now? ) of classes already in existence ? What strategy are you going to use- your small steps are going to be competing with the Great Giant Leaps of the change stream? Dubious, I think- in fact, I suspect that it would be highly unlikely. For one thing, who outside of SqueakCentral feels that they have the confidence to undertake such a task while development continues at the current pace ? My own feeling is that everything you do will be obsoleted immediately.

--------

So, to summarize- the situation as I see it is that there actually is a need for tools that would support "A Different Way of Doing Smalltalk Development". That doesn't mean that I think Squeak ( or Smalltalk in general ) is incapable of being used as a serious development tool- in fact, I haven't used anything else for years now. It just means that I've seen opportunities to make an already strong system into a very strong system, one that can completely silence any criticisms of being untrustworthy or otherwise unsuited for "serious" applications. It's not the criticisms that bother me so much- it's the fact that often I have only vague generalizations to offer in defense, and I'm pretty tired of that.

So Paul McCullough, if you are reading this, I'm interested. Caveat: I have some idea of the issues involved, and they are not trivial. Luckily, I did not know that at first!

- les