3 ms·

I’m not a fan of the special `log.info."x: \{x}";` syntax, it looks like a weird mix of field access and a string literal. And even with the fancy new syntax,

I’m not a fan of the special `log.info."x: \{x}";` syntax, it looks like a weird mix of field access and a string literal. And even with the fancy new syntax, I’m sure there will be people passing STR."SELECT * FROM x WHERE y = \{y}" to their database. You can educate people all you want, but not all developers will read the docs telling them this is dangerous. Even if all the docs do the right thing, people might end up reading old tutorials, and will then notice the “inefficiency” of the prepared statement syntax and will just do a STR."" format. Or they might consider the database.executeQuery."SELECT \{x}"; syntax “invalid” and try to fix it.

pron 4y ago
Well, you know, even thirty years of experience as the custodians of one of the most successful programming languages is no guarantee of success with every feature, but that's why we have the preview process now that lets us figure out what problems people actually encounter -- which may well be different from the problems they, or we, think they would encounter -- before finalising the feature. Just remember that you can't pass a string to an API that doesn't take strings, and even with existing APIs, methods that take strings can be deprecated to cause compiler warnings. So sometimes there are stronger ways than just documentation to discourage dangerous code.
- avgcorrection 4y ago
  If I had a cent for every time pron appealed to Java’s age and “popularity” in technical arguments, I would have at least enough cents to use a dollar-sign in string template syntax.
  - pron 4y ago
    That's cute, but that appeal is crucial because technical arguments that are divorced from empirical results in the field are a great way to spend a lot of time solving the wrong problems. For example, you can make technical arguments in favour of either VHS or Betamax, but while they both had superior solutions to two separate technical problems, one of those problems (recording time) ended up being a much more important one for more people than the other. The purpose of engineering is not to enjoy intellectual puzzles, but to solve problems for people. You can only insist that the team that's at or near the top of the charts for so many years don't know what they're doing so many times. After a while, you may want to reconsider your beliefs about what the right approach is. Those who misunderstand that will forever be puzzled by why it is that the VHSes usually win over the Betamaxes, and will continue betting on the wrong horses. The relatively new concept of preview features helps us gather information on what problems people actually encounter when working with a new feature as opposed to what problems some speculate they'll run into. The best way to influence Java's direction is not to speculate, but to report problems you've actually encountered to the relevant OpenJDK mailing list (amber-dev in this case). If the use of the \ or $ character turns out to be a real problem, we expect to find that out during the preview process (which will begin in JDK 21, out this September) and we'll reconsider, only we'll do it based on reports, not speculation.
    - avgcorrection 4y ago
      Well, I’ll agree that one shouldn’t be naive about the “technically superior” arguments. One has to look at why certain things succeeded. In an honest and non-ideological way (e.g. don’t blind yourself on the “technically superior” talking points, whatever that means). I don’t really have a problem with a backslash over a dollar-sign. I just couldn’t resist...

pron 4y ago

Well, you know, even thirty years of experience as the custodians of one of the most successful programming languages is no guarantee of success with every feature, but that's why we have the preview process now that lets us figure out what problems people actually encounter -- which may well be different from the problems they, or we, think they would encounter -- before finalising the feature. Just remember that you can't pass a string to an API that doesn't take strings, and even with existing APIs, methods that take strings can be deprecated to cause compiler warnings. So sometimes there are stronger ways than just documentation to discourage dangerous code.

avgcorrection 4y ago
If I had a cent for every time pron appealed to Java’s age and “popularity” in technical arguments, I would have at least enough cents to use a dollar-sign in string template syntax.
- pron 4y ago
  That's cute, but that appeal is crucial because technical arguments that are divorced from empirical results in the field are a great way to spend a lot of time solving the wrong problems. For example, you can make technical arguments in favour of either VHS or Betamax, but while they both had superior solutions to two separate technical problems, one of those problems (recording time) ended up being a much more important one for more people than the other. The purpose of engineering is not to enjoy intellectual puzzles, but to solve problems for people. You can only insist that the team that's at or near the top of the charts for so many years don't know what they're doing so many times. After a while, you may want to reconsider your beliefs about what the right approach is. Those who misunderstand that will forever be puzzled by why it is that the VHSes usually win over the Betamaxes, and will continue betting on the wrong horses. The relatively new concept of preview features helps us gather information on what problems people actually encounter when working with a new feature as opposed to what problems some speculate they'll run into. The best way to influence Java's direction is not to speculate, but to report problems you've actually encountered to the relevant OpenJDK mailing list (amber-dev in this case). If the use of the \ or $ character turns out to be a real problem, we expect to find that out during the preview process (which will begin in JDK 21, out this September) and we'll reconsider, only we'll do it based on reports, not speculation.
  - avgcorrection 4y ago
    Well, I’ll agree that one shouldn’t be naive about the “technically superior” arguments. One has to look at why certain things succeeded. In an honest and non-ideological way (e.g. don’t blind yourself on the “technically superior” talking points, whatever that means). I don’t really have a problem with a backslash over a dollar-sign. I just couldn’t resist...