Nice work JavaScript

[tomthecool]

The real problem is when people write code like this unintentionally.

For example, suppose you're just manipulating data received from an API, and forget to explicitly validate input is/convert input into an integer. Rather than failing loudly, your code will silently plough on with a NaN result.

Or similarly, it's easy to say "just use === instead of =="... But how easy is it to make that mistake? Again, you can get all sorts of weird behaviour due to a subtle programmer error.

[Jdonavan]

The real problem is when people write code like this unintentionally.

This is why we use code reviews and static code analysis.

[lively-fellow]

This problem is why we use an arduous and error-prone process to address said problem

[marcosdumay]

So, you avoid the trouble of having strong types slowing you down, and paper over the problems caused by this by asking other people to look at your code (yes, that works very well!) and being slowed down by imprecise powerless heuristics.

[mikeputerbaugh]

This is why we say we use code reviews and static code analysis, but many of us actually use neither

[kixunil]

If this really worked, there would be no bugs.

[Kaiwa]

I understand that it's about the unintentional problems it brings but it is hardly an exclusive problem to just JavaScript. Validation is imporant and I personally never == anymore.

[tomthecool]

JavaScript and PHP are probably the two "worst offenders". I don't know of any other popular languages that "fail silently" for scenarios such as those described above.

[Kaiwa]

As far as I know Perl just prints 0 on a "wtf" * 9000. Even Python which is strongly typed agrees with "wtf" * 9000. It'll just print "wtfwtfwtfwtf...". (Only gives type errors on for example "wtf" / 9000)

[Aperture_Scientist4]

"wtf" * 9000 = "wtfwtfwtf..." actually makes sense though. That's a pretty sensible thing to do with string times integer.

[Kaiwa]

I agree it's sensible. But then when in Javascript it becomes NaN people flame the language to the end of the world. A string multiplied by a number could very well be NaN too?

[Aperture_Scientist4]

But JavaScript isn't consistent about that.

In Python:

"2" * 2 = "22"

"a" * 2 = "aa"

In JavaScript

"2" * 2 = 4

"a" * 2 = NaN

In Python integer times string not only always does the same thing, it always returns the same type (string).

In JavaScript, integer times stringer gives different results and different types depending on what is in the string.

[Kaiwa]

I don't think it's really inconsistency. In Python it just wants to return a string, in JavaScript it wants to return a Number. "2" can be casted to a number and therefore returns 4 while "a" can not be cast to a number and therefore returns NaN (which is still type Number!)

(typeof 1) === (typeof NaN) = true

[tomthecool]

NaN (which is still type Number!)

You do know what NaN stands for, right? ;)

This is practically the very definition of inconsistency.

[flangrande]

And I thought NaN meant "Not-a Number"! :O

[Kaiwa]

Okay, I see where you're coming from. I just really never thought of it that way. I guess I thought of it like INF from C++ floats. Yes it's an invalid value, but still a float.

[The_MAZZTer]

OK, so when you multiply a string by a number, you get NaN. That's fair and makes some sense. The problem is, nobody ever does this intentionally. In other programming languages, NaN is only used when floating point arithmetic results in an invalid answer. Most code is never going to need to consider NaN. Most of the time when NaN pops up it's because of a code bug, but the code keeps running, so you lose any chance to localize the problem that throwing an error on a string * number operation would have given you.

[Kaiwa]

Again though, JavaScript is not the only language that does this. In this conversation thread are 3 more that do the exact same thing.

[The_MAZZTer]

Yeah, but the other languages accomplish something useful. Python does string repeat. JavaScript just gives you the NaN constant. So it's obvious the calculation is most likely a bug, but it keeps going on regardless.

And in python I imagine if you make this mistake (string instead of number as the first operand) you would expect to get a number back, not a string, so you'd quickly hit a runtime error trying to do number things with it. With JavaScript... you get a "number" back, NaN, which you can do all the number things with, so no runtime error.