Hacker News Reader

Comment by bentlegen | Hacker News Reader

The reality is that nobody writes parseInt(1/0, 19). Get off your high horse.

it is just an example, but it shows the kind of danger/potential bugs comes with using a badly designed language.

PS : I know it had been designed in 11 days and as such it is an achievement, but as the most used programming language it is quite awful.

Do people really use the "11 days" thing in defense of javascript? I get that it was rushed into production, and all things considered, that was probably the appropriate thing to do given its intended use at the time. But it doesn't matter. I think we have to realize we've collectively failed by not developing an alternative to this tool that clearly wasn't designed for the things modern web applications want/need.

There's nothing "clearly" about it. What in particular can't it do that you want it to do?

I don't even see why this is such a sign of bad design. There are tons of things in JavaScript (and virtually every other language, if not all of them) that are bad design; the fact that parseInt takes a string as its first argument and that 1/0 is the string "Infinity" really doesn't seem like it should qualify.

The fact that we are looking at parseInt as a potential problem here doesn't even make sense, given that the way most developers at this point actually expect functions like parseInt to work is to stop at the first non-number, and the developer in this case specifically went out of their way to choose a radix where I is a number.

Things that could have happened instead:

1) parseInt could fail if it is passed a string that contains anything that is not a digit (this would surprise many developers: again, this is highly common behavior)

2) 1/0 could throw an exception (I would argue this isn't even useful: +Inf is a valuable result)

3) +Inf could return something other than Infinity if converted to a string (maybe the infinity symbol in unicode?)

4) +Inf could refuse to be converted to a string (this is awkward, given that any other number can be converted to a string)

5) numbers could always refuse to be automatically converted to strings (I actually agree with this, but I feel like I'm in the minority: 'a' + 4 + 'b' would therefore also hopefully be illegal; this is an argument for a separate string concatenation operator)

6) parseInt could specifically refuse to automatically convert its argument to a string (this is probably the most reasonable thing that could have been different; however, tons of languages, including ones considered to have amazing type systems like Scala, support implicit conversion and don't even offer this kind of override flexibity)

Which are you claiming is the bad design? Maybe there's something I'm missing? I mean, if this was a situation where 4 + '1a' yielded the result '5' I'd be sufficiently angry as to claim that the people who designed this language were incompetent or dangerously negligant (PHP probably does this... MySQL almost certainly does ;P j/k, btw, only semi-serious), but this behavior seems somewhat reasonable.

One bit I think is poor design is that parseInt parses all characters until it finds a non numeric one. It can introduce some really subtle bugs.

That was my potential complaint/fix #1: that parseInt could refuse to work if it is passed a string that contains things that aren't valid digits in whatever radix it is working in. I personally believe I agree with you, but this is actually the way these functions work in most languages. In particular, this is the behavior of the various functions in C, such as atoi and strtol. While this isn't then "best of breed" behavior, I don't think it is unreasonable behavior. (Python's int() does not do this, for what it is worth: it gets angry and throws an exception if you pass it something that isn't entirely a number.)

Python does (5) and it's pretty refreshing. I'm sure other languages with more elaborate type systems do as well, but it's nice to see in an ostensibly "scripty" language.

I think another interesting thing to note is that many languages that do make a distinction (at the type level) between integer types and floating point types (that is, ones like IEEE 754 floats with defined NaN and +/- Infinity behavior) do allow 1f / 0f [1], but raise an error on 1 / 0. Avoiding automatic type coercions (either between ints and floats or between floats and strings) would make it more clear what actually happens in that case.

[1]: Except, apparently, Python! Who knew: http://bytes.com/topic/python/answers/769104-turn-off-zerodi... ?

I strongly disagree on #1. If I hand you something to parse in any context and it isn't valid, I expect you to tell me it wasn't valid (the one big exclusion to this is HTML in the browser).

I weakly disagree on #2. There are cases where +Inf is valuable, but I've never seen it in the browser. That doesn't mean it doesn't exist in the browser, just that I think it is an error far more than it is expected.

I think #3 would need to exist because 1 and 2 are wrong.

I totally agree with #5. That little simplification is the source of endless subtle bugs.

And #6 is an interesting one. I think it is related to #5, though. A language should first and foremost be consistent. If it automatically coerces in some conditions, it probably should in all[1].

1. Said while it is late and I haven't really thought through all the potential ramifications.

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)

What does this example have to do with language design? Eval, for instance, introducing lexical bindings is bad language design. This is mereley an API with a poor contract.

Isn't this a problem with any weakly typed language though? This same problem comes up in Perl and php. When you do type coercion, weird edge cases come up.

Just because you have weak types does not mean you have to have automatic coercion.

That's actually a widely accepted definition of "weak types": automatic type coercion. That said, "weakly typed" is not a well-defined term and I prefer not to use it.

Note that it is not the same as dynamic types. A dynamic type system is a well-defined concept and says nothing about type coercion.

The reality is that flaws like that are seldom skin deep, and can bite you in other parts of the language, even where you don't expect them.

Lack of type safety in a dynamic language is one thing, but awful type coercion is a different beast altogether.

Reply on news.ycombinator.com