This is why I think a type system--at least one like Haskell's or OCaml's--isn't just a way to catch certain bugs. It's more of a different <i>basis</i> for programming: your program grows from the types rather than vice versa. Confusing behavior like this simply couldn't arise. And in the cases it <i>could</i> it <i>wouldn't</i>--it simply doesn't fit with the philosophy.<p>So the difference is not that the type system would catch this sort of behavior or even that it would prevent it--the difference is that it wouldn't arise in the first place. Sure, this is more a difference of perspective than of actual behavior or features, but I think it's incredibly important nonetheless.<p>Thinking about types in this different way is actually quite a deep topic; I should write a blog post about it for that blog I keep on meaning to start :P. One day. At the very least, writing it all down would help me get my own thoughts in order.
Funnily enough I just blogged on exactly the same issue: <a href="http://www.noelwelsh.com/programming/2013/04/13/less-wat-in-javascripts-future-please/" rel="nofollow">http://www.noelwelsh.com/programming/2013/04/13/less-wat-in-...</a><p>Couldn't agree more that this is bad practice!
Just to relate this to known concepts, this is basically Type Coercion, aka Implicit Type Conversion, at library level. Or it can be framed as method overloading with some magic to neutralize the parameters.<p><a href="http://en.wikipedia.org/wiki/Type_conversion#Implicit_type_conversion" rel="nofollow">http://en.wikipedia.org/wiki/Type_conversion#Implicit_type_c...</a><p>I don't think magic like this is out of place with JS; that's the zen of the language. Similarly for Ruby. Whereas in Java or Python, it <i>would</i> be out of place. Now you might use that as an argument against JS, but that's a separate debate.
From the post:<p>"This is annoying at the level of Arrays, but gets more difficult with more complex types, and function interactions. The recent brouhaha around the Promise/A+ highlights one such example: It is difficult to return a Promise of a Promise as a value from onFulfilled because then duck-wraps the return value as described in the Promise Resolution Procedure"<p>Could anyone share a pointer to this brouhaha around the Promise/A+ [spec, I assume]?