JS gets even weirder when you include all the comparison operators.

https://jsfiddle.net/5Yzs6/17/

Did you know undefined is equal to undefined, but not <= undefined or >= undefined?

Or that two instances of the same object/array are not equal (e.g. [-1] != [-1]), but are both <= and >= each other?

Or that /.*/ is non-comparable (only != is true) to all numbers, but greater than [-0.5] and "-0.5", and less than [0] and "0"?

Most of the examples you point out make sense if you know that using greater than or less than casts the value to a number. >= and <= always cast their parameters to numbers while == only does if either side is already a number.

If you define "make sense" as "having an explanation not rooted in the supernatural", then yes.

By that definition, Brainf*ck[1] also makes sense.

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

What a clusterfuck.

And yet, people say Brendan Eich doesn't believe in equality!

> Moral of the story: Always use 3 equals unless you have a good reason to use 2.

  NaN === Nan  // => false
  [] === []    // => false
  {} === {}    // => false
  [1] === [1]  // => false
  [0] === [0]  // => false

I guess i never see the gains in the triple vs double equal sign wars.

None of those are true when using `==` either.

The NaN example comes directly from IEEE754

The others are based on the fact that the two sides are not referring to the same object. C "equivalents" of your examples:

    int x[0], y[0]; x == y; // false
    typedef struct {} empty_t; empty_t *x, *y; x == y; // false
    int x[] = { 1 }, y[] = { 1 }; x == y; // false
    int x[] = { 0 }, y[] = { 0 }; x == y; // false

[] and {} create new objects. === always compares by identity, which isn't a unique feature. It's equivalent to Java's ==, and two different objects aren't ever equal to each other. === is equivalent to Python's `is`, and you'll get false from `[] is []` in Python for example.

Those non equations are perfectly reasonable.

One array or object does not equal another, different one.

There are definitely gains - I strongly suggest following the 'moral' of the story.

At least the === paradigm is fairly consistent and mostly rational.

This notion of equality would make pattern matching on empty lists or objects impossible in languages such as Erlang or Haskell. Perhaps it makes sense with the knowledge that each array is a different object, but it is highly counterintuitive.

Do any of those return true if you use double equals? The distinction only really comes up when you have to different types on either side and then It will coerce one of the types to match the other.

That is correct. The canonical example is string-numeric coercion:

    "0" == 0 && "0" !== 0

You're comparing two expressions of the same type so it doesn't matter whether you use == or ===, but == can return true even if the expressions are of different types.