> ... 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.
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).