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.
> ... 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).
> 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.
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.
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.
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.
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"?
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.
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.
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.
> 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.
> 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.
> 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.
That's true, but the overhead is still relatively huge.
> 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
I'm the type of programmer who tries to avoid errors as much as I can, but still make them as I am human, as we all are.
One of the possible errors that's really easy to make is forgetting to grep for callers of a function you just changed. Of course 99 out of 100 times you remember, but 1 out of 100 you will forget.
Another possible error is remembering to change the function signature, but just having a typo or mistake.
And finally, even if you make no errors at all -- when you pull from the server you get a bunch of function signatures and calls changed "under you feet", so any changes you had already pending (perhaps in different files) are now potentially silently invalidated, and there won't even be a runtime error to tell you about them.
There is really no real benefit to this behavior at all (beyond backwards compatibility of course). Explicit rest-of-args cost nothing.
Error messages are superior to wrong behavior, and this behavior is simply insane.
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.