7 ms·

Silencing an error like that is catastrophic. Silencing an error would be a problem, but in JS, it's not an error, because there's no concept of "wrong numbers

Silencing an error like that is catastrophic. Silencing an error would be a problem, but in JS, it's not an error, because there's no concept of "wrong numbers of function arguments" built into the language. That's not to say you can't inspect the number of arguments yourself and throw an error, if some situation warrants it. But you don't have to do this. It's a very flexible, dynamic language. In some ways this flexibility makes things easier and more expressive, in other ways it necessitates more manual checking (or slower debugging). There's no catastrophe, just design differences.

anon1385 13y ago
It's still a programmer error when they accidentally call a function with 2 arguments when they meant to call it with 3. The fact that the language can't inform them of the error doesn't change that.
- marrs 13y ago
  So do some error checks. The first unit test I write for any function is that it handles arguments correctly.
  - prof_hobart 13y ago
    That's great if it's your function that's the problem. Less so if it's someone else's. And it's not only these kinds of errors that can cause silent failure. I've had it on missing brackets, on missing commas, on failure to include/require the right source file etc, etc. No error message, no warning, no log entry, no nothing. Just silence. And a blank output. Not overly helpful.
  - anon1385 13y ago
    But you do see why people are complaining, right? You are having to manually write thousands of tests to check something that is trivial for a compiler to check.
    - gnaritas 13y ago
      This is just an absurd complaint, it's a dynamic language, if you want compiler forced type checking, use a static language. Dynamic languages are not broken because they don't behave like static languages.
      - Peaker 13y ago
        You're missing the point. A static language catches the error at compile-time. A dynamic language catches the error at run-time. Javascript hides the error and gives a cryptic bug, instead.
        gnaritas 13y ago
        I'm not missing the point, and I don't agree that it hides an error and gives a cryptic bug. Messing with a function signature and not updating callers of that function is not a bug in the language, it's a bug in the programmer and will result in runtime bugs in any dynamic language. If you require X number of args, then assert that they aren't undefined. If you presume callers pass in X number of args in a variable args language, and then change the required args, you're the bug, not the language.
        Peaker 13y ago
        > I'm not missing the point, and I don't agree that it hides an error and gives a cryptic bug. It hides the error by carrying on, despite having the wrong number of arguments, and executing code with thus necessarily wrong inputs. > Messing with a function signature and not updating callers of that function is not a bug in the language, it's a bug in the programmer When editing code, you routinely change the function signatures of hundreds of functions. Of course you're going to miss some, some of the time. Human errors happen, and good languages help us deal with them. Also, every time you pull code from another repository, function signatures all over the place change. Some of those may be functions your currently edited code is calling. This means every little divergence requires reviewing every single signature change or cryptic bugs will result. > and will result in runtime bugs in any dynamic language. It will result in runtime errors in dynamic languages. Errors that are visible, and difficult to ignore. That means the code gets fixed. UT triggers it trivially. Whereas with Javascript, even code under UT can easily pass accidentally when wrong numbers of arguments are used. This Dijkstra quote is relevant: > It was a significant improvement that now many a silly mistake did result in an error message instead of in an erroneous answer. (And even this improvement wasn't universally appreciated: some people found error messages they couldn't ignore more annoying than wrong results, and, when judging the relative merits of programming languages, some still seem to equate "the ease of programming" with the ease of making undetected mistakes.) > If you require X number of args, then assert that they aren't undefined That captures half of the bugs (too few arguments), for a large overhead (an extra line for almost every argument in every function). > If you presume callers pass in X number of args in a variable args language, and then change the required args, you're the bug, not the language Every time you change code, there is potential to insert bugs. Of course all bugs originate from programmer errors. The tools can work with us to find these errors and mitigate them, or they can give us hell.
  - Peaker 13y ago
    So in every single function, I have to either: A) Silently ignore errors in param counts, get cryptic bugs later when a trivial merge changes a function signature, or when changing a function signature. B) Add explicit code to check the parameter counts at a huge cost (a per-function overhead!) along with extra tests for this silly thing for each and every function. This overhead is insane! I have to choose between cryptic bugs and insane overhead, all for what? So you can use "args" and not "*args"? This is a catastrophic choice for the language.
Sirenos 13y ago
> ... in other ways it necessitates more manual checking (or slower debugging). There's no catastrophe, just design differences. See, there's the problem. Glossing over issues by explaining them away as "design differences". Nothing about an expressive language necessitates making life hard for the programmer. If your function call doesn't match the signature then it is very likely to be in error, and instead of failing silently the language should make such mistakes easy to spot. I like how most other dynamic languages require you to be more explicit about function parameters (with the exception of PHP).
- goblin89 13y ago
  > If your function call doesn't match the signature Depending on what constitutes function signature. I agree with “design difference” argument. Someone has to make design decisions, even if someone else doesn't agree with them.
  - Peaker 13y ago
    The problem is the design here is to trade errors that could be detected with cryptic bugs that can slip through. Or alternatively, adding insane per-function overhead/testing to manually cover signature checking.

