4 ms·

Because dynamic languages by definition don't stop you from doing silly things like: Math.floor("banana") They might attempt to provide a sensible answer,

Because dynamic languages by definition don't stop you from doing silly things like: Math.floor("banana") They might attempt to provide a sensible answer, such as NaN if I run the above in JavaScript. But that operation doesn't really have a sensible semantic definition and the choice to return NaN instead of crashing is somewhat arbitrary.

dragonwriter 10y ago
I don't know, treating anything that is not a number as NaN (and mathematical operations on it as producing NaN) seems to be exactly semantically correct. I mean, really, all NaN is in any language is a signal that a mathematical operation was used with a set of inputs for which the operation does not produce a defined numerical result. In a sense, this is always a sign of an insufficiently expressive type system that can't prevent you from feeding a bad value (or bad combination of values) to the operation.
- jdmichal 10y ago
  I said it was a sensible response to a non-sensible operation. The operation of flooring "banana" is not semantically-correct. The fact that IEEE floating point numbers happens to have a value that provides a sensible result to this operation is a bit of a fluke. What if the return value was an integer type, which is perfectly valid considering that the floor operation always provides an integer result?
  - kbenson 10y ago
    What is sensible is first based on the language definition, not your opinion. If the language defines it explicitly and has well defined rules, there's nothing non-sensible about it. Consider the following, which fall well within the definition of how Perl handles implicit conversion of strings to numeric types, and is well known to Perl programmers: # perl -E 'say "1zero"+0 ' 1 # perl -E 'say "zero1"+0 ' 0
    - jdmichal 10y ago
      No, I'm pretty sure that the question "what's the mathematical floor of banana" doesn't make any sense, no matter what the language definition is. The fact that some (dynamic) languages even allow you to ask the question is the entire point being made by kodablah in regards to typing as a safety mechanism. The fact that some smaller subset of languages even attempt (and fail) to make sense of the operation (weak typing) is just diving straight off the deep-end of safety.
      - kbenson 10y ago
        I'm not sure there's a point in continuing this when I've defined, multiple times, the definition of safety I'm working under for the purposes of this discussion and my point, and you willfully ignore it to argue something entirely different time and again. I'm not interesting in discussing the merits of dynamic vs static languages, nor weak vs strong typing, when this started out as if you have a language feature that might cause a crash under normal, expected allowed behavior within the language, and one that will not cause a crash a a very small performance draw for that specific operation, I think defaulting to the non-crashing operation is the correct choice. Feel free to speak to that point if you would like to continue, because I don't see how the current tangent applies.
        jdmichal 10y ago
        The entire point of this "tangent" (which it isn't) is that the same reason you would make the choice to use the "unsafe" variant are the same reasons you would argue to not use a type-safe language. Or, rather, if you're default inclination is to always choose safety over other factors, then why not apply the same logic to languages? The fact is that you seem to be drawing an arbitrary line at language-use in your logic here.
kbenson 10y ago
That expressly ignores what I set up as my criteria, so I'm unsure why you presented this. Even if that does cause a crash, which is entirely dependent on the language, I think there's a clear delineation of whether something can be expected to crash or not based on the opt-in assumptions of the language you choose. If your language is not type-safe, you've already accepted that as a constraint ("types may not help you"). Should we expect addition to be implemented in some way that causes problems within the constraints you've already accepted? I think not. Here's two specific examples of dynamic languages, one weakly typed (Perl), one strongly typed (Python), and how they are internally consistent. # perl -E 'say 1 + "2" + "four" + 8' 11 # python -c 'say 1 + "2" + "four" + 8' File "<string>", line 1 say 1 + "2" + "four" + 8 ^ SyntaxError: invalid syntax Each makes it clear what you can expect up-front. If python could occasionally crash from addition of two integers, or Perl would occasionally interpret an all alpha string as non-empty in numeric context, all for the name of being slightly faster, I would consider that the wrong thing to do as well. (Note: There are rules for how mixed alphanumeric strings are interpreted in Perl, but they are well defined).
- jdmichal 10y ago
  > I think there's a clear delineation of whether something can be expected to crash or not based on the opt-in assumptions of the language you choose. I can say exactly the same thing about StringBuffer vs StringBuilder, with the obvious substitution for the word "language". The point of kodablah's post is that, if your stance is that safety should always be chosen over other practical concerns, then a natural conclusion is that you should by default be opposed to dynamic languages, as they trade type safety for programmer comfort (for lack of a better term). EDIT: I also want to point out that "crashing" vs throwing an error is not a distinction worth making for this conversation. If your program stops executing for any reason that could be prevented by a type-checking system, then it seems reasonable to call a type-checking system a safety feature.
  - kbenson 10y ago
    > I can say exactly the same thing about StringBuffer vs StringBuilder, with the obvious substitution for the word "language". Sure. And if you think the the difference in developer efficiency between a dynamic language and a static one is less than 10%, but when the gains are small, as has been shown in the linked article, then why pay the cost of possible program failure for a less than 10% gain in string concatenation speed when you probably won't event see it? > I also want to point out that "crashing" vs throwing an error is not a distinction worth making for this conversation. If your program stops executing for any reason that could be prevented by a type-checking system, then it seems reasonable to call a type-checking system a safety feature. I disagree. Exceptions which can be caught are not comparable to memory corruption, unless you can ensure the corruption can not cause a segmentation fault (which may be the case here, I have no idea). Nobody seems to be answering my question as to what type of problem the threading error is limited to in Java. I've made clear that any objection I have to the default is moot based on possible assurances that the JVM might provide, but I haven't had anyone clarify.

dragonwriter 10y ago

I don't know, treating anything that is not a number as NaN (and mathematical operations on it as producing NaN) seems to be exactly semantically correct. I mean, really, all NaN is in any language is a signal that a mathematical operation was used with a set of inputs for which the operation does not produce a defined numerical result. In a sense, this is always a sign of an insufficiently expressive type system that can't prevent you from feeding a bad value (or bad combination of values) to the operation.

jdmichal 10y ago
I said it was a sensible response to a non-sensible operation. The operation of flooring "banana" is not semantically-correct. The fact that IEEE floating point numbers happens to have a value that provides a sensible result to this operation is a bit of a fluke. What if the return value was an integer type, which is perfectly valid considering that the floor operation always provides an integer result?
- kbenson 10y ago
  What is sensible is first based on the language definition, not your opinion. If the language defines it explicitly and has well defined rules, there's nothing non-sensible about it. Consider the following, which fall well within the definition of how Perl handles implicit conversion of strings to numeric types, and is well known to Perl programmers: # perl -E 'say "1zero"+0 ' 1 # perl -E 'say "zero1"+0 ' 0
  - jdmichal 10y ago
    No, I'm pretty sure that the question "what's the mathematical floor of banana" doesn't make any sense, no matter what the language definition is. The fact that some (dynamic) languages even allow you to ask the question is the entire point being made by kodablah in regards to typing as a safety mechanism. The fact that some smaller subset of languages even attempt (and fail) to make sense of the operation (weak typing) is just diving straight off the deep-end of safety.
    - kbenson 10y ago
      I'm not sure there's a point in continuing this when I've defined, multiple times, the definition of safety I'm working under for the purposes of this discussion and my point, and you willfully ignore it to argue something entirely different time and again. I'm not interesting in discussing the merits of dynamic vs static languages, nor weak vs strong typing, when this started out as if you have a language feature that might cause a crash under normal, expected allowed behavior within the language, and one that will not cause a crash a a very small performance draw for that specific operation, I think defaulting to the non-crashing operation is the correct choice. Feel free to speak to that point if you would like to continue, because I don't see how the current tangent applies.
      - jdmichal 10y ago
        The entire point of this "tangent" (which it isn't) is that the same reason you would make the choice to use the "unsafe" variant are the same reasons you would argue to not use a type-safe language. Or, rather, if you're default inclination is to always choose safety over other factors, then why not apply the same logic to languages? The fact is that you seem to be drawing an arbitrary line at language-use in your logic here.

kbenson 10y ago

That expressly ignores what I set up as my criteria, so I'm unsure why you presented this. Even if that does cause a crash, which is entirely dependent on the language, I think there's a clear delineation of whether something can be expected to crash or not based on the opt-in assumptions of the language you choose. If your language is not type-safe, you've already accepted that as a constraint ("types may not help you"). Should we expect addition to be implemented in some way that causes problems within the constraints you've already accepted? I think not. Here's two specific examples of dynamic languages, one weakly typed (Perl), one strongly typed (Python), and how they are internally consistent. # perl -E 'say 1 + "2" + "four" + 8' 11 # python -c 'say 1 + "2" + "four" + 8' File "<string>", line 1 say 1 + "2" + "four" + 8 ^ SyntaxError: invalid syntax Each makes it clear what you can expect up-front. If python could occasionally crash from addition of two integers, or Perl would occasionally interpret an all alpha string as non-empty in numeric context, all for the name of being slightly faster, I would consider that the wrong thing to do as well. (Note: There are rules for how mixed alphanumeric strings are interpreted in Perl, but they are well defined).

jdmichal 10y ago
> I think there's a clear delineation of whether something can be expected to crash or not based on the opt-in assumptions of the language you choose. I can say exactly the same thing about StringBuffer vs StringBuilder, with the obvious substitution for the word "language". The point of kodablah's post is that, if your stance is that safety should always be chosen over other practical concerns, then a natural conclusion is that you should by default be opposed to dynamic languages, as they trade type safety for programmer comfort (for lack of a better term). EDIT: I also want to point out that "crashing" vs throwing an error is not a distinction worth making for this conversation. If your program stops executing for any reason that could be prevented by a type-checking system, then it seems reasonable to call a type-checking system a safety feature.
- kbenson 10y ago
  > I can say exactly the same thing about StringBuffer vs StringBuilder, with the obvious substitution for the word "language". Sure. And if you think the the difference in developer efficiency between a dynamic language and a static one is less than 10%, but when the gains are small, as has been shown in the linked article, then why pay the cost of possible program failure for a less than 10% gain in string concatenation speed when you probably won't event see it? > I also want to point out that "crashing" vs throwing an error is not a distinction worth making for this conversation. If your program stops executing for any reason that could be prevented by a type-checking system, then it seems reasonable to call a type-checking system a safety feature. I disagree. Exceptions which can be caught are not comparable to memory corruption, unless you can ensure the corruption can not cause a segmentation fault (which may be the case here, I have no idea). Nobody seems to be answering my question as to what type of problem the threading error is limited to in Java. I've made clear that any objection I have to the default is moot based on possible assurances that the JVM might provide, but I haven't had anyone clarify.