I really dislike this sort of reasoning. That its only confusing because you don't know enough. It's possible to word things in ways that are easy to learn and lead you to an understanding of the underlying mechanics.
Its confusing because NaN explicitly states not a number. Then the function explicitly states is number.
However the two are in very different contexts, yet this is not communicated when using them. It's intuitive to think of a date as a class and there for the context is implicit in isDate. I don't think this is the case for isNumber.
I think this is less about people understanding floating-point numbers more about understanding that a function starting with is implies some form of type checking.
> Its confusing because NaN explicitly states not a number. Then the function explicitly states is number.
The problem is that "Number" is the name of a JS data type, and "number" is the name of a concept, the two don't match exactly, and when you are using camel-casing for word separation, you can't distinguish the two.
The function "isNumber" checks if the thing it is applied to is a JS Number, not if it is a number.
Its confusing because NaN explicitly states not a number. Then the function explicitly states is number.
However the two are in very different contexts, yet this is not communicated when using them. It's intuitive to think of a date as a class and there for the context is implicit in isDate. I don't think this is the case for isNumber.
I think this is less about people understanding floating-point numbers more about understanding that a function starting with is implies some form of type checking.