Live data from Hacker News

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

stackoverflow.com

21–30 of 80 posts

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

#21

Earlier quoted context omitted.

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…

Wikipedia has a good page on this subject. In a nutshell, "strong/weak" typing is not formally defined. Usually languages are called weakly typed when they allow a lot of implicit type coercion or just don't strictly enforce types. It's not at all unique to dynamically typed languages. C is pretty weakly typed, for example. And a static language could just as easily have a quirk like this JavaScript thing. http://en.…

I wrote an article where I tried to lay out the definitions of these terms: http://alexgaynor.net/2010/nov/19/programming-languages-term...

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

#23
post #8

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.

No they will, in every horribly thought out interview that someone who thinks they are smart writes in on a white board and asks applicants to solve it. As if these trick questions some how give insight into ones ability to solve real world problems. These are exactly the kind of obscure fringes of a languadge that an interviewer with an ego loves. When they reality is whether one can solve it or not, amounts to a hill of beans as to whether one is a good JavaScript programer or not. In fact if they are using these fringe practices in their code base they are writing unmaintainable code, which makes them a less desirable developer.

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

#24

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 have been in the industry for 16 years and have some pretty big code bases, in a variety of languages, under my belt (not trying to brag just setting the back-story). In thinking back, I cannot recall a single instance where any member of my team was bitten by an accidental conversion or a type safety issue. I have been fortunate to work with some good people, but some of them where average in their ability to actually write code, yet we never had these issue. I find it hard to believe that my situation is unique and I think the type safety Strong/Weak argument is a little overblown, I just don't encounter it in real life and don't know many other developers that do.

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

#26

Earlier quoted context omitted.

True! you wont use it. I guess it'll end up being just an Interview Question.

The correct interview question is, “Write a filter that blocks executable JavaScript but allows text.” And the correct answer is “Kobayashi Maru."

The correct interview question is, “Write a filter that blocks executable JavaScript but allows text.

I would hire you on the spot, my post history is littered with how irrelevant these type of questions are to gauging ones ability to develop real world solutions. You pretty much summed up the irony nicely.

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

#27

Earlier quoted context omitted.

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…

Wikipedia has a good page on this subject. In a nutshell, "strong/weak" typing is not formally defined. Usually languages are called weakly typed when they allow a lot of implicit type coercion or just don't strictly enforce types. It's not at all unique to dynamically typed languages. C is pretty weakly typed, for example. And a static language could just as easily have a quirk like this JavaScript thing. http://en.…

While the phrases don’t seem to have strict definitions, by the Wikipedia description of Strong Typing ,there is an overlap with Static Typing:

The mandatory requirement, by a language definition, of compile-time checks for type constraint violations. That is, the compiler ensures that operations only occur on operand types that are valid for the operation. However, that is also the definition of static typing, leading some experts to state: "Static typing is often confused with StrongTyping”...

Fixed and invariable typing of data objects. The type of a given data object does not vary over that object's lifetime. For example, class instances may not have their class altered.

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

I guess this is one of those things where the correct response to any claim about “Strong,” “Static,” “Weak,” or “Dynamic” typing is to ask the speaker what, specifically, he is thinking of.

In this case, you and I are exploring the subject in some depth, but the person who originally used the phrase “Strongly Typed” is silent, so neither of us has any idea what he had in mind.

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

#29
post #23
post #8

Earlier quoted context omitted.

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.

No they will, in every horribly thought out interview that someone who thinks they are smart writes in on a white board and asks applicants to solve it. As if these trick questions some how give insight into ones ability to solve real world problems. These are exactly the kind of obscure fringes of a languadge that an interviewer with an ego loves. When they reality is whether one can solve it or not, amounts to a hi…

Great, then you know who not to work for.

I agree that 'magic code' and obfuscation is pretty much ego stroking, but this doesn't seem like a good argument against the whole idea of using weakly typed languages.

Post reply on HN