<i>This raises some interesting questions. E.g. why this does not work: [1,2,3].map({2:4}) (in JavaScript)?</i><p>It seems obvious to me why, but the author's question made me realize that I couldn't immediately express <i>why</i> that's not possible. The glib answer is that it doesn't make any sense, but that's not very useful. I think what is more fundamental is that JavaScript, and most other languages, have separate concepts of data and code. A dictionary is data, a function is code.<p>Forgive me that I don't know JavaScript, so I'm going to switch to pseudo-Python for my examples.<p><pre><code> def f1(n):
if (n == 2): return 4
return null
f2 = {2:4}
</code></pre>
I said pseudo-Python because in real Python, when I query a dictionary for a value that is not there, it throws an exception. In my pseudo-Python, I'm going to assume that it just returns null. If we assume that, then f1 and f2 can be used to get the same result, even thought they have to called in different ways:<p><pre><code> res1 = f1(2)
res2 = f2[2]
</code></pre>
Both res1 and res2 will have the value 2. In that way, dictionaries can be seen as a kind of function. I'm going to posit that the main reason we don't treat them the same in most languages is efficiency and simplicity. Dictionaries can only represent a limited number of functions - functions with integral and finite inputs. Even so, it will often be quicker to write a closed-form function than to write the full dictionary for a task. For example, if you want an entity that given an <i>N</i> between 1 and 1000 it will return to you the sum of all numbers from 1 to <i>N</i>, it is much easier to just say that this quantity will be <i>N</i>(<i>N</i> + 1) / 2 than it is to exhaustively list all options from 1 to 1000. (Of course, the dictionary could not represent if we wanted something that could handle arbitrarily large <i>N</i>.)<p>Going back to the author's question, if we assume that question was asked with this pseudo-Python, and we could query dictionaries in the same way as functions, then the answer would be [null, 4, null]. Is that useful? I'm not sure. But perhaps there is value in unifying how we call functions and how we query a dictionary. That is, if I give it a value, and it returns a value, it should be invisible to me whether it's a function or a dictionary. I know I can achieve this in C++ with operator overloading, and I think Python gives mechanisms for me to define classes that can behave like this, but there is still a fundamental difference in the language.<p>Lisps, of course, don't have the data-code divide, so querying a data structure and calling a function can look the same. But it's interesting to note that other languages don't have to make the two look different, but they do.<p>Finally, <i>[2,3] + [1,4] gives a string "2,31,4" in JavaScript, but shouldn't this produce [2,3,1,4] (which is equivalent to Array.concat([2,3], [1,4]))?</i><p>In most languages I'm familiar with, you will <i>not</i> get a string, but instead a concatenated list. I think that fact is a byproduct of the fact that JavaScript was designed for use in browsers. To the author, try exposing yourself to more languages. What you observe there is a quirk of JavaScript, not all programming languages.