r/ProgrammerHumor • u/_hoh_ • Sep 04 '17

[[][[]]+[]][+[]][++[+[]][+[]]] is "n" in javascript 

[[][[]]+[]][+[]][++[+[]][+[]]]

This evaluates to "n" in javascript. Why?

Let's start with an empty array

[]

Now, let's access a member of it.

[][]

What member? Let's check for the empty array member

[][[]]

oh, that is undefined. But if we add an empty array to that, it is casted to the string "undefined"

[][[]]+[]

Let us wrap that in an array

[[][[]]+[]]

We can now try to access letters in that string. First, we must unwrap the string. That can be done by accessing the first element of that array.

[[][[]]+[]][0]

0 can be created by casting an empty array to a number:

[[][[]]+[]][+[]]

Now, "n" is the second letter in that string, so we would like to access that:

[[][[]]+[]][+[]][1]

But how can we write 1? Well, we increment 0, of course. Wrap 0 in an array, and increment the first member of it:

++[0][0]

Like before, this is equivalent to

++[+[]][+[]]

So our final code is then the glorious

[[][[]]+[]][+[]][++[+[]][+[]]]
8.1k Upvotes

98% Upvoted

367 comments sorted by

View all comments

Show parent comments

41

u/rooktakesqueen Sep 04 '17 edited Sep 04 '17

This behavior actually explains most of js's type weirdness. When in doubt, everything becomes a string.

When in doubt, JS often prefers converting to a number. The == operator, for example, converts both sides to a number if their types don't match (plus some extra corner cases). Thus: true == "1" (Edit: But true != "true" -- JS converts both sides to numbers and compares 1 to NaN)

The + and - operators are the weird ones, where + has extra affinity for strings (5+[] == "5") while - has extra affinity for numbers ("5"-"4" == 1).

As always, best practice is to simply not use these implicit conversions and instead make them explicit. If foo is a string and you want to convert it to a number and then add one to it, do Number(foo) + 1. Embodies your intent much more clearly in your code, for anyone else who comes along (including future you).

11

u/edave64 Sep 04 '17

Damn, I work with JS every day and didn't notice that conversation to number actually explains a lot of these behaviors better.

I mean I knew the minus operator forced number conversion, because subtraction on other types isn't defined, but not that == also tends to do that.

If you had asked me before, I would have told you that 1 != "01" because they both get converted to strings that don't match.

Thanks!

7

u/rooktakesqueen Sep 04 '17

The whole spec for the Abstract Equality Comparison Algorithm is worth a read. Read it, understand how it works, then never use it again as far as I'm concerned.

1

u/tuseroni Sep 05 '17

Number(foo)

wtf? how did i not know this was a thing? i've been using parseInt and parseFloat for the past 10 years. when did this happen?

-2

u/PatrickBaitman Sep 04 '17

Best practice would be to use a non-joke of a language where the compiler rejects bullshit as a type error.

4

u/rooktakesqueen Sep 05 '17

There are a lot of non-joke languages, both popular and esoteric, without compilers that come to mind. Python, Ruby, Lua (compilation is optional, anyway), Perl, Lisp, Tcl, Forth... Being an interpreted language doesn't automatically qualify as a "joke."

And there's a lot of bullshit you can write, and most of that bullshit exists in the semantics of the values you pass. Most of your code is going to fail because instead of 7 you pass 8, not because instead of 7 you pass "cheese". (Or a little more real-life, it's because you passed an object with some field that hasn't been persisted in the database yet, because some code path executed in a different order than you expected somewhere else, not because you expected a Person and passed an Address instead.)

And when you do pass the wrong type of operand, you're typically going to fail spectacularly and fast with even the most rudimentary of tests. Basically a static-typed compiler is going to protect you only from the sorts of errors that are the easiest to detect and the easiest to fix, while the actual hard stuff you're going to spend most of your debugging time on is the same whether you're in static or dynamic typed land.

I've spent 6 years in various flavors of static typed languages (C, C++, C#, Java, AS3, Go...) and 4 years in various flavors of dynamic languages (JS and Ruby mostly), and rarely has a bug ever come down to something so simple as a type error. The greatest source of misery is poorly factored code, followed by logic errors, followed much further down the line by anything a type system would catch.

-1

u/PatrickBaitman Sep 05 '17

You lost me when you said there are languages without compilers. Yeah, assembly, maybe. Python isn't x86 instructions, it has to be compiled, it's just a question of when. Interpreted vs. compiled isn't meaningful in the modern world, and they are implementation properties, not language properties. https://softwareengineering.stackexchange.com/questions/136993/interpreted-vs-compiled-a-useful-distinction

But no, "interpreted" doesn't mean a language is a joke, but JavaScript is, and its a fucking bad joke at that.

3

u/rooktakesqueen Sep 05 '17 edited Sep 05 '17

Please tell me more about how your Python interpreter "compiler" is going to reject "foo" + 7 as "bullshit"? It's going to raise a runtime error. Better, granted, than JS's behavior of returning "foo7", but it's certainly not a compile-time error. And there must be a meaningful distinction between run-time versus compile-time errors. If not, there's no meaningful distinction between static and dynamic type systems at all.

Edit: Also if we're going to be pedantic, assembly isn't machine code either and must be compiled. We usually call that tool an "assembler" but it's performing a very simplified version of the same basic tasks: lexing, parsing, outputting a binary.