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.

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.