JavaScript

+ is overloaded for string concatenation, but - isn't so the interpreter coerces the "11" into a number first.

yup
we have a concept for that in brazilian portuguese. it's called "gambiarra".
Thanks for the explanation

        ('b' + 'a' + + 'a' + 'a').toLowerCase()

Returns "banana"

wut
- I'm guessing the + + in the middle returns NaN
- 'a' + +
  This part is the same as writing 'a'++ and that returns "NaN" (short for "not a number") since you can't increment a character, but this return type is a string, so the interpreter just concatenates it with the other letters: baNaNa. Then that string is converted to lower case to give the final result, "banana".

So "11" + 1 - 1 == "11" - 1 + 1 is false? ;-;

That's easily explained by + being the concatenation operator though. Those are two different operations with the same symbol

Just use typescript anyway lol

I thank god every day people who make these comics are too stupid to open gcc's sha1.c because they'd see shit like:

    
#define M(I) ( tm =   x[I&0x0f] ^ x[(I-14)&0x0f] \
            ^ x[(I-8)&0x0f] ^ x[(I-3)&0x0f] \
           , (x[I&0x0f] = rol(tm, 1)) )

#define R(A,B,C,D,E,F,K,M)  do { E += rol( A, 5 )     \
                      + F( B, C, D )  \
                      + K	      \
                      + M;	      \
                 B = rol( B, 30 );    \
                   } while(0)

      R( a, b, c, d, e, F1, K1, x[ 0] );
      R( e, a, b, c, d, F1, K1, x[ 1] );
      R( d, e, a, b, c, F1, K1, x[ 2] );
      R( c, d, e, a, b, F1, K1, x[ 3] );
      R( b, c, d, e, a, F1, K1, x[ 4] );
      R( a, b, c, d, e, F1, K1, x[ 5] );
      R( e, a, b, c, d, F1, K1, x[ 6] );
      R( d, e, a, b, c, F1, K1, x[ 7] );
      R( c, d, e, a, b, F1, K1, x[ 8] );
      R( b, c, d, e, a, F1, K1, x[ 9] );
      R( a, b, c, d, e, F1, K1, x[10] );
      R( e, a, b, c, d, F1, K1, x[11] );
      R( d, e, a, b, c, F1, K1, x[12] );
      R( c, d, e, a, b, F1, K1, x[13] );
      R( b, c, d, e, a, F1, K1, x[14] );
      R( a, b, c, d, e, F1, K1, x[15] );
      R( dee, dee, dee, baa, dee, F1, K1, x[16] );
      R( bee, do, do, dee, baa, F1, K1, x[17] );
      R( dee, bee, do, dee, dee, F1, K1, x[18] );
      R( dee, dee, dee, ba, dee, F1, K1, x[19] );
      R( d, a, y, d, o, F1, K1, x[20] );

And think, yeah this is real programming. Remember the difference between being smart and incredibly stupid is what language you write it in. Using seemingly nonsensical coercion and operator overloaded is cringe, making your own nonsensical coercion and operator overloads is based.

That's why you should never subtract things from 0x5F3759DF in any language other than C.

sha1.c
Yeah, a hash function actually just looks like that intrinsically, though. Being impenetrable is the point.
- There are plenty of sha1 implementations that are more readable and sensible and less readable and sensible. This portion is simply an manually unrolled loop (lmao these gcc nerds haven't even heard of Gentoo) of the hash chunk computation rounds. Hash functions aren't "impenetrable" they're just math. You can write math programmatically in a way that explains the math.
  The point of this post is actually things like x[(I-3)&0x0f]. It's entirely the same concept as coercion to manipulate index values this way. What's funny is that void pointer math, function pointer math, void pointers and function pointers in general are typically seen as "beyond the pale" for whatever reason.
  Beyond that if you know C you know why this is written this way with the parens. It's because C has fucked up order of operations. For example a + b == 7 is literally "does adding a + b equal 7", but if you write a & b == 7 you would think it means "does a AND b equal 7", but you'd be wrong. It actually means does b equal 7 AND a.
  Furthermore a & (b ==7) makes no sense because b == 7 is a boolean value. Bitwise ANDing a boolean value should not work because the width of the boolean is 1 bit and the width of the int is 8 bits. ANDing should fail because there's 7 void bits between the two types. However the standard coerces booleans in these cases to fit the full width, coercing the void bits to 0's to make bitwise ANDing make sense.
  Beyond that asking what the memory size of a variable in C is a fools errand because the real answer is "it depends" and "it also depends if someone decided to ignore what it typically depends on (compiler and platform) with some preprocessor fun". Remember how I said "void pointers" are beyond the pale? Yeah the typical "why" of that is because they don't have a known size, but remember the size of something for C is "it depends". 🤷
  Almost every language has idiosyncratic stuff like this, but some let you make up your own shit on top of that. These kinda low hanging fruit jokes are just people virtue signaling their nerddom (JS bad am rite guis, use a real language like C), when in reality this stuff is everywhere in imperative languages and typically doesn't matter too much in practice. This isn't even getting into idiosyncracies based on how computers understand numbers which is what subtracting from 0x5F3759DF (fast inverse square root) references.

JavaScript is very easy to understand