Put aside its weird exceptions in specification(Which is hard to find), such as
The more frustrating thing is that the result of
isNaN consumes my thinking energy, though a tiny bit every time, before I established an intuition about it.(Which requires quite a bit of efforts)
But man, we are lazy. And this design does not follow the human instinct.
isNaN(n) false # THOUGHTS: # The result of isNaN(n) is false, what does it mean? # it means n is not a number is false. # OK, let me think for a while.. # So, I assume it is a number(with hesitation) type(n) == int False # THOUGHTS: # type(n) == int returns False, what does it mean? # So it tells us that `the type of n equals int` is false # So the type of n is not equal to int! # I think n is not a int.
I think human beings have a tendency to assume everything is True at first.
Thus multiple negative levels on statement will increase our recognition cost.
On this sight of view, the design of
isNaN is a bad one, and
isN(isNumber) is a better solution for human understanding.
But as a sceptic, I'm wondering there may have some background story about this design, to achieving a important functionality, the author chosen this design as a tradeoff? Was there a good reason, or is this just a design deficiency(in the sense of human friendly)?