I agree with that. 'map' or 'dictionary' are the best choices I think (or 'associative array', but why bring arrays into it). That's the interface, of which a hash table is just one possible implementation.

I've never liked 'dictionary'. The analogy isn't at all apparent to me. A dictionary explains what words means. The thing we're talking about doesn't explain what keys mean. (Someone who spends most of his time writing python here.) 'map' or 'mapping'.

It's about the operations. One Does Not Simply (tm) read a dictionary. One instead performs a “lookup” for a particular item. The dictionary is designed to make this lookup fast and reliable, which matches the purpose of these data structures in software.

A dictionary maps words to their definitions. The words are the keys, the definitions are the values. Seems reasonable to me. Though as another predominantly pythoner, I do prefer map as well.

In a dictionary the value (meaning) is often (partially) implied by the key (word), by etymology etc. In the data structure there need be no relationship between the key and value other than the fact that they are a key-value pair in this instance. It introduces messy cultural concepts into what should be a clean, abstract concept.

I think dictionary is a useful high-level analogy. Small key objects mapping to potentially large, and often structured, value objects. (By structure, I mean the definition in a dictionary often includes fields like pronunciation and origin.)

Sadly "map" is also the name of the critical "map" function which operates on lists. Maybe with an indefinite article ("a map") it's clear enough.

Sure, so go the Lua route: table. Or the python route: dictionary. If neither of those do it for you, how about "mapping"?

Hash (and hash map, hash table etc) leak too much implementation detail. What if you want a tree-based mapping instead? I like how in C++ it's map (for ordered, rb-tree based maps) and unordered_map (for unordered, hash table based maps).

I'm going to try out "mapping" -- good suggestion.

This bit of ruby should take care of it

    HashMap = HashTable = Map = Table = Dictionary = Hash

And if you're feeling adventurous,

    Object.send :remove_const, :Hash

Please never, ever do this

If doing this is such a bad idea then why is it so easy?

If doing:

  #define BEGIN {
  #define END }

were such a bad idea, then why is it so easy?

Maybe the language is poorly designed.

Or maybe the connection between being able to do something and it being a good idea to do something is just in your head.

In my experience, making obviously bad things difficult or impossible improves reliability. This idea certainly resides within my cranial cavity, but that doesn't necessarily make it wrong.

How could:

  HashMap = HashTable = Map = Table = Dictionary = Hash

possibly not qualify as "obviously bad"? The only reason you've offered up is because it is easy...

I think this is fine. The obviously bad part is being able to remove/change constants, especially as these changes are global.

The obviously bad part is that you pollute the global namespace for no reason other than laziness. When someone comes across code that uses a "Table" object interchangeably with "Dictionary" and "Hash", then he's going to have to look through the source code to find this bizarre line only to find out that you renamed a built-in container for no good reason.

Yes, I suppose that's also true.

I approve of this. Don't listen to that other guy. This should be standard.

One addition though:

    Cocktionary = HashMap

"Dictionary" never really made sense.

Because the primitive is called Hash

    my %hash = ();
    Hash.new

So naturally people talk of Hashes etc. I understand where you're coming from, but it's really not very important, and it would be more confusing to talk of Hash Tables as learners would naturally look for HashTable in the stdlib.

That was the question: why the class is named Hash instead of HashMap or Dictionary? Was it done intentionally, or it is just an accident because someone did not know English very well?

I agree Map or Dictionary would have been fine too, but it's so widely used it needs to be easy to type so two words is not great (HashMap). However I suspect it was just named that way following perl (written by an english speaker). Obviously it's far to late to change it now and I can't say it bothers me or most Ruby users. It's something you get used to very quickly.

So do what python did: dict

Though even HashMap isn't bad because typing is a solved problem - with auto completion and touch typing two words really aren't an issue in my mind.

People get used to living with all kinds of things, but that doesn't make them any better. Yes I'm aware that this applies equally to my typing comment as to you having got used to hash.

> why the class is named Hash instead of HashMap

Why in golang is a function denoted by func instead of function?

I'd guess it's because programmers prefer fewer keystrokes as long as the term remains sufficiently mnemonic.

The name 'func' doesn't collide with anything else though. It is an entirely more reasonable abbreviation.

It's because Larry Wall wanted something shorter than associative arrays.

* http://www.nntp.perl.org/group/perl.perl6.language/2007/05/m...

* http://www.nntp.perl.org/group/perl.perl6.language/2007/06/m...