4 ms·

So do some error checks. The first unit test I write for any function is that it handles arguments correctly.

by marrs 13y ago

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.
        gnaritas 13y ago
        > That captures half of the bugs (too few arguments), for a large overhead (an extra line for almost every argument in every function). You don't have to check every every arg to check the count is correct if that's something you're concerned about. Nor does checking args are undefined require a line per since you could check them all with a single assert. If you're the type who has constant bugs from wrong arg counts, use another language that better suits your programming style, but it's not a problem everyone has. And Dijkstra despised OO, and came from a much different time, I don't much care for many of his opinions. Alan Kay is more my style.
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.

So do some error checks. The first unit test I write for any function is that it handles arguments correctly.

by marrs 13y ago

So do some error checks. The first unit test I write for any function is that it handles arguments correctly.

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.
      - gnaritas 13y ago
        > That captures half of the bugs (too few arguments), for a large overhead (an extra line for almost every argument in every function). You don't have to check every every arg to check the count is correct if that's something you're concerned about. Nor does checking args are undefined require a line per since you could check them all with a single assert. If you're the type who has constant bugs from wrong arg counts, use another language that better suits your programming style, but it's not a problem everyone has. And Dijkstra despised OO, and came from a much different time, I don't much care for many of his opinions. Alan Kay is more my style.

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.