It is true. Math.min() returns positive Infinity when called with no arguments and Math.max() returns Negative Infinity when called with no arguments. Positive Infinity > Negative Infinity.
Math.min() works something like this
defmin(numbers):
r = Infinity
for n in numbers:
if n < r:
r = n
return r
I’m guessing there’s a reason they wanted min() to be able to be called without any arguments but I’m sure it isn’t a good one.
I’m guessing there’s a reason they wanted min() to be able to be called without any arguments but I’m sure it isn’t a good one.
It not a totally unreasonable definition. For example it preserves nice properties like min(a.concat(b)) == min([min(a), min(b)]).
Obviously the correct thing to do is to return an optional type, like Rust does. But … yeah I mean considering the other footguns in Javascript (e.g. the insane implicit type coersion) I’d say they didn’t do too badly here.
So, the language isn’t compiled (or wasn’t originally) so they couldn’t make min() be an error that only a developer saw, it has to be something that the runtime on the end-user system dealt with. So, it had to be assigned some value. Under those restrictions, it is the most mathematically sound value. It makes miniumum-exactly-2(x, min(<…>)) be exactly the same as min(x, <…>), even when the “<…>” has no values.
As a developer, I see a lot of value in static analysis, including refusing to generate output for sufficiently erroneous results of static analysis, so I don’t like using JS, and the language that I tinker with will definitely have a separate compilation step and reject the equivalent of min(). But, if I HAD to assign something like that a value, it probably would be a representation of infinity, if we had one (probably will due to IEEE floats).
The language not being compiled has nothing to do with error handling. You could have a min function that operates on dynamic arrays (e.g. std::min_element in C++ or min() in Python).
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.
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.
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.
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.
It is true. Math.min() returns positive Infinity when called with no arguments and Math.max() returns Negative Infinity when called with no arguments. Positive Infinity > Negative Infinity.
Math.min() works something like this
def min(numbers): r = Infinity for n in numbers: if n < r: r = n return rI’m guessing there’s a reason they wanted min() to be able to be called without any arguments but I’m sure it isn’t a good one.
It not a totally unreasonable definition. For example it preserves nice properties like
min(a.concat(b)) == min([min(a), min(b)]).Obviously the correct thing to do is to return an optional type, like Rust does. But … yeah I mean considering the other footguns in Javascript (e.g. the insane implicit type coersion) I’d say they didn’t do too badly here.
So, the language isn’t compiled (or wasn’t originally) so they couldn’t make
min()be an error that only a developer saw, it has to be something that the runtime on the end-user system dealt with. So, it had to be assigned some value. Under those restrictions, it is the most mathematically sound value. It makes miniumum-exactly-2(x, min(<…>)) be exactly the same as min(x, <…>), even when the “<…>” has no values.As a developer, I see a lot of value in static analysis, including refusing to generate output for sufficiently erroneous results of static analysis, so I don’t like using JS, and the language that I tinker with will definitely have a separate compilation step and reject the equivalent of
min(). But, if I HAD to assign something like that a value, it probably would be a representation of infinity, if we had one (probably will due to IEEE floats).HTH
The language not being compiled has nothing to do with error handling. You could have a
minfunction that operates on dynamic arrays (e.g. std::min_element in C++ or min() in Python).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.
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.
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.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.