3 ms·

Because of practicality. Think of it this way, "why would you want to opt-in to better performance instead of out of it?" The main reason behind sensible defaul

Because of practicality. Think of it this way, "why would you want to opt-in to better performance instead of out of it?" The main reason behind sensible defaults is that they suit most for the best benefit. Whatever language you are familiar with, I can undoubtedly show you safer yet less convenient (and less frequently needed) ways to do things to which you could pose your same question.

kbenson 10y ago
> Think of it this way, "why would you want to opt-in to better performance instead of out of it?" Because it's unsafe some portion of the time? I don't think it's controversial to say safety should be the default, unless it imposes undue constraints. We have plenty of experience with the alternative. See C. > The main reason behind sensible defaults is that they suit most for the best benefit. Are we not talking about some small percentage of performance loss in string concatenation in exchange for a program that doesn't crash in the case it's used in a particular manner with threads? Am I misunderstanding this? > Whatever language you are familiar with, I can undoubtedly show you safer yet less convenient (and less frequently needed) ways to do things to which you could pose your same question. Yes. And when you point out where the same API exists for two constructs with different names, that achieve the same end, with small performance differences between them, and one is safe and one can possible cause the program to crash in some edge cases, I will side with the safer way as a default. It's not like we as an industry or hobby need help writing buggy software. We've accomplished that just fine for decades.
- kodablah 10y ago
  > Because it's unsafe some portion of the time? Yes, in the rare case of using string buffering across threads simultaneously. This "some" is so small as to have no practical benefits to default to the safe way. I don't know of any code that does it or would use it (and if that code did exist, you would opt in to the safety guarantees by using a different class for that rare purpose). > Are we not talking about some small percentage of performance loss in string concatenation in exchange for a program that doesn't crash in the case it's used in a particular manner with threads? Am I misunderstanding this? A bit. New code makes a conscious choice to be thread safe or not. I would not recommend anyone edit old code to improve performance. But for new code, thread safe string buffers are like thread safe anything else in the language, they are opt in because the default is assumed to not be thread safe unless you really mean it. All programming languages I know that support cross-thread racy invocations have a thread-unsafe-by-default approach to their stdlib. This is a reasonable approach/default for practical reasons. > I will side with the safer way as a default This is specifically why I used the word "practicality". In your mind I assume that there never should be such things as dynamic languages? If safety trumps all other forms of practical choice, your programming environment and library choice will be really limited. We can all theoretically tout we choose safety over everything else, but we all know we have to make practicality sacrifices for many reasons that are unrelated to safety.
  - kbenson 10y ago
    > In your mind I assume that there never should be such things as dynamic languages? In what way are dynamic languages "unsafe"? To be clear, what I mean here by unsafe, and everywhere I've used the word, is "can cause a crash or memory corruption", which I consider different than "not the output I expected", such as weird order of operations. Can using one over the other cause a Java program to crash in certain circumstances? Then I advise the one with the possibility to crash not be the default, if at all possible. Is it extremely rare that it could cause a crash? Are we sure that will always remain the case? Could interesting developments later on the JVM make it markedly less rare (maybe some auto-threading loop constructs)? Perhaps we shouldn't use current common current behavior as a justification for what will be safe in the future? Is it not a case of actual crashing or corruption, and just a non-intuitive ordering of operations than someone might expect? Well then we aren't really talking about the same thing at all, and I don't really care as much what the default should be, as a matter of industry best practices.
    - jdmichal 10y ago
      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.
        10y ago

kbenson 10y ago

> Think of it this way, "why would you want to opt-in to better performance instead of out of it?" Because it's unsafe some portion of the time? I don't think it's controversial to say safety should be the default, unless it imposes undue constraints. We have plenty of experience with the alternative. See C. > The main reason behind sensible defaults is that they suit most for the best benefit. Are we not talking about some small percentage of performance loss in string concatenation in exchange for a program that doesn't crash in the case it's used in a particular manner with threads? Am I misunderstanding this? > Whatever language you are familiar with, I can undoubtedly show you safer yet less convenient (and less frequently needed) ways to do things to which you could pose your same question. Yes. And when you point out where the same API exists for two constructs with different names, that achieve the same end, with small performance differences between them, and one is safe and one can possible cause the program to crash in some edge cases, I will side with the safer way as a default. It's not like we as an industry or hobby need help writing buggy software. We've accomplished that just fine for decades.

kodablah 10y ago
> Because it's unsafe some portion of the time? Yes, in the rare case of using string buffering across threads simultaneously. This "some" is so small as to have no practical benefits to default to the safe way. I don't know of any code that does it or would use it (and if that code did exist, you would opt in to the safety guarantees by using a different class for that rare purpose). > Are we not talking about some small percentage of performance loss in string concatenation in exchange for a program that doesn't crash in the case it's used in a particular manner with threads? Am I misunderstanding this? A bit. New code makes a conscious choice to be thread safe or not. I would not recommend anyone edit old code to improve performance. But for new code, thread safe string buffers are like thread safe anything else in the language, they are opt in because the default is assumed to not be thread safe unless you really mean it. All programming languages I know that support cross-thread racy invocations have a thread-unsafe-by-default approach to their stdlib. This is a reasonable approach/default for practical reasons. > I will side with the safer way as a default This is specifically why I used the word "practicality". In your mind I assume that there never should be such things as dynamic languages? If safety trumps all other forms of practical choice, your programming environment and library choice will be really limited. We can all theoretically tout we choose safety over everything else, but we all know we have to make practicality sacrifices for many reasons that are unrelated to safety.
- kbenson 10y ago
  > In your mind I assume that there never should be such things as dynamic languages? In what way are dynamic languages "unsafe"? To be clear, what I mean here by unsafe, and everywhere I've used the word, is "can cause a crash or memory corruption", which I consider different than "not the output I expected", such as weird order of operations. Can using one over the other cause a Java program to crash in certain circumstances? Then I advise the one with the possibility to crash not be the default, if at all possible. Is it extremely rare that it could cause a crash? Are we sure that will always remain the case? Could interesting developments later on the JVM make it markedly less rare (maybe some auto-threading loop constructs)? Perhaps we shouldn't use current common current behavior as a justification for what will be safe in the future? Is it not a case of actual crashing or corruption, and just a non-intuitive ordering of operations than someone might expect? Well then we aren't really talking about the same thing at all, and I don't really care as much what the default should be, as a matter of industry best practices.
  - jdmichal 10y ago
    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.
      - 10y ago