Live data from Hacker News

JavaScript: The Curious Case of null >= 0

blog.campvanilla.com

1–10 of 152 posts

Re: JavaScript: The Curious Case of null >= 0

#2
I thought so when starting to read this article and seeing > and == cases being false. I guess, with some experience one probably has implemented such logical shortcuts as well themselves. And now I am pretty sure this is a question of backwards compatibility and not anymore easily reversible

Re: JavaScript: The Curious Case of null >= 0

#6
post #4

Dynamic typing is a nightmare.

Done right (like in python), it's not so bad.

I really wish the industry settled on terms for this stuff but alas...

The difference is python is strict about its types and doesn't do automatic coercion. So at least you get type errors at runtime and not magic implicit behaviour.

That said, even Perl did this better (less magic and surprises)... JavaScript is like a language intentionally designed to surprise the developer. Half the time I feel like it's a practical joke that someone accidentally took seriously.

Re: JavaScript: The Curious Case of null >= 0

#8

Dynamic typing is a nightmare.

Yes I can contrive examples in any language that are nightmarish. Fortunately we manage to muddle through somehow, at least those of us who have work to do in lieu of walking through trivia to prove how smart we are to other hackers.

Re: JavaScript: The Curious Case of null >= 0

#9
post #5

Did he seriously claim at the end that that made sense "mathematically"?

When the language permitted a nonsense comparison like this, the spec needs to be complex, and within the logic of the spec, yes it makes sense.

The original error was allowing a nonsense comparison. Which is greater, 10 or fish? If you permit asking this question, you'll occasionally get weird results.

Re: JavaScript: The Curious Case of null >= 0

#10
Not to defend JavaScript too much, but I think the three examples seem reasonable when viewed in the right way, and I think it's hard for JavaScript to do much better with its existing design philosophy (dynamic typing and coercion rather than runtime errors to deal with type mismatches).

>= and > are numerical operations, so both sides are interpreted as a number, and null is 0 when treated as a number. That means `null > 0` becomes `0 > 0`, which is false, and `null >= 0` becomes `0 >= 0`, which is true. In contrast, == is a much more general operation that works on numbers as well as objects, strings, and all sorts of other things, so it certainly doesn't make sense to always convert both sides to a number first. I'm certainly happy that `null == 0` is false in JavaScript, and I wouldn't want that changed to be consistent with numerical comparison (which comes up much more rarely than equality checks, at least in my code).

This type of issue isn't unique to JavaScript. In Java, if you have boxed Integers, `==` will do object identity comparison (so two different instances of the same number will compare as not equal), while `>=` etc will unbox them and do numerical comparison, which I think stems from the same issue of equality being more general than numerical comparison.

Also worth noting that it's not always true that `a >= b` means `!(a = null` and `'a' < null` are both false.

Post reply on HN