Hacker News Reader

Does knowing any of this make you a better programmer? I'd say no.

Should you be using any of this in production code? No

The next programmer even if he is a really good one might not know that particular esoteric trick.

I'm not trying to vote down or anything, but what is the point? Most of it look like language design warts to me. Most of them should have thrown exceptions and errored out.

Now I'm loving the idea of static typing a lot more.

Most of it is warts and is completely useless. Sometimes things like knowing that an array is an abject are pretty important if you're writing production code.

The bit at the end (integer and float casting) is almost essential knowledge now for anyone writing JavaScript code that does anything mildly intensive.

The problem is the strong-typing/weak-typing distinction, not the static-typing/dynamic-typing distinction. For example, Python is about as strongly typed as C++ yet they're on opposite sides wrt. how dynamic their types are.

Using +x to convert things to numbers and x|0 to convert things to 32-bit integers are useful and common operations.

> Does knowing any of this make you a better programmer? I'd say no.

Yes it does, it makes sure you never do this ;P

Adding arrays sounds like something I'd totally try in JS, had I not known that it causes magic unicorn sparkles to happen)

Useful for obfuscating executable JS for security reasons.

Security through obscurity is not security. This would be easy to translate back into the original code anyway. This is also not efficient from a file size perspective which is cancer on the web.

It'd have to be something that really had to be hidden, because most of these edge cases are very very slow to run.

Why? I believe you have more sophisticated ways of obfuscating code. Those tricks seem to be easy to reverse.

Here's a slightly more entertaining version of the discrepancies/oddities found in javascript:

https://www.destroyallsoftware.com/talks/wat

A bunch of that is wrong or at least misleading.

> {} + [] > 0 (The number zero)

This is wrong, it is only true in the weird scenario that you type it into the jsconsole and don't use the result. It parses as an empty block ({}) and then an unrelated unary +[] after that. var x = {} + []; gives you a string and it is the same as var x = [] + {}.

There is more logic than it seems here:

  Unary plus:
  > always gives a number (a double: NaN is a double)
  > on array: +a -> if len>=2: NaN else +a[0] (recursively)
  > on object: NaN
  > on string: parseNumber, or NaN if that fails
  > on bool: 0 for false, 1 for true
  > on null: 0
  > on undefined: NaN

  binary plus (addition):
  > order doesn't matter except for the jsconsole pseudo-bug
  > if both sides are number or boolean, add them
  > else, toString() both sides and concat them

  boolean negate (not):
  > false for 0, false, "", null, undefined
  > true otherwise

  binary - (subtraction)
  > x-y coerces x and y to number and subtracts them.
  > Most mainstream languages that use + for string concat don't use - for some sort of string unconcat so its not too crazy.

  > typeof [] === typeof {}

  This isn't so crazy, typeof any non-primitive gives you "object".
  [] is pretty much just an object plus magic .length property,
  var x = []; x.blah = 7; console.log(x.blah) works. It doesn't work on number or bool.

https://www.destroyallsoftware.com/talks/wat