Does this trick work in Brendan Eich's first JS implementaion in Netscape 2.0? Which came first, the spec or the implementation?
I guess that's funny depending on who you are.
You may say that users don't need to see to see strange error messages they don't understand. Quite right, what we need instead is to have a way for browsers to transmit uncaught exceptions in JS to the server.
If I want an array to be a number, I'll call .Count on the array or whatever the applicable property I want is.
The unary '+' operator is completely pointless if something is already a number, it is a no-op. Literally the only time anyone would ever type +x is if x is not a number, if someone chose to write +x and x turned out to unexpectedly be an array, pretty much the only thing that you know they were thinking of when they wrote the + was that they thought x isn't a number; maybe a string if they were using +x instead of parseFloat(x), but definitely not a number.
It just isn't a reasonable example of a situation where an array is being used where a number should be, +x where you know that x is a number would make no sense. If you talk about -x then that is completely different, people who write -x almost certainly expect it to be a number, and - === 0. Unary plus is just not the right example for awful type coercion here.
",,," == Array((null,'cool',false,NaN,4)); // true
(null,'cool',false,NaN,4) evaluates to the last expression - 4
Array(4) creates an array with 4 elements.
Array(4).toString() = ",,,"
1). a list of expressions eg (foo,bar,baz) evaluates to the last one.
2). Array(4) creates an empty array of 4 elements
2). Array(4).toString() = ",,,"
The same applies to the void operator, I can think of one or two cases at most where it would be useful, but I don't see anyone using it.
It depends on underscore.js for the functional bits.
I've never seen the term "gook" outside of a racial slur context.
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.
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)
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):
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.
Update to your update:
Strong typing does not subsume static typing. Ruby, for example, is dynamic and quite strongly typed. You can't bypass the type system at all, and the only real coercion is to boolean, which follows a very simple rule.
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.
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.
Most people are not trained to notice these kinds of problems, or the simple checks that can stop them from confusing a list of lists and a list of lists of lists. But if you take a step back and think hard about what's happening to your time, you'll find that many hours are sunk chasing problems that are, in many ways, simple. Having static checks is like always having someone to read code over your shoulder.
Right which was my point in my other post where I said I just don't run into it that much. It is rare that we run into situations where we have to do tricky stuff with the type system. If we do we usually hide it behind a well tested API so that it is isolated and reusable. It's just not the problem domain that we solve for (most of the time) in web and mobile development. As such for my work flow the type safety of a languadge, does not factor in all that much. At least until I hit the middleware layer then I tend to use Java, but much of that decision is out of comfort and volume of libraries available.
Maybe you've created a button that puts some text in an element, but, in some rare cases, due to other events on the page, that element doesn't exist. The user clicks the button, document.getElementById returns null, and a nice error message pops out.
Remember, being able to write a function that converts either a string or an integer to an array is exactly the kind of thing that dynamically typed languages let you do that statically-typed languages don't. If you're not doing that kind of thing, you're better off with a statically-typed language (when available).
Moreover, despite being a strongly-ish typed language, C++ has pretty ridiculous implicit conversion semantics, only statically rather than dynamically.
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.
A bad craftsman always blames their tools.
And sometime smart people tend to think they're invincible/bullet-proof. Not too many people have high-level discipline. And those that have high-level discipline tend to be shunned by "hackers" because "hackers" hate "processes". They just want to write fun code.
Hence the circle of evil.
(Surely no other university teaches that language besides mine, right?)
(I'm learning J and other APL derivatives right now by myself by experimenting with the J docs and pinging the amazing people at the J software forums).
See you at the J software forums.