Hacker News Reader

Hacker News

Comment by granttimmerman | Hacker News Reader

Full thread

granttimmerman

> xs = ['10', '10', '10']

> xs.map(parseInt)

[10, NaN, 2]

Javascript is beautiful.

View on HN

There are so many good WTFs in JS, but this is not one. parseInt expects 2 arguments and Array.prototype.map provides 3 to the callback it is given. Both of these facts are very well documented and known.

    var mappableParseInt = function(str){
        return parseInt(str, 10);
    };

    ['10', '10', '10'].map(mappableParseInt);

I'd suspect this snippet is more a snipe at people who don't know JS very well and expect parseInt to be base-10 only.

You could say it's a snipe at the weak type system that Javascript has.

I dunno, as someone without much experience with Javascript, it is a little odd that arrays return the index alongside the value by default.

arrays don't do that, but map() does. Normally in js you can just ignore arguments you don't care about, but it does lead to surprises like this one.

It has little to do with the type system. Variadic arguments can be typed given a type system that supports it.

I don't think `parseInt` accepting an optional second argument is the surprising behavior there. The real WTF is `map` passing more than one argument, and the loose behavior of JS regarding argument passing overall.

It's only WTF because it's not the same as other implementations of map. Once you can internalize the map implementation, it's no longer WTF & actually makes sense.

That's the weird part. Why does array provide three arguments? But I agree, that's something you can learn. I guess.

But it's WTF anyway. I have a function that takes either one or two arguments, I provide three, and everyone seems to be OK with that.

Well that decision is pretty necessary when you realize that JS has no syntax to indicate a function is variadic (we use the arguments magic variable, but use of it does not necessarily indicate that a function is variadic) and that implementation supplied functions are not required to have their arity exposed via Function.prototype.length (http://es5.github.io/#x15.3.5.1).

There's no way to know, even at run-time, whether a function is being called with too few or too many arguments, since that's equivalent to the halting problem. So the sensible alternative is just to default everything to undefined, and silently ignore extraneous arguments.

But yes, if JS was strict with how it handled argument definition lists and had support for indicating infinite arity, I'd agree, this would be a WTF, or at least strange. But I think it makes a lot of sense, all things considered.

It makes sense but it still strongly violates the principle of least surprise. No other language I know of does this, nor do I think this would be a particularly desirable feature.

So much for abstraction if you need to understand the implementation of every function you'll every use in JavaScript.

> understand the implementation of every function

Rather: remember three things that make up the majority of Array iterators' callback functions' signatures:

Element, Index, Array.

Shared by: .map, .every, .forEach, .filter, and probably some that I am forgetting. The exception I think is just .reduce[Right], which by definition requires its previous return value, so you have (retVal, elem, i, arr).

Quite literally, if you remember .map callback, you remember .every callback :)

Javascript deserves shtick for its truly bad parts (with, arguments, ...) and some missing parts, but .map and its friends aren't it.

Alternatively, if a function expects two arguments, the language could take exception at the fact that three were handed in. Quietly accepting arbitrary arguments could be considered breaking contract. It does have a wtf-ey whiff.

with a function named "parseInt" anyone would expect the inputs as base 10.. otherwise this shoud be called "parseHex" for 15 or at least "parseBytes(input, base)"

The programmers are not the ones to blame on that.. this is really a bad contract between the language and the programmer

Its the equivalent of a function named "getStone()" to return you a " Paper{} " :)

"int" doesn't imply anything about the base.

It does for human beings. We use base-10 for basically everything. This is true even for most programmers in most situations. Human beings aren't computers, and we aren't abstract math processing units who by default consider numbers abstracted (e.g. as elements of Rings). This goes double for string representations of numbers--in the majority of cases a number represented by a string is a number meant for human consumption in a normal human context; not some machine running in base-2 (or -8 or -16). It is certainly reasonable to expect "parseInt" to parse an integer out of a string in base-10 by default, and entirely unreasonable to expect to be required to provide a base as anything except an optional argument, and certainly it is unreasonable to expect that that second optional argument is treated as not optional in a composition operation.

> It is certainly reasonable to expect "parseInt" to parse an integer out of a string in base-10 by default

It does.

> and entirely unreasonable to expect to be required to provide a base as anything except an optional argument

It is optional.

> and certainly it is unreasonable to expect that that second optional argument is treated as not optional in a composition operation

I don't understand what you're saying here. It's never treated as required, it's just map supplies a parameter in that position, so it get's used. That's how optional parameters work.

The wat (if there is one) is that map provides extra arguments.

>> ...parse an integer out of a string in base-10 by default

> It does.

Not quite: in some browsers (IE), a string starting with '0' gets interpreted as octal. So parseInt('041') === 33 in IE.

Guess how I found out about that.

I agree with your conclusions. However, the poster I was responding to was suggesting that the category of "int" necessarily excludes non-decimal representations in the same sense that the category of "stone" excludes "paper".

I think in this case it's not parseInt that's at fault, it's the fact that map optionally passes additional arguments.

A bit less annoying with ES6:

  >>> ['10', '10', '10'].map(x => parseInt(x, 10))
  [10, 10, 10]

