4 ms·

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 i

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.
  - reificator 9y ago
    No, not following the globally agreed upon standard for the sole purpose of making arithmetic slower in the general case would be bad design.
    - crimsonalucard 9y ago
      what are you talking about? when did i say I want to make arithmetic slower? And how is that globally agreed upon as a standard? In math when you get a NaN, do mathematicians continue to use it as a variable or do they realize they made a mistake? Think about it. In all math and science It's actually globally agreed upon that a NaN is not a variable you can reuse in some other function.
      - reificator 9y ago
        > And how is that globally agreed upon as a standard? Because all modern processors and mainstream languages implement their floating point calculations as IEEE 754. > when did i say I want to make arithmetic slower? When you said you wanted to introduce exceptions whenever NaN is encountered. Your processor has instructions that add/subtract/divide/multiply floating point numbers according to the IEEE 754 standard. What you propose is to then check in the implementation of JS after each instruction to see if the result is NaN, which is going to be a speed reduction of at least 2-3x, though I would expect it to actually be higher than that because branching can get expensive. (Making a note to go try it and benchmark) Then, after doing this check, you want to have JS throw an exception. This only slows down the uncommon case, so that's not much of an issue, but in situations where NaNs are able to be treated as valid values, they then have to catch these exceptions and resume normal execution flow. The result is that there is a happy path slowdown of arithmetic operations by at least 2-3x, to gain an arguable advantage in debugging time in the unhappy path. Throwing away compatibility with other languages and working against the processor are not goals I'd shoot for, and wrapping basic arithmetic in try/catch blocks doesn't sound like a very good payout for doing so.
        crimsonalucard 9y ago
reificator 9y ago
> Imagine you are debugging a 10000 line function that's suppose to return an int, but instead returns a NaN. I'm imagining that. It's my first day at a new job cleaning up a legacy codebase, but upon opening up a single 10kloc function written in JS, I realize that I made a terrible mistake and immediately hand in my resignation. In the meantime, I set a breakpoint at the end of the function, inspect the inline value annotations for NaNs, and trace them back to the start. Relative to any other debugging task in a 10kloc function, that doesn't sound bad at all. If it's consistently returning NaN, that should take maybe half an hour. Also, I'd be really surprised if the function was made to return an int, because JS doesn't have integer datatypes.
- crimsonalucard 9y ago
  Read what I wrote again: > 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. I said this in the parent post and sure enough the reply is exactly inline with what I said was going to happen. I don't hate javascript, but it has its horrible horrible warts. >Relative to any other debugging task in a 10kloc function, that doesn't sound bad at all. If it's consistently returning NaN, that should take maybe half an hour. An exception would take a second. An exception would give you the target line of every illegal operation; while a NaN propagates itself like a virus along every arithmetic operation. Some people find it easy to run a 20 miles, sure but that still doesn't change the fact that cars are much better. Get the analogy? You are running 20 miles and telling me how you don't mind... I'm saying sure, but driving still has a purpose in life.
  - reificator 9y ago
    > I said this in the parent post and sure enough someone who is a fan of javascript had to reply with exactly what I said was going to happen. Breakpoints are off the table? Seriously? I didn't realizing using a debugger made me a JS fanboy. Wrapping all of your basic arithmetic in try/catch blocks is completely unreasonable. If you need to check for NaN, check for NaN. Making arithmetic substantially slower in the general case to catch the uncommon cases is exactly the problem NaN was introduced to solve.

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.
- reificator 9y ago
  No, not following the globally agreed upon standard for the sole purpose of making arithmetic slower in the general case would be bad design.
  - crimsonalucard 9y ago
    what are you talking about? when did i say I want to make arithmetic slower? And how is that globally agreed upon as a standard? In math when you get a NaN, do mathematicians continue to use it as a variable or do they realize they made a mistake? Think about it. In all math and science It's actually globally agreed upon that a NaN is not a variable you can reuse in some other function.
    - reificator 9y ago
      > And how is that globally agreed upon as a standard? Because all modern processors and mainstream languages implement their floating point calculations as IEEE 754. > when did i say I want to make arithmetic slower? When you said you wanted to introduce exceptions whenever NaN is encountered. Your processor has instructions that add/subtract/divide/multiply floating point numbers according to the IEEE 754 standard. What you propose is to then check in the implementation of JS after each instruction to see if the result is NaN, which is going to be a speed reduction of at least 2-3x, though I would expect it to actually be higher than that because branching can get expensive. (Making a note to go try it and benchmark) Then, after doing this check, you want to have JS throw an exception. This only slows down the uncommon case, so that's not much of an issue, but in situations where NaNs are able to be treated as valid values, they then have to catch these exceptions and resume normal execution flow. The result is that there is a happy path slowdown of arithmetic operations by at least 2-3x, to gain an arguable advantage in debugging time in the unhappy path. Throwing away compatibility with other languages and working against the processor are not goals I'd shoot for, and wrapping basic arithmetic in try/catch blocks doesn't sound like a very good payout for doing so.
      - crimsonalucard 9y ago

reificator 9y ago

> Imagine you are debugging a 10000 line function that's suppose to return an int, but instead returns a NaN. I'm imagining that. It's my first day at a new job cleaning up a legacy codebase, but upon opening up a single 10kloc function written in JS, I realize that I made a terrible mistake and immediately hand in my resignation. In the meantime, I set a breakpoint at the end of the function, inspect the inline value annotations for NaNs, and trace them back to the start. Relative to any other debugging task in a 10kloc function, that doesn't sound bad at all. If it's consistently returning NaN, that should take maybe half an hour. Also, I'd be really surprised if the function was made to return an int, because JS doesn't have integer datatypes.

crimsonalucard 9y ago
Read what I wrote again: > 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. I said this in the parent post and sure enough the reply is exactly inline with what I said was going to happen. I don't hate javascript, but it has its horrible horrible warts. >Relative to any other debugging task in a 10kloc function, that doesn't sound bad at all. If it's consistently returning NaN, that should take maybe half an hour. An exception would take a second. An exception would give you the target line of every illegal operation; while a NaN propagates itself like a virus along every arithmetic operation. Some people find it easy to run a 20 miles, sure but that still doesn't change the fact that cars are much better. Get the analogy? You are running 20 miles and telling me how you don't mind... I'm saying sure, but driving still has a purpose in life.
- reificator 9y ago
  > I said this in the parent post and sure enough someone who is a fan of javascript had to reply with exactly what I said was going to happen. Breakpoints are off the table? Seriously? I didn't realizing using a debugger made me a JS fanboy. Wrapping all of your basic arithmetic in try/catch blocks is completely unreasonable. If you need to check for NaN, check for NaN. Making arithmetic substantially slower in the general case to catch the uncommon cases is exactly the problem NaN was introduced to solve.