- cross-posted to:
- programmerhumor@lemmy.ml
- cross-posted to:
- programmerhumor@lemmy.ml
Not having a separate compilation step absolutely affects error handling. With a compilation step, you can have errors that will only be seen by and must be address by a developer prior to run time. Without one, the run time system, must assign some semantics to the source code, no matter how erroneous it is.
No matter what advisory “signature” you imagine for a function, JS has to assign some run time semantics to that function being called incorrectly. Compiled languages do not have to provide a run time semantics to for signatures that can be statically checked.
I agree, compiled languages prevent large classes of errors, including invoking functions with wrong parameters. However, whether or not you define calling max() with no arguments to be an error or not is unrelated to your language being compiled or interpreted. You could define max() to be -inf in C++ if you wanted, even though the language allows you to prevent invocations of max() with no arguments altogether.
The run time still has to assign a semantics to it, even if that semantics is a fatal error. In a compiled language, you can prevent the run time from having to assign any semantics by eliminating the error condition at compile time.
Without one, the run time system, must assign some semantics to the source code, no matter how erroneous it is.
That’s just not true; as the comment above points out, Python also has no separate compilation step and yet it did not adopt this philosophy. Interpeted languages were common before JavaScript; in fact, most LISP variants are interpreted, and LISP is older than C.
Moreover, even JavaScript does sometimes throw errors, because sometimes code is simply not valid syntactically, or has no valid semantics even in a language as permissive as JavaScript.
So Eich et al. absolutely could have made more things invalid, despite the risk that end-users would see the resulting error.
Python also has no separate compilation step and yet it did not adopt this philosophy
Yes. It did. It didn’t assign exactly the same semantics, but it DOES assign a run time semantic to
min()
.I’m addressing the bit that I quoted, saying that an interpreted language “must” have valid semantics for all code. I’m not specifically addressing whether or not JavaScript is right in this particular case of
min()
.…but also, what are you talking about? Python throws a type error if you call
min()
with no argument.