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