6 ms·

If this was in PHP people would be crying out what a bad and horrible language it is. Javascript it's seen as an amusing conundrum.

JoeCortopassi 14y ago
The only reason something like this makes it to the front page, is because of the popularity of things like node.js right now. This is a bug, not a feature.
- JonoW 14y ago
  The crazy part is that it's not a bug; it's behaving exactly as it's specified to.
- deleted 14y ago
  [deleted]
- chris_wot 14y ago
  No, no it's not. It's actually part of ECMA-262. Javascript allows numbers to be a number, NaN or positive/negative infinity. It is well specified within the spec that "Division of a nonzero finite value by a zero results in a signed infinity. The sign is determined by the rule already stated above." [1] Before you get your knickers in a twist, this is compliant with IEEE 754; although the IEEE define it as an exception. 1. ECMA-262, pg 74, "11.5.2 Applying the / Operator"
  - JoeCortopassi 14y ago
    I understand that this is part of the spec. But that is a bug to allow division by zero to return a string, and then allow a string to have it's first letter indexed by a math function as a representation of a non base 10 number, is a bug! Just because it is part of the spec doesn't make it a sane addition to the language.
    - chris_wot 14y ago
      Division by zero doesn't return a string. It returns a well defined value that is within the domain of the data type, which is positive infinity. parseInt does what it is specified to do - it takes the numerical value (positive infinity) and converts it to a string, then searches the string for the first character that it recognises as a contiguous number ("I", which is 18 in base 19). If it finds one, then it returns the value as an integer, if not then it returns NaN. So not a bug, though I agree the string search is particularly silly. It can't be a bug if it does what the specified algorithm says it does. It would be a bug if it gave a different result.
asto 14y ago
The reason javascript won't get nearly as much ridicule as PHP is because there's no other choice with javascript. Most arguments against PHP are in the form - I'm using <super awesome language> because PHP has .... faults. Also, the fact that very few people code pure javascript, instead choosing frameworks like jquery, goes to show how much people like it!
- philwelch 14y ago
  > Also, the fact that very few people code pure javascript, instead choosing frameworks like jquery, goes to show how much people like it! I'd say most languages are coded in frameworks and not just the "pure" language.
- jpk 14y ago
  I second this. Javascript is a dumpster-fire of a language, as is PHP. If I could use anything other than javascript for scripting in the browser, I would, but I can't. So I use it. I can use things other than php on the server, so I do. However, I'd say the use of libraries and frameworks help javascript programmers, for sure, but that doesn't make the language any less of a mess (and in some cases, like jQuery setting "this" to whatever the hell it wants, makes it more of a mess). I can't speak for php, because I've used it far less, but I suspect the same holds true there, too.
  - chris_wot 14y ago
    I'm unclear what in particular is such a mess about Javascript?
    - chris_wot 14y ago
      Clearly my comment has annoyed someone. I'm actually quite serious though; rather than voting me down, perhaps an answer (or even just a link!) would be more useful to the discussion at hand.
      - Androsynth 14y ago
bentlegen 14y ago
The reality is that nobody writes parseInt(1/0, 19). Get off your high horse.
- 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.
Lazare 14y ago
First, Javascript isn't nearly as bad as PHP. Second, even the biggest fans of Javascript recognize its problems (the same can't be said of PHP). Third, even the biggest decractors of Javascript recognize its one overwhelming strength: It's the only language to run in the browser.
- steve-howard 14y ago
  Remember that the main reason PHP has such a broad user base is that it runs with fairly comparatively little setup on every server out there. That doesn't make it good. JavaScript is the only language to run in the browser because years ago someone developed it for that purpose. We could be using Python or Ruby or Brainfuck if there were any way to convince all major browser vendors to support that directly.
  - gaius 14y ago
    ISTR that Eich said he originally planned on Scheme in the browser, but for marketing reasons was ordered to make it look more like Java.
