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.

I propose we call Javascript a "quantum mechanical programming language" because the value of a variable can never be determined if it is compared to another by observing it directly.

I can just hear it now: "It helps to think of variable conversions in comparisons as a 'cloud' of value probabilities instead of a discrete value"

Yes. For X and Y being of the same type, defining the < operator should be enough to derive all other operators:

Define X < Y, and then derive the rest:

X > Y : X < Y

X == Y: !(X < Y) && !(Y > X)

X != Y: !(X == Y)

X >= Y: !(X < Y)

X <= Y: !(Y < X)

That's why it's the only operator that needs to be defined for std::map/set (which are rb-trees) in C++

Now, if X and Y aren't the same type, the only thing you can expect to get out of the system is a cronenberg.

> X == Y: !(X < Y) && !(Y > X)

Only for totally ordered sets [1]. Floating-point numbers, for example, are not totally ordered, because !(NaN == NaN).

[1] https://en.wikipedia.org/wiki/Total_order

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.

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.