anon1385 13y ago

It's still a programmer error when they accidentally call a function with 2 arguments when they meant to call it with 3. The fact that the language can't inform them of the error doesn't change that.

marrs 13y ago
So do some error checks. The first unit test I write for any function is that it handles arguments correctly.
- prof_hobart 13y ago
  That's great if it's your function that's the problem. Less so if it's someone else's. And it's not only these kinds of errors that can cause silent failure. I've had it on missing brackets, on missing commas, on failure to include/require the right source file etc, etc. No error message, no warning, no log entry, no nothing. Just silence. And a blank output. Not overly helpful.
- anon1385 13y ago
  But you do see why people are complaining, right? You are having to manually write thousands of tests to check something that is trivial for a compiler to check.
  - gnaritas 13y ago
    This is just an absurd complaint, it's a dynamic language, if you want compiler forced type checking, use a static language. Dynamic languages are not broken because they don't behave like static languages.
    - Peaker 13y ago
      You're missing the point. A static language catches the error at compile-time. A dynamic language catches the error at run-time. Javascript hides the error and gives a cryptic bug, instead.
      - gnaritas 13y ago
        I'm not missing the point, and I don't agree that it hides an error and gives a cryptic bug. Messing with a function signature and not updating callers of that function is not a bug in the language, it's a bug in the programmer and will result in runtime bugs in any dynamic language. If you require X number of args, then assert that they aren't undefined. If you presume callers pass in X number of args in a variable args language, and then change the required args, you're the bug, not the language.
        Peaker 13y ago
        > I'm not missing the point, and I don't agree that it hides an error and gives a cryptic bug. It hides the error by carrying on, despite having the wrong number of arguments, and executing code with thus necessarily wrong inputs. > Messing with a function signature and not updating callers of that function is not a bug in the language, it's a bug in the programmer When editing code, you routinely change the function signatures of hundreds of functions. Of course you're going to miss some, some of the time. Human errors happen, and good languages help us deal with them. Also, every time you pull code from another repository, function signatures all over the place change. Some of those may be functions your currently edited code is calling. This means every little divergence requires reviewing every single signature change or cryptic bugs will result. > and will result in runtime bugs in any dynamic language. It will result in runtime errors in dynamic languages. Errors that are visible, and difficult to ignore. That means the code gets fixed. UT triggers it trivially. Whereas with Javascript, even code under UT can easily pass accidentally when wrong numbers of arguments are used. This Dijkstra quote is relevant: > It was a significant improvement that now many a silly mistake did result in an error message instead of in an erroneous answer. (And even this improvement wasn't universally appreciated: some people found error messages they couldn't ignore more annoying than wrong results, and, when judging the relative merits of programming languages, some still seem to equate "the ease of programming" with the ease of making undetected mistakes.) > If you require X number of args, then assert that they aren't undefined That captures half of the bugs (too few arguments), for a large overhead (an extra line for almost every argument in every function). > If you presume callers pass in X number of args in a variable args language, and then change the required args, you're the bug, not the language Every time you change code, there is potential to insert bugs. Of course all bugs originate from programmer errors. The tools can work with us to find these errors and mitigate them, or they can give us hell.
- Peaker 13y ago
  So in every single function, I have to either: A) Silently ignore errors in param counts, get cryptic bugs later when a trivial merge changes a function signature, or when changing a function signature. B) Add explicit code to check the parameter counts at a huge cost (a per-function overhead!) along with extra tests for this silly thing for each and every function. This overhead is insane! I have to choose between cryptic bugs and insane overhead, all for what? So you can use "args" and not "*args"? This is a catastrophic choice for the language.

Sirenos 13y ago

> ... in other ways it necessitates more manual checking (or slower debugging). There's no catastrophe, just design differences. See, there's the problem. Glossing over issues by explaining them away as "design differences". Nothing about an expressive language necessitates making life hard for the programmer. If your function call doesn't match the signature then it is very likely to be in error, and instead of failing silently the language should make such mistakes easy to spot. I like how most other dynamic languages require you to be more explicit about function parameters (with the exception of PHP).

goblin89 13y ago
> If your function call doesn't match the signature Depending on what constitutes function signature. I agree with “design difference” argument. Someone has to make design decisions, even if someone else doesn't agree with them.
- Peaker 13y ago
  The problem is the design here is to trade errors that could be detected with cryptic bugs that can slip through. Or alternatively, adding insane per-function overhead/testing to manually cover signature checking.