Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why ++[[]][+[]]+[+[]] = 10 in JavaScript

stackoverflow.com

Post reply on HN
Print view View original

1–10 of 80 posts

Re: Why ++[[]][+[]]+[+[]] = 10 in JavaScript

#5

Post by raganwald »

recoiledsnake wrote: post #3

This is the reason I prefer strongly typed languages. Allowing developers to play fast and loose with data types only leads to less maintainability down the road and makes code difficult to read.

I am not a PL expert, but is this a strong vs. weak type problem or an implicit conversion problem? My layman’s (simplistic) model is that “weakly typed” languages allow entities to change their type at runtime, strongly typed languages do not.

But what we have here is an expression where entities are being implicitly converted into intermediate values, along with operators that do different things based on the values they are given. For example, the behaviour of the “+” infix operator in JavaScript could be replicated in any strongly typed language that has pattern matching:

  x:string + y:string -> concat(x,y)
  x:stringable + y:string -> concat(toString(x), y)
  x:string + y:stringable -> concat(x, toString(y))
  x:numeric + y:numeric -> sum(x,y)
  ...
I recall implicit conversion being one of the gotchas in C++. While its casts break strictly strong typing, a program with lots of implicit conversions can behave just about as mysteriously as the example JavaScript.

Back in the day when I wrote C++ (by gaslight, after I rode my penny farthing to the office), any one-argument constructor was presumed to be an implicit conversion unless you provided the “explicit” keyword.

UPDATE (and thanks to the hacker who pointed me in this direction):

http://en.wikipedia.org/wiki/Strong_typing

It seems that the expression “Strong typing” subsumes both the concept of static typing (variables and/or values do not change their types) and of coercion. (Along with other issues such as whether programmers can deliberately evade restrictions).

If I were to rewrite my question, I would ask if this is a strong typing problem overall or just the subset of strong typing issues concerning coercion?

So part of the issue with this code is implicit coercion, which is not “strong typing,” but the other is polymorphic operators like “+”, which are independent of strong vs. weak typing.

Re: Why ++[[]][+[]]+[+[]] = 10 in JavaScript

#8

Post by ramchip »

recoiledsnake wrote: post #3

This is the reason I prefer strongly typed languages. Allowing developers to play fast and loose with data types only leads to less maintainability down the road and makes code difficult to read.

I don't see how this example justifies your position, though. Nobody will ever write "++[[]][+[]]+[+[]]" to mean "10" in anything but an obfuscated code contest.

Re: Why ++[[]][+[]]+[+[]] = 10 in JavaScript

#9

Post by [deleted] »

raganwald wrote: post #5
recoiledsnake wrote: post #3

This is the reason I prefer strongly typed languages. Allowing developers to play fast and loose with data types only leads to less maintainability down the road and makes code difficult to read.

I am not a PL expert, but is this a strong vs. weak type problem or an implicit conversion problem? My layman’s (simplistic) model is that “weakly typed” languages allow entities to change their type at runtime, strongly typed languages do not. But what we have here is an expression where entities are being implicitly converted into intermediate values, along with operators that do different things based on the value…

[deleted]

Re: Why ++[[]][+[]]+[+[]] = 10 in JavaScript

#10

Post by flpmor »

ajankovic wrote: post #6

I wonder how people come up with this kind of code to begin with?

This comes from an attempt to write valid JavaScript without using any letters or numbers. It's partly for the sake of demonstrating it's possible and part for security testing reasons, to show that poorly written input validation filters can be bypassed.
Post reply on HN