Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

JavaScript: The Curious Case of null >= 0

blog.campvanilla.com

Post reply on HN
Print view View original

51–60 of 152 posts

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

#51

Post by moomin »

guitarbill wrote: post #31
mrgriffin wrote: post #18

Earlier quoted context omitted.

I find this behavior surprising: >>> d = {0: "int"} >>> d[False] = "bool" >>> d {0: 'bool'} >>> nan = float('nan') >>> d[nan] = 0 >>> d[nan] = 1 >>> d {0: 'bool', nan: 0, nan: 1} Yes, yes, it's because issubclass(bool, int) == True, and nan != nan, but weird. And if we include Python 2 you get the truly ridiculous: >>> dict() >> dict >> 0 >> 0 To compare e.g. a dictionary and set we compare the _names_ of the types!…

The `nan` thing is actually because `float('nan')` can (and does) return a new object (well, with a different ID) each time. So it's like going `d[object()] = 'a'; d[object()] = 'b'` and not retaining the objects for lookup. > Personally I'd just make any comparison involving different types an error As you point out, this is what Python 3 did for `None`. But it's been idiomatic to have 0 = False when languages didn'…

My favourite of these is Haskell

> "" = [] True

Which makes perfect sense if you know any Haskell, but looks like a JavaScript wat if you don't.

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

#52

Post by schindlabua »

microcolonel wrote: post #39
deburo wrote: post #36

Earlier quoted context omitted.

But the code using twisted features is hard to maintain afterward. You will have to put comments around them just to be sure the next guy (it might even be the author himself) doesn't waste its time understanding what the hell the code is doing.

> But the code using twisted features is hard to maintain afterward. let a = 0; for (const record of records) a += record.bool; What's so bad about this? (aside from mutable accumulator, but that can be restricted to one scope). The pattern is basically directly lifted from C, where there's thankfully no such thing as a boolean type. If anything, the solution is to fold Boolean and null into Number to begin with. > Y…

To be fair, I'd trade that for

    a += record.bool ? 1 : 0;
if I can have less awkward type coercions in return in a heartbeat.

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

#53

Post by twiss »

alangpierce wrote: post #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 `…

> Also worth noting that it's not always true that `a >= b` means `!(a = null` and `'a' For anyone wondering why (like me), it's because +'a' returns NaN, and comparisons with NaN always return false (NaN = 0 and NaN === NaN are all false).

Specifically, the Abstract Relational Comparison algorithm for 'a' When neither argument is NaN, what the author wrote is true and a >= b === !(a [1]: http://www.ecma-international.org/ecma-262/8.0/index.html#se...

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

#54

Post by fenomas »

lisper wrote: post #44
justinpombrio wrote: post #35

Earlier quoted context omitted.

Let me agree with you but then turn that on its head. You've argued that having `null >= 0` is the best that JS could do while having a coercion-based semantics. And I agree: this confusing behavior may be the best you can possibly do with a coercion-based semantics. And it's not just this example, either. JavaScript is filled with gotchas, and a lot of them have to do with automatic coercion. For example, did you kn…

> having `null >= 0` is the best that JS could do while having a coercion-based semantics. And I agree Well, I disagree. You have to add a third condition for this to be the best you can do, and that is that the boolean type has to be two-valued. But that is not a given. Just as numerical types can include infinities and NaNs, a boolean type could include a third value that is neither true nor false. The IF statement…

Are you seriously suggesting that, widgety though JS's implicit type conversions might be, if its booleans had three values then things would be better?

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

#55

Post by lisper »

fenomas wrote: post #54
lisper wrote: post #44

Earlier quoted context omitted.

> having `null >= 0` is the best that JS could do while having a coercion-based semantics. And I agree Well, I disagree. You have to add a third condition for this to be the best you can do, and that is that the boolean type has to be two-valued. But that is not a given. Just as numerical types can include infinities and NaNs, a boolean type could include a third value that is neither true nor false. The IF statement…

Are you seriously suggesting that, widgety though JS's implicit type conversions might be, if its booleans had three values then things would be better?

Yes. Why would you doubt it? (i.e. why would you doubt that I'm seriously suggesting it, not why would you doubt that what I am suggesting has merit)

(Oh, and BTW, before you completely dismiss the idea that my suggestion might have merit, you might want to look me up. I didn't just fall off the turnip truck.)

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

#56

Post by roberttod »

I wish in JavaScript that inequality operators would always return false if either side of the operator needed coercion, at least then this sort of scenario would be predictable (and a little more JavaScripty than throwing an error).

As it stands, it's bad practice to rely on this sort of edge case in your code. If you know that one of the variables can be null, always handle that case before doing the comparison.

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

#57

Post by 567arlo »

This being a result of JavaScript's weapons grade weak-typing, I've always wondered of what benefit weak typing actually brings, once dynamic typing is assumed, over strong typing as in python/Ruby. Or at least stronger typing. Reasonable coercion from 11434 -> "11434" is one thing, but why not throw an exception when anything more ambiguous is encountered? It would seem even for an absolute newcomer to programming, or someone experienced who wants to rapidly prototype, the bugs resulting from this hidden coercion complexity outweigh any gains in productivity. Especially considering the alternative is simply a set of special unambiguous casting functions that could be easily looked up.

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

#59

Post by mikebenfield »

alangpierce wrote: post #21
zzalpha wrote: post #6

Earlier quoted context omitted.

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 practi…

> I really wish the industry settled on terms for this stuff I've pretty consistently heard "strong typing" to mean that the language avoids coercing between types, and "static typing" to mean that types are known at compile time. So JS and Python are both dynamic typed, but Python is (more) strongly typed and JS is (more) weakly typed. https://stackoverflow.com/questions/2690544/what-is-the-diff...

Yes, I've always understood this to be the correct terminology, but unfortunately in informal discussion among non-academically inclined software people, people use the terms wrong more often than they use them right. You get lots of people saying C is strongly typed (it certainly is not) and something like Scheme is weakly typed (it certainly is not).

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

#60

Post by nebulous1 »

roberttod wrote: post #56

I wish in JavaScript that inequality operators would always return false if either side of the operator needed coercion, at least then this sort of scenario would be predictable (and a little more JavaScripty than throwing an error). As it stands, it's bad practice to rely on this sort of edge case in your code. If you know that one of the variables can be null, always handle that case before doing the comparison.

It does. https://developer.mozilla.org/en-US/docs/Web/JavaScript/Equa...
Post reply on HN