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.…
Why ++[[]][+[]]+[+[]] = 10 in JavaScript
21–30 of 80 posts
Re: Why ++[[]][+[]]+[+[]] = 10 in JavaScript
#22Reminds me of the J programming language
Re: Why ++[[]][+[]]+[+[]] = 10 in JavaScript
#23This 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
#24This 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.
Re: Why ++[[]][+[]]+[+[]] = 10 in JavaScript
#25returns "foobar"
Re: Why ++[[]][+[]]+[+[]] = 10 in JavaScript
#26Earlier 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."
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
#27Earlier 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.…
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
#28((__=!($=[]))+$)[$++]+(_={}+$)[$]+_[$++]+_[$]+(__+_)[--$]+(!__+_)[$] returns "foobar"
Re: Why ++[[]][+[]]+[+[]] = 10 in JavaScript
#29Earlier 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…
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.