Ahh - that got your attention.

No, I'm not really opposed to improving iteration speeds, by all means have
at it.  Terrific idea. My own vote is cast for a hashing class based on
SHA5.  I think you could get interesting results from using a perfect
hash,even if the thing is 120 bits.

On the other hand, maybe I didn't make my original point too well.  My
thread started over "can one language do everything" and my response was
"no, languages are tools and you shouln't pound in a nail with a power saw".

>From my own perspective, I live in a world where we drop down to native
platform machine code in a few places, and C++ code may often be written to
deal with little issues like "Pentiums usually predict you'll take a reverse
branch over a forward branch."  When performance gets to be that much of an
issue (we have clients that require many billions of high level linear
algebra calcs per second) you tend to survey your language tools very
carefully.

For the record, C++ iteration is what we use to deal with problems that
really vex the computer but that the user could care less about.  Smalltalk
has a richer and more powerful set of iterators and collections than STL,
but the costs of such a dynamic flexible solution are more than we can bear.
Nothing I've said should be construed to mean I'm talking about collections
the user interacts with directly.  In my first post I observed that C/C++
was prefered over Smalltalk when the computers oddest peripheral wasn't
directly involved   :-)

I really only keep responding to this because I do feel it's
counterproductive to go "I don't care what you got, Squeak can do it
better".  I'm just arguing for a slight modification -  If you don't care
enough to profile it to death, then Squeak will do perfectly.   Recognizing
this means we can say, we don't care what your problem is, what Smalltalk
can't do well directly it can do by being extended.  Legacy systems,
databases, whatever.

But I rather violently disagree with those that claim you should just use
Smalltalk cause it's iterators aren't as fast as C/C++.  Bull.  A C/C++
iterator/loop construct is a lot more expensive to write, a lot more
expensive to maintain, and a lot less accessable.  It's also a hell of a lot
faster cause it's compiled, and cause if performance is the central thread,
it's using static storage.  For example, in such a world one has a tendancy
to use a vector to aquire data of unknown length, and then immediately
reconstruct it as a fixed size array as soon as the length is known.

On reflection, if there are those who think I'm arguing for recoding the
collection classes or using plugins to do collection --  neat idea, but no.
I like Smalltalk collections just fine, I was only using
collections/iteration as an example of why languages were tools.  What is
particularly interesting these days is that Smalltalk and it's close
relatives seem to be the only ones that truly recognize that the class
hierarchy is in fact a derivative language, and implicitly, a tool in its
own right.  In the real world of C++ it's hard to keep two class libraries
from either stepping on each other or being incapable of efficient
interoperation, depending on namespace:.  In Smalltalk land, we regularly
seem to throw 30 peoples work into one unified whole with a lot less sweat.

I wrote a book in 89 under duress about how to use C++, and my primary focus
was on 'if you do these things this way, you too can have the ability to
create and share class libraries like we do every day in Smalltalk'.  Funny,
things haven't worked out that way.  Yes we have more libraries, but nowhere
near what I have expected.  Now that's what I think is most unique of all
about the Smalltalk tool.  Why is it so damn good at collecting, merging,
and sharing the work of many participants and everything else just sucks
soooo bad.

Mark