5 ms·

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 a

by LBarret 14y ago

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.

jpk 14y ago
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.
- chris_wot 14y ago
  There's nothing "clearly" about it. What in particular can't it do that you want it to do?
saurik 14y ago
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.
- JonoW 14y ago
  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.
  - saurik 14y ago
    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.)
- deleted 14y ago
  [deleted]
- deafbybeheading 14y ago
  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-zerodivisionerror http://bytes.com/topic/python/answers/769104-turn-off-zerodi... ?
- SoftwareMaven 14y ago
  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.
kaushiks 14y ago
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.
Androsynth 14y ago
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.
- justincormack 14y ago
  Just because you have weak types does not mean you have to have automatic coercion.
  - tikhonj 14y ago
    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.

by LBarret 14y ago

jpk 14y ago

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.

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

saurik 14y ago

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.

JonoW 14y ago
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.
- saurik 14y ago
  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.)
deleted 14y ago
[deleted]
deafbybeheading 14y ago
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-zerodivisionerror http://bytes.com/topic/python/answers/769104-turn-off-zerodi... ?
SoftwareMaven 14y ago
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.

kaushiks 14y ago

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.

Androsynth 14y ago

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.

justincormack 14y ago
Just because you have weak types does not mean you have to have automatic coercion.
- tikhonj 14y ago
  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.