5 ms·

From: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/map https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

From: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/map https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... ['1', '2', '3'].map(parseInt); // While one could expect [1, 2, 3] // The actual result is [1, NaN, NaN] parseInt is often used with one argument, but takes two. The first is an expression and the second is the radix. To the callback function, Array.prototype.map passes 3 arguments: the element, the index, the array. The third argument is ignored by parseInt, but not the second one, hence the possible confusion.

crimsonalucard 9y ago
This shows how badly javascript was designed. Functions when used improperly should throw an exception not "sort of work."
- reificator 9y ago
  To take up the mantle of Devil's Advocate: Neither of these are doing anything wrong on their own[1]. When you go to map something you want to be able to access the index sometimes. When you parse an int, you sometimes want to be able to specify a base. Maybe in a strongly typed language you might use an enum with valid bases instead of an int, but that doesn't make sense in a dynamically typed language[2]. Maybe you use different function names if you want to parse an int in decimal vs an arbitrary base, I can't argue with that, but overloaded functions/methods are the norm and not the exception in most languages I've used. [1]: Except parseInt's default radix which is ambiguous and the cause of countless bugs. But this bug is because we ARE specifying it. [2]: And no, being dynamically typed is not inherently bad design.
  - dragonwriter 9y ago
    It makes sense to have a function that is like the common functional “map” but passing the index as well, it's probably not a great design to have it be called “map” and have the basic, no-index behavior rely on the passed function taking only one arg, especially in a language where functions that usually take one arg but also have optional args are common.
  - crimsonalucard 9y ago
    In terms of design I'm talking about an exception not the arity of the function. A hidden NaN in an array of numbers is like a javascript promise for an error in the future. This isn't IO so it's better to kill it now rather than killing it sometime in the future. Actually, to be honest will NaN even launch an exception? Does 1 + NaN cause an exception or does it propagate more NaNs all over the code? Imagine you are debugging a 10000 line function that's suppose to return an int, but instead returns a NaN. Where did this error occur in the 10000 lines? Sure, I can say all kinds of stuff to make finding this error sound simple but if exceptions were thrown instead of assigning NaNs to some variable life would be easier. The exception would tell me the exact line of the illegal operation while a NaN tells me nothing. Javascript treats the "NaN" type as if it's a number... in the sense that when you do a math operation on something that is a NaN you get another NaN... The reality is... the very abbreviation "NaN" stands for is "Not a Number" so the addition of a number and something that is not a number should not even occur. Seriously? They should have called it "LoL" or "WtF" because these are more appropriate abbreviations.
    - deleted 9y ago
      [deleted]
    - reificator 9y ago
      Look, misattributing the introduction of NaN to JS is not going to help make the case that JS is poorly designed[1]. JS uses double-precision floating point numbers, based on the IEEE 754 standard first published in 1985. [1]: Though there is a case that using doubles for all numbers is poor design, that's a different topic altogether.
      - crimsonalucard 9y ago
        I don't know where NaNs were introduced, but I never attributed the introduction of NaNs to javascript. If JS is just propagating a bad design, it still fits the description of being poorly designed. Not to mention a null. null + 1 = 1. This is even worse. Your 1000loc function returns a legit number but it's a little bit off... and you have to find it. Imagine never having to have to do that with a language like python... 1+None and 1/0 all return named exceptions with line numbers in python.

crimsonalucard 9y ago

This shows how badly javascript was designed. Functions when used improperly should throw an exception not "sort of work."

reificator 9y ago
To take up the mantle of Devil's Advocate: Neither of these are doing anything wrong on their own[1]. When you go to map something you want to be able to access the index sometimes. When you parse an int, you sometimes want to be able to specify a base. Maybe in a strongly typed language you might use an enum with valid bases instead of an int, but that doesn't make sense in a dynamically typed language[2]. Maybe you use different function names if you want to parse an int in decimal vs an arbitrary base, I can't argue with that, but overloaded functions/methods are the norm and not the exception in most languages I've used. [1]: Except parseInt's default radix which is ambiguous and the cause of countless bugs. But this bug is because we ARE specifying it. [2]: And no, being dynamically typed is not inherently bad design.
- dragonwriter 9y ago
  It makes sense to have a function that is like the common functional “map” but passing the index as well, it's probably not a great design to have it be called “map” and have the basic, no-index behavior rely on the passed function taking only one arg, especially in a language where functions that usually take one arg but also have optional args are common.
- crimsonalucard 9y ago
  In terms of design I'm talking about an exception not the arity of the function. A hidden NaN in an array of numbers is like a javascript promise for an error in the future. This isn't IO so it's better to kill it now rather than killing it sometime in the future. Actually, to be honest will NaN even launch an exception? Does 1 + NaN cause an exception or does it propagate more NaNs all over the code? Imagine you are debugging a 10000 line function that's suppose to return an int, but instead returns a NaN. Where did this error occur in the 10000 lines? Sure, I can say all kinds of stuff to make finding this error sound simple but if exceptions were thrown instead of assigning NaNs to some variable life would be easier. The exception would tell me the exact line of the illegal operation while a NaN tells me nothing. Javascript treats the "NaN" type as if it's a number... in the sense that when you do a math operation on something that is a NaN you get another NaN... The reality is... the very abbreviation "NaN" stands for is "Not a Number" so the addition of a number and something that is not a number should not even occur. Seriously? They should have called it "LoL" or "WtF" because these are more appropriate abbreviations.
  - deleted 9y ago
    [deleted]
  - reificator 9y ago
    Look, misattributing the introduction of NaN to JS is not going to help make the case that JS is poorly designed[1]. JS uses double-precision floating point numbers, based on the IEEE 754 standard first published in 1985. [1]: Though there is a case that using doubles for all numbers is poor design, that's a different topic altogether.
    - crimsonalucard 9y ago
      I don't know where NaNs were introduced, but I never attributed the introduction of NaNs to javascript. If JS is just propagating a bad design, it still fits the description of being poorly designed. Not to mention a null. null + 1 = 1. This is even worse. Your 1000loc function returns a legit number but it's a little bit off... and you have to find it. Imagine never having to have to do that with a language like python... 1+None and 1/0 all return named exceptions with line numbers in python.