It's due to parseInt having an optional second parameter, the radix, and map passing the index as the second paramater, hence:

  xs = [
    parseInt('10', 0),
    parseInt('10', 1),
    parseInt('10', 2)
  ]

And since 0 is falsy we get 10 for base 0.

Which is odd. I wonder why they checked for falsiness and not the argument being undefined.

It's not exactly checking for falsy values. Although all falsy values will lead to a radix of 10 being applied.

parseInt internally uses the ToInt32 abstract operation on the radix parameter. Once it has that value, it explicitly looks to see if the value is 0. If it is, it uses a radix of 10.

https://people.mozilla.org/~jorendorff/es6-draft.html#sec-pa...

Edit: I hope that doesn't come off as pedantic. My point wasn't to disagree as much as it was to just add some further explanation.

This is HN, there's no such thing as being pedantic. :)

Or rather, there is but it's thoroughly welcome.

Although keep in mind that excessive pedantry is frowned upon.

It's not optional if you lint your code :)

Thank you. I read many comments to find an explanation.

Just like with any language, as long as you read the docs of the stuff you use, you don't get this problem (you might get others with automatic type conversion and missing arguments like the speaker says, but not this)... this is just stupid.

Try this:

int subtract(int b, int a) { return a - b; }

int test = subtract(5, 3); // != 2, just read the damn docs

Oh, C sucks now !

The talk is quite fun and interesting to watch though.

And the end is pretty cool.

The thing is, good language design means you don't have to read the docs.

The number one thing taught at user interaction / usabillity courses is that users don't read the documentation. Or skim it and go directly to one or two parts they want to check (Sure, some bizarro outliers do read it all).

Besides, a golden rule from the UNIX era is the "principle of least surprise". Don't define stupid behavior as default, as in this case (both for parseInt and Map).

Both behaviors make sense in isolation. It's not always so easy.

Juggling these interactions is exactly what makes good language design so difficult and time consuming. In the talk, I mention JS' ten-day design time several times for exactly this reason. Language design is hard and ten days just isn't enough time to carefully consider how everything will fit together. Try to imagine a programmer, even a brilliant one, noticing the map/parseInt interaction ten days after starting to learn JS, especially in 1995 when these high level languages were far less common. Seems unlikely!

Arguably the issue is not with the behavior but rather a deeper design problem within the language itself. Notice that in Obj-C no one would ever get confused regarding the second parameter of parseInt:withRadix:.

> good language design means you don't have to read the docs

Let's assume JavaScript is a poorly-designed language, and Clojure is a well-designed language. In the first month of language use, the user of Clojure will have looked at the docs many more times.

But the user of javascript will have more bugs.

That's because:

1) Clojure has a larger API -- Javascript doesn't have 1/10 that.

2) Javascript has a familiar (to many) Algol-derrived braced syntax and lots of common C/C++/Java/etc keywords. Clojure is only familiar to Lisp/Scheme users.

If those things were equal, Clojure would win the "don't have to look caveats up" contest, because its design is more coherent, and doesn't give you unexpected results and undefined behavior like Javascript does.

Obviously, you somehow you need to first know that "parseInt" is called "parseInt()" and not "atoi()" for example. But I wasn't implying never reading anything, including function reference. Just being able to code without needing to study and/or memorize lots of arcane edge cases.

By "this problem" do you mean "the this problem"?

And by "this is just stupid" do you mean "this === just stupid"?

If you think that's bad, you should see this!

I just wrote this line about two hours ago and my tests weren't thorough enough to catch the bug it introduced. Just when I thought I knew JavaScript. Thanks for saving me some time.

I'm sure you know this by now but you can keep the syntax and use Number instead

xs.parseInt(Number)

I think xs.map(Math.floor) takes the cake if I recall speed tests properly

Always give the base to parseInt in Javascript.

Always. The moment you don't, all kinds of bugs follow.

I have to go cry now at the number of times this has bitten me.

Are there any other problems aside from octal?

Not just javascript, a whole bunch of language's parseInt implementation will interpret the base from a leading zero etc.

Always remember - it's not a language but a loosely parsable texty thing.

A useful function

    function overValues(f) { return function(x) { return f(x); } }

Then you can do

    ['10', '10', '10'].map(overValues(parseInt));

However, usually you're going to want to do the equivalent of this

    ['0101', '032'].map(function(s) { return parseInt(s, 10); })

Because Javascript interprets a leading zero as an indicator of base.

I think you accidentally a word...

> as an indicator of base.

As an indicator of base 8 (octal).

You need:

['10', '10', '10'].map(Number);

  var xs = ['10', '10', '10'];
  xs.map(function (str) {
    return parseInt(str, 10);
  });
  
  > [10, 10, 10]

Fixed that for you. Why?

  map callback params: (value, index, originalArray)
  parseInt params: (string, radix)

Your code is passing the map array index to parseInt's radix.

Where people use parseInt, they usually should use Number: ['10', '10', '10'].map(Number); // [10, 10, 10]

;)

Reply on news.ycombinator.com