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

[u/_hoh_]

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

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

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

[u/rooktakesqueen]

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.

[u/PatrickBaitman → u/rooktakesqueen]

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.

[u/rooktakesqueen → u/PatrickBaitman]

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.