Live data from Hacker News

JavaScript: The Curious Case of null >= 0

blog.campvanilla.com

11–20 of 152 posts

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

#11

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.

Okay.

Find an equivalently surprising example in... Let's use the other poster's choice, python.

I'll wait.

Edit: didn't have to wait long, way to go Python! Maybe I'll just claim it probably has fewer of these types of bizarre idiosyncrasies? I hope it has fewer...

I'm always baffled by JavaScript apologists... Look, your baby is ugly. We know it's ugly. You know it's ugly. But if we point out the problems, hey, maybe the ECMA will update the language to fix some of the issues.

Meanwhile, being aware of them is often important in order to build correct, secure code.

And they're just entertaining.

So chill. Let's all laugh at how ugly JS is on a Saturday morning and enjoy ourselves a bit. Because when it comes to the JS ecosystem, if we can't laugh, we'd probably be crying...

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

#12
post #7
post #5

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

It makes sense when you're dealing with real numbers, which I think is what he's getting at. It only falls apart when you try using the operator with other types.

Right, which is where I think the actual return value ought to be "undefined" or something. Or an error. But I'm clearly in the minority on my thoughts of the js type system.

But then again, you can avoid having to make intertype comparisons in the first place by following reasonable guidelines. As funny as this case is, I can't imagine how I'd run into it in practice.

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

#13
post #12
post #7

Earlier quoted context omitted.

It makes sense when you're dealing with real numbers, which I think is what he's getting at. It only falls apart when you try using the operator with other types.

Right, which is where I think the actual return value ought to be "undefined" or something. Or an error. But I'm clearly in the minority on my thoughts of the js type system. But then again, you can avoid having to make intertype comparisons in the first place by following reasonable guidelines. As funny as this case is, I can't imagine how I'd run into it in practice.

[deleted]

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

#14

Dynamic typing is a nightmare.

It's not so much dynamic typing, but a lack of typing. Dynamic typing means that type checks are made at runtime.

e.g. in Ruby:

    irb> nil >= 0
    NoMethodError: undefined method `>=' for nil:NilClass
and Python 3:

    >>> None >= 0
    TypeError: '>=' not supported between instances of 'NoneType' and 'int'
Obviously JS (and Python 2!) get this wrong, but to be fair JS was designed in the 90s.

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

#17

In a game of code golf, or something where you purposely make your code as hard to read as possible, I can imagine doing something like `if (!(x>0) && !(x==0) && (x>=0))` instead of doing `if(x===null)`.

Not as hard, it's as short as possible, i.e. a keystroke is stroke.

The hard to read is a pleasant side effect.

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

#18
post #11

Earlier quoted context omitted.

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.

Okay. Find an equivalently surprising example in... Let's use the other poster's choice, python. I'll wait. Edit: didn't have to wait long, way to go Python! Maybe I'll just claim it probably has fewer of these types of bizarre idiosyncrasies? I hope it has fewer... I'm always baffled by JavaScript apologists... Look, your baby is ugly. We know it's ugly. You know it's ugly. But if we point out the problems, hey, may…

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! Except complex numbers, because they don't have an ordering. I actually have come across this as a bug in production.

Personally I'd just make any comparison involving different types an error. That probably interacts poorly with subtyping, but it's a price I'm willing to pay.

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

#19
post #5

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

Both the > and >= make sense. Having a >= b !(b > a) ensures consistency (though it requires your set is at least weakly ordered, partial ordering is not enough, and NaNs break everything as usual...) This time IMO it's really the == that's broken. Given that it's really lenient with implicit conversions anyway, it should also apply ToNumeric to null, returning 0==0 which is, of course, true. If you want strict equality you'd use === as usual.

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

#20
post #11

Earlier quoted context omitted.

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.

Okay. Find an equivalently surprising example in... Let's use the other poster's choice, python. I'll wait. Edit: didn't have to wait long, way to go Python! Maybe I'll just claim it probably has fewer of these types of bizarre idiosyncrasies? I hope it has fewer... I'm always baffled by JavaScript apologists... Look, your baby is ugly. We know it's ugly. You know it's ugly. But if we point out the problems, hey, may…

I gave a talk on Python idiosyncrasies a while back that you might enjoy:

https://speakerdeck.com/alangpierce/python-puzzlers

Several of the examples from that talk have equivalents in JavaScript where JavaScript does better. I think pretty much any real-world language has lots of surprises like this that you need to get used to, although I certainly admit JavaScript (particularly JS type coercion) tends to have especially surprising behavior.

Post reply on HN