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