| The browser is just another programming environment: people are now doing distributed computation and 3D engine development in JavaScript; if you believe that +Inf is valuable anywhere, it should be no different in the browser. To me the argument against trying to fix #3 is that this is already a type domain error: if you are doing division on any two numbers and expecting to be able to take the result, as if it were a string, and pass that to a function called parseInt (as in, "integer"), you are already doing something fundamentally wrong. I mean, the semantics of the code in question are just stupid: take two integers (yes, I realize JavaScript has no concept of integers vs. doubles), divide to get a rational number, pass that rational number to a function that takes a string that is supposed to represent an integer, and claim that that string is in base 19... So, arguably, the real goal here should just be "keep the developer from doing something this stupid", as there really isn't anything more reasonable to have happened: it isn't like it should return 0 (incorrect result) or +Inf (not an integer); it could return null, or thrown an exception, but it should not work: the only question is "why should it not work". To make it not work in a sensible way, we then need to ask ourselves "what is the underlying mistake here", and I believe that it really has nothing to do with the 1/0: if I somehow managed to accidentally pass 1/2 to parseInt with a radix of 19, I'd also want an exception. Hell, in a more-perfect universe, I'd like to get an exception even if I pass 2/2 to parseInt with a radix of 19. I can thereby totally feel for the argument that parseInt should throw an exception (maybe return null) if the string does not represent an integer. However, I continue to find it a stretch to claim that that is bad language design... maybe bad library design, but again that is how that function works in most languages. From a language design perspective, the problem is either 1) that this function (parseInt) made sense to have been written at all, 2) that this block of code using it was allowed to be executed in the first place, or 3) that the developer was led to believe, based on other language constructs, that this was sufficiently reasonable to be typed by a developer. Looking at it in this light, some languages are even well-enough designed to allow a function with the semantics of parseInt to exist and yet not allow this call at compile time: the fact that we have to wait until runtime to figure out that this code is wrong is then arguably "bad language design" (although, of course, has other interesting tradeoffs that people sometimes prefer). This notion of "choose the language feature that best disuades this entire class of error" appeal is therefore why, were we to have a time machine to change JavaScript before it got entrenched, I would go with #5 (refusing to cast from a number to a string, and preferably also adding a dedicated string concatenation operator). The key advantage is that #5 is a language change that fundamentally removes this kind of mistake from everywhere it could occur, while not adding a static type system or otherwise screwing with the set of data types (which would drastically change the overall character and abilities of the rest of the language "JavaScript"). (As an aside: I personally believe that the notion of "string with specific semantics" is something that can and should also be considered when designing type systems, but the ramifications of building something like that are more worthy of a PhD, or at least a Master's, thesis than a tiny post on a web forum. ;P) |