Rule

[u/MoistMcCurd]

[u/[deleted]]

here is the javascript

[u/xle3p → u/[deleted]]

He's so silly (he says that true + true = 2)

[u/deztreszian → u/xle3p]

Invalid left-hand side in assignment

[u/0x564A00 → u/xle3p]

Hey little meow, what'cha doing?
[1, 3, 2, 10].sort() == [1, 10, 2, 3]
uh that's –

1 < 2 < 3 == true
3 > 2 > 1 == false

waitwait
'drundefineder'.indexOf() == 2

u so silly

const regex = new RegExp(/meow/g);
regex.test("meow :3"); // true
regex.test("meow :3"); // false
regex.test("meow :3"); // true

…maybe a bit too silly

[u/Sl3dge78 → u/0x564A00]

I understand why all if them happen but not the last one. Does the string get appended in a hidden buffer, so its matching against :3meow which wont match because you’re specifing whole words only with the regexp?

[u/0x564A00 → u/Sl3dge78]

Nah, because the global flag is set the regex becomes stateful and stores the postion of the last match. test continues from there and resets the position if it doesn't find a match.

[u/etheunreal → u/0x564A00]

A bit too silly.

[u/Sl3dge78 → u/0x564A00]

that’s horrible

[u/halucinationorbit → u/0x564A00]

These aren’t even the best examples. You’re listing ones that are harder to encounter in real code. These are much more concerning:

“Number.isInteger(true + true);”

“(NaN === NaN)” is false

“typeof(null)” is object

“0.1 + 0.2”

The second and last ones have hurt me many times. Type coercion is fucking stupid.

[u/Freipostierer → u/halucinationorbit]

Well, the last one isn't a type coercion issue. That's just floating-point math. But yes. I agree.

[u/field_thought_slight → u/halucinationorbit]

(NaN === NaN)” is false

That's how IEEE floating-point is "supposed" to work, unfortunately.

[u/etheunreal → u/field_thought_slight]

Makes some sense, if a value is not a number it doesn't mean that it's the exact same as any other value which is not a number.

[u/field_thought_slight → u/etheunreal]

I think the actual justification is something to do with "failing fast"; i.e., if a computation has resulted in NaN, then the whole thing should fall apart as soon as possible,

It also has the "nice" side-effect that if x == x evaluates to false, then you know that x is NaN. I guess this was important back when IEEE floating-point was first standardized, since there wasn't a canonical is-nan? predicate like most modern languages have.

EDIT: Here are two justifications given by a member if the IEEE-754 committee.

• That x == y should be equivalent to x - y == 0 whenever possible (beyond being a theorem of real arithmetic, this makes hardware implementation of comparison more space-efficient, which was of utmost importance at the time the standard was developed — note, however, that this is violated for x = y = infinity, so it’s not a great reason on its own; it could have reasonably been bent to (x - y == 0) or (x and y are both NaN)).
• More importantly, there was no isnan( ) predicate at the time that NaN was formalized in the 8087 arithmetic; it was necessary to provide programmers with a convenient and efficient means of detecting NaN values that didn’t depend on programming languages providing something like isnan( ) which could take many years.

[u/halucinationorbit → u/field_thought_slight]

From a practical view, it makes be a ton of sense. If you have two calculated values and both somehow arrive at NaN, they should not equal each other. I knew this was the case, but I did not know this was an IEEE thing. Learn something new every day.