Stupid Languages

In JavaScript, every function is varadic. The problem is one of contract, not language. Passing varadic functions to higher-order functions without checking whether the types are compatible will cause a problem in <i>every such language</i>.<p>The problem is parseInt, not map. Consider:<p><pre><code> // using lodash.js (http://lodash.com/) _.mixin({ args: function () { return _.toArray(arguments); } }) ['10','10','10','10'].map(_.compose(parseInt, _.first, _.args)); // #=&#62; [10,10,10,10]</code></pre>

&#62; But it can do things the other maps can't easily, like create an array of differences between elements, or a running total, and so on. Other languages have other solutions to those problems.<p>Lisp has some rather elegant solutions to both of those use cases. It's misleading to say that Javascript's 'map' is more powerful just because it tries to cram two or three distinct use cases into one.<p>It's not like Javascript even uses the Lisp definition of 'map' (which is <i>not</i> what most languages use for map - they use Lisp's 'mapcar').

This example clearly violates the principle of least surprise, but it doesn't necessarily mean that the language it comes from is bad. Rather, the <i>code</i> it's used in is.

This is more of a case of a stupid library than stupid language.<p>And whether it's a stupid library is even debatable. map() has gained a more popular understanding from functional programming these days but it was probably not so when this Javascript map() function was added.

One important characteristic of the map function is that it can be used reversibly. For example, (partial map inc) is inverted by (partial map dec). If I want to map over a collection by a function that takes the entire collection as an argument I'd rather use some function other then map to avoid confusion.

To me, the bigger issue is that the unused 3rd argument is silently ignored without error or warning.

&#62; They want to know if function arguments are call by value or call by reference (neither).<p>My knowledge of Python is limited, but I was under the impression that it is call by value just like everything else (where Python's notion of value is "pointer to something"). Am I missing something?

I think one of the reasons for the third argument (the array itself) is to permit chaining. Consider this:<p><pre><code> var publishedPosts = posts.filter(function(post){ return post.published }) var intervals = publishedPosts.map(function(post, i){ var next = publishedPosts[i+1] return post.date - (next &#38;&#38; next.date || 0) }) </code></pre> With the array reference you don't need an intermediate var:<p><pre><code> var intervals = posts.filter(function(post){ return post.published }).map(function(post, i, arr){ var next = arr[i+1] return post.date - (next &#38;&#38; next.date || 0) })</code></pre>

For another quick 'WAT' talk, see Gary Bernhardt from CodeMash 2012.<p><a href="https://www.destroyallsoftware.com/talks/wat" rel="nofollow">https://www.destroyallsoftware.com/talks/wat</a>

Base 1 does make sense!<p>0 = 0<p>00 = 1<p>000 = 2<p>0000 = 3<p>etc