Personally, I often find that I need to iterate over a range shortly after I’ve implemented something complex in a hash, e.g. an LRU cache or whatever. Yes, you could say this shows a lack of foresight

For the search of hash usage vs tree usage, I’m going to attribute this to the English Effect. I’m sure if you look at a typical native lisper’s code where trees are 1st class structures and hashes are definitely 2nd class, they will find more utility for trees. Heck, even C++ got map before hashmap.

Anyway, interesting discussion. I enjoyed it

I think we are in violent (mostly) agreement. Both of us have said that if you want sorted range iteration of some kind, then you ought to use a tree instead of a hash. No argument there. I think where we disagree is that you think sorted range iteration is a common thing to do; that has not been my experience. Nor can I think of too many instances where it would have been helpful.

As a quick-and-dirty calculation, looking for HashMap in Java code via codesearch.google.com results in more than 10x the number of hits than looking for TreeMap. This is an imperfect way of looking at it: the first page of results for both are from open-source Java implementations, for instance. Context is also lacking; the keys from those HashMaps might be sorted for further processing, in which case a TreeMap might have been the better choice. But 10x suggests that a fair number of other programmers think sorted range iteration is not a very common operation either.

Although yet, followed by a reason would work (it would still be a little clumsy) I’m afraid YET! doesn’t work standalone in the same way as Doch (if I understand Doch usage correctly – admittedly I don’t intuit German well). AND!? might work better, but then I think UND!? would be similar in German and still different from Doch oder?

on trees requiring a less than function: Hashes require a hashing function. If a built-in hash can provide a hashing function for anything under the covers, so a built-in tree could provide an ordering function under the covers (if you’re really stuck for ideas you could use less(hash(key)). In some cases an ordered traversal would return seemingly random elements, just like a traversal of a hash. In others, an ordered traversal would do what you expect.

Aside from a slightly slower store/retrieve operation, you don’t lose anything by having your fundamental type be a tree instead of a hash. But in many cases you gain a decent key range operation.

I don’t doubt that you understand what a tree is. But I think the fact that you don’t see opportunities to use them all over the place just means your native language consists of scalars, extensible arrays and hashes which has constrained your thinking. I think I have the same reaction to Graphs. I know what they are, and I have some ideas about the problem domains in which they are useful. But doggone it, I’m sure I could just replace them with a tree and not lose too much!

It’s the English Effect – my language doesn’t contain graphs, or Doch!

You can always follow ‘yet’ with your reason,
or you can let it stand-alone as your comeback.

YET! …

If trees are your fundamental map, using them requires you to implement an ordering over whatever type your keys are. Which can be an unnecessary irritation, especially if you don’t naturally think of your keys as having an ordering. Or maybe it’s not straightforward to give them an ordering. And it’s another piece of code to write and debug… Hashes (in dynamic languages) make it very easy to use whatever you like as a key; the implementation hides all those details.

Ordering constraints also make using multiple datatypes as keys tricky; doing so is very easy with a hashtable. (Granted, I think it would be unusual to have such a table.)

Depending on your area of concern, these may be trivial or they may be significant speed bumps.

And I kind of get that rationalization. But if I was only going to get one of hashes and trees, I’d rather have trees. Log2 N isn’t much slower for normal usage, and you get much saner range traversal.