4 ms·

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

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.

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.