chris_wot 14y ago
I know! In PHP, try the equivalent: print intval(NaN, 19); Result in PHP 5.2.17 is: 0 Clearly, that is correct. PHP does the following: intval('42', 8); // => 34 intval(42, 8); // => 42 Now try: print intval(strval("19.99"*100)); print "<br>"; print intval("19.99"*100); This returns: 1999 1998
- saurik 14y ago
  That is not equivalent: 1/0 returns +Inf, not NaN. In JavaScript, parseInt(NaN, 19) actually returns NaN, as there are no valid digits below radix 19 in the string "NaN". PHP, in fact, has the same behavior that JavaScript does: if you do parseInt or intval on (NaN, 24) you will get 13511 (23 * 24 * 24 + 10 * 24 + 23) in either language. Unrelated, it seems like intval(1/0, 19) in PHP also returns 0 because 1) intval returns 0 if given an empty string (JavaScript's parseInt returns NaN if given an empty string) and 2) 1/0 seems to return something hilarious... it converts to "", but gettype() on it returns "boolean"... I sadly don't know PHP well enough to understand what it is ;P.
  - deleted 14y ago
    [deleted]
  - deleted 14y ago
    [deleted]
  - deleted 14y ago
    [deleted]

JoeCortopassi 14y ago

The only reason something like this makes it to the front page, is because of the popularity of things like node.js right now. This is a bug, not a feature.

JonoW 14y ago
The crazy part is that it's not a bug; it's behaving exactly as it's specified to.
deleted 14y ago
[deleted]
chris_wot 14y ago
No, no it's not. It's actually part of ECMA-262. Javascript allows numbers to be a number, NaN or positive/negative infinity. It is well specified within the spec that "Division of a nonzero finite value by a zero results in a signed infinity. The sign is determined by the rule already stated above." [1] Before you get your knickers in a twist, this is compliant with IEEE 754; although the IEEE define it as an exception. 1. ECMA-262, pg 74, "11.5.2 Applying the / Operator"
- JoeCortopassi 14y ago
  I understand that this is part of the spec. But that is a bug to allow division by zero to return a string, and then allow a string to have it's first letter indexed by a math function as a representation of a non base 10 number, is a bug! Just because it is part of the spec doesn't make it a sane addition to the language.
  - chris_wot 14y ago
    Division by zero doesn't return a string. It returns a well defined value that is within the domain of the data type, which is positive infinity. parseInt does what it is specified to do - it takes the numerical value (positive infinity) and converts it to a string, then searches the string for the first character that it recognises as a contiguous number ("I", which is 18 in base 19). If it finds one, then it returns the value as an integer, if not then it returns NaN. So not a bug, though I agree the string search is particularly silly. It can't be a bug if it does what the specified algorithm says it does. It would be a bug if it gave a different result.

asto 14y ago

The reason javascript won't get nearly as much ridicule as PHP is because there's no other choice with javascript. Most arguments against PHP are in the form - I'm using <super awesome language> because PHP has .... faults. Also, the fact that very few people code pure javascript, instead choosing frameworks like jquery, goes to show how much people like it!

philwelch 14y ago
> Also, the fact that very few people code pure javascript, instead choosing frameworks like jquery, goes to show how much people like it! I'd say most languages are coded in frameworks and not just the "pure" language.
jpk 14y ago
I second this. Javascript is a dumpster-fire of a language, as is PHP. If I could use anything other than javascript for scripting in the browser, I would, but I can't. So I use it. I can use things other than php on the server, so I do. However, I'd say the use of libraries and frameworks help javascript programmers, for sure, but that doesn't make the language any less of a mess (and in some cases, like jQuery setting "this" to whatever the hell it wants, makes it more of a mess). I can't speak for php, because I've used it far less, but I suspect the same holds true there, too.
- chris_wot 14y ago
  I'm unclear what in particular is such a mess about Javascript?
  - chris_wot 14y ago
    Clearly my comment has annoyed someone. I'm actually quite serious though; rather than voting me down, perhaps an answer (or even just a link!) would be more useful to the discussion at hand.
    - Androsynth 14y ago

bentlegen 14y ago

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

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.

Lazare 14y ago

First, Javascript isn't nearly as bad as PHP. Second, even the biggest fans of Javascript recognize its problems (the same can't be said of PHP). Third, even the biggest decractors of Javascript recognize its one overwhelming strength: It's the only language to run in the browser.

steve-howard 14y ago
Remember that the main reason PHP has such a broad user base is that it runs with fairly comparatively little setup on every server out there. That doesn't make it good. JavaScript is the only language to run in the browser because years ago someone developed it for that purpose. We could be using Python or Ruby or Brainfuck if there were any way to convince all major browser vendors to support that directly.
- gaius 14y ago
  ISTR that Eich said he originally planned on Scheme in the browser, but for marketing reasons was ordered to make it look more like Java.

chris_wot 14y ago

I know! In PHP, try the equivalent: print intval(NaN, 19); Result in PHP 5.2.17 is: 0 Clearly, that is correct. PHP does the following: intval('42', 8); // => 34 intval(42, 8); // => 42 Now try: print intval(strval("19.99"*100)); print "<br>"; print intval("19.99"*100); This returns: 1999 1998

saurik 14y ago
That is not equivalent: 1/0 returns +Inf, not NaN. In JavaScript, parseInt(NaN, 19) actually returns NaN, as there are no valid digits below radix 19 in the string "NaN". PHP, in fact, has the same behavior that JavaScript does: if you do parseInt or intval on (NaN, 24) you will get 13511 (23 * 24 * 24 + 10 * 24 + 23) in either language. Unrelated, it seems like intval(1/0, 19) in PHP also returns 0 because 1) intval returns 0 if given an empty string (JavaScript's parseInt returns NaN if given an empty string) and 2) 1/0 seems to return something hilarious... it converts to "", but gettype() on it returns "boolean"... I sadly don't know PHP well enough to understand what it is ;P.
- deleted 14y ago
  [deleted]
- deleted 14y ago
  [deleted]
- deleted 14y ago
  [deleted]