3 ms·

Even if I think that Guy Steele is a genius, an argument of authority is always a bad argument. Better listening to the foot soldiers than staying in your high

Even if I think that Guy Steele is a genius, an argument of authority is always a bad argument. Better listening to the foot soldiers than staying in your high tower. Using '\' instead of '$' does not allow $variable as a shortcut to ${variable} making the syntax objectively harder to read. Using '\' cleverly helps to detect when the processor is missing at compile time but it does not matter because the syntax mandates a big STR in front.

pron 3y ago
> an argument of authority is always a bad argument True, but so was the argument I responded to (JS did it differently) and this is, after all, the internet. But there was also another point I was trying to make, which is that some people seem to have it as their null hypothesis that Java's designers get things wrong or don't do what the people want even though they are not only among the most experienced language designers around but also among the most consistently successful, and usually by a pretty wide margin. I think that means that at the very least they deserve the benefit of the doubt and perhaps another moment of contemplation. > Better listening to the foot soldiers than staying in your high tower. Which is why the designers didn't just trust their guts and experience, but designed the feature in an iterative process with actual "foot soldiers" trying it out (as most new Java features are designed, and as the Preview process was created to support). The criticism, on the other hand, seems to mostly come from people who have not actually tried it out, and it is they who are staying in their high tower. When designing new Java features and asking for feedback we always emphasise that speculating is something anyone can do, and what we need is people trying out the prototype or preview and reporting on their actual experience. Such feedback is always valuable and taken seriously. On the other hand, speculation offered by people who have both given the matter less thought and who have had less experience with the feature than its designers is usually not very useful. It is really very easy for a Java programmer to have an actual impact on the design of new features: Step 1 — try the feature for a while in EA or in Preview; step 2 — report on your experiences to the mailing list. If someone can't even spend the time to do that, how can we know that they've spent more than 30 minutes thinking about the problem before sharing their speculation that we must have done something wrong? Now, it is true that while we know that string interpolation is problematic, we can only speculate that offering it only as a special case of string templates would improve matters. But we figured that if, despite our analysis, we end up being proved wrong, it would be an easy matter to also offer string interpolation as a language feature (e.g. by making it the default processor). > Using '\' instead of '$' does not allow $variable as a shortcut to ${variable} making the syntax objectively harder to read. Python (f-strings), JS, C#, and Ruby -- the most popular language that have had either string interpolation and/or string templates before Java -- also don't allow for such a shortcut (I believe the only top language that does support this shortcut is PHP), and if quite a few language designers didn't think that the shortcut was a significant advantage I don't know how "objective" you can claim it to be. $ also creates some other difficulties, as it is quite common in Java templating libraries (even in JS, the syntax used by templating libraries differs from that used by the language, otherwise it causes bigger annoyances). It would mean that $ would need to be escaped in some contexts and not in others, making adoption of the feature less smooth than we'd want (see https://mail.openjdk.org/pipermail/amber-spec-experts/2023-April/003827.html https://mail.openjdk.org/pipermail/amber-spec-experts/2023-A...). > Using '\' cleverly helps to detect when the processor is missing at compile time but it does not matter because the syntax mandates a big STR in front. Like all instance calls in Java, this instance call also mandates a receiver; it's not some special prefix. If you don't like the "big" STR you can assign that particular template processor object a different name, including one named `$` if you like, because that's a valid Java identifier. I.e. you can do: var $ = STR; $."Hello \{x}!"
- _old_dude_ 3y ago
  We had high hope that unlike SUN, Oracle will listen. > Iterative process please send a link to a video of a designer from Oracle presenting the string templates at a conference. This is not Loom, there is no iterative process. > Python, JS, and C# also don't allow for such a shortcut The syntax of C# or Python is also lightweight, fine by me. > it's not some special prefix I get that, but not using a constant like STR is an anti-pattern, as you said it's a virtual method call. > The criticism, on the other hand, seems to mostly come from people who have not actually tried it out Ask designers to go to conferences and you will get real feedback.
  - pron 3y ago
    > We had high hope that unlike SUN, Oracle will listen. Sorry to disappoint (or not) but much of the technical leadership are the same people... > please send a link to a video of a designer from Oracle presenting the string templates at a conference. How about not one video but two, not of any designer but of the chief language designer talking about the feature not at any conference but at what is probably the biggest Java conference? https://youtu.be/TIHx6MNt79Y?si=Qwj0ER-yxlS-Flxq&t=1972 https://youtu.be/TIHx6MNt79Y?si=Qwj0ER-yxlS-Flxq&t=1972 https://youtu.be/DlTUMjg7DD0?si=6urFyuyF_jCtZ0H-&t=1099 https://youtu.be/DlTUMjg7DD0?si=6urFyuyF_jCtZ0H-&t=1099 > This is not Loom, there is no iterative process a. you're wrong — the discussion and iteration have taken place on the amber-dev and the amber-spec-experts mailing lists — and b. I've received my share of accusations of "not listening" (and sometimes even worse) on Loom. It may not have been from you, though. :) As always, feedback that follows actual usage is taken very seriously and has a significant impact. You're right, however, that it's a much smaller feature than virtual threads, and so the public part of the design process didn't last for over four years but only for a little over two years (https://mail.openjdk.org/pipermail/amber-dev/2021-September/007076.html https://mail.openjdk.org/pipermail/amber-dev/2021-September/..., https://github.com/openjdk/amber-docs/blob/master/site/design-notes/templated-strings.md https://github.com/openjdk/amber-docs/blob/master/site/desig...). > The syntax of C# or Python is also lightweight, fine by me. Python has string interpolation but doesn't have string templates; Java has string templates but doesn't have string interpolation as a language feature. You're comparing syntax for two different features. As for C#, Java-like string templates can be mimicked [1], but the syntax isn't really lighter-weight. Instead of `SQL."SELECT * FROM SomeTable WHERE Age = \{age} AND Name = \{name}"` you'd write `SQL($"SELECT * FROM SomeTable WHERE Age = {age} AND Name = {name}")`; note that the method call to SQL is necessary to get a similar feature to Java's. > I get that, but not using a constant like STR is an anti-pattern, as you said it's a virtual method call. It's just a final field. You can do `final StringTemplate.Processor<String, RuntimeException> $ = STR;` and it's just as much of a "constant" as STR is. Of course, whether or not you should make string interpolation easier is up to you; after all, the reason we didn't add string interpolation to the language is because we think that making it easier is a bad idea given the vulnerabilities it has caused. > Ask designers to go to conferences and you will get real feedback. But they do. But just to clarify, feedback about a feature is from people who've actually used it; otherwise it's just a speculative opinion. [1]: https://bengribaudo.com/blog/2021/04/13/5596/intercepting-string-interpolation https://bengribaudo.com/blog/2021/04/13/5596/intercepting-st...

pron 3y ago

> an argument of authority is always a bad argument True, but so was the argument I responded to (JS did it differently) and this is, after all, the internet. But there was also another point I was trying to make, which is that some people seem to have it as their null hypothesis that Java's designers get things wrong or don't do what the people want even though they are not only among the most experienced language designers around but also among the most consistently successful, and usually by a pretty wide margin. I think that means that at the very least they deserve the benefit of the doubt and perhaps another moment of contemplation. > Better listening to the foot soldiers than staying in your high tower. Which is why the designers didn't just trust their guts and experience, but designed the feature in an iterative process with actual "foot soldiers" trying it out (as most new Java features are designed, and as the Preview process was created to support). The criticism, on the other hand, seems to mostly come from people who have not actually tried it out, and it is they who are staying in their high tower. When designing new Java features and asking for feedback we always emphasise that speculating is something anyone can do, and what we need is people trying out the prototype or preview and reporting on their actual experience. Such feedback is always valuable and taken seriously. On the other hand, speculation offered by people who have both given the matter less thought and who have had less experience with the feature than its designers is usually not very useful. It is really very easy for a Java programmer to have an actual impact on the design of new features: Step 1 — try the feature for a while in EA or in Preview; step 2 — report on your experiences to the mailing list. If someone can't even spend the time to do that, how can we know that they've spent more than 30 minutes thinking about the problem before sharing their speculation that we must have done something wrong? Now, it is true that while we know that string interpolation is problematic, we can only speculate that offering it only as a special case of string templates would improve matters. But we figured that if, despite our analysis, we end up being proved wrong, it would be an easy matter to also offer string interpolation as a language feature (e.g. by making it the default processor). > Using '\' instead of '$' does not allow $variable as a shortcut to ${variable} making the syntax objectively harder to read. Python (f-strings), JS, C#, and Ruby -- the most popular language that have had either string interpolation and/or string templates before Java -- also don't allow for such a shortcut (I believe the only top language that does support this shortcut is PHP), and if quite a few language designers didn't think that the shortcut was a significant advantage I don't know how "objective" you can claim it to be. $ also creates some other difficulties, as it is quite common in Java templating libraries (even in JS, the syntax used by templating libraries differs from that used by the language, otherwise it causes bigger annoyances). It would mean that $ would need to be escaped in some contexts and not in others, making adoption of the feature less smooth than we'd want (see https://mail.openjdk.org/pipermail/amber-spec-experts/2023-April/003827.html https://mail.openjdk.org/pipermail/amber-spec-experts/2023-A...). > Using '\' cleverly helps to detect when the processor is missing at compile time but it does not matter because the syntax mandates a big STR in front. Like all instance calls in Java, this instance call also mandates a receiver; it's not some special prefix. If you don't like the "big" STR you can assign that particular template processor object a different name, including one named `$` if you like, because that's a valid Java identifier. I.e. you can do: var $ = STR; $."Hello \{x}!"

_old_dude_ 3y ago
We had high hope that unlike SUN, Oracle will listen. > Iterative process please send a link to a video of a designer from Oracle presenting the string templates at a conference. This is not Loom, there is no iterative process. > Python, JS, and C# also don't allow for such a shortcut The syntax of C# or Python is also lightweight, fine by me. > it's not some special prefix I get that, but not using a constant like STR is an anti-pattern, as you said it's a virtual method call. > The criticism, on the other hand, seems to mostly come from people who have not actually tried it out Ask designers to go to conferences and you will get real feedback.
- pron 3y ago
  > We had high hope that unlike SUN, Oracle will listen. Sorry to disappoint (or not) but much of the technical leadership are the same people... > please send a link to a video of a designer from Oracle presenting the string templates at a conference. How about not one video but two, not of any designer but of the chief language designer talking about the feature not at any conference but at what is probably the biggest Java conference? https://youtu.be/TIHx6MNt79Y?si=Qwj0ER-yxlS-Flxq&t=1972 https://youtu.be/TIHx6MNt79Y?si=Qwj0ER-yxlS-Flxq&t=1972 https://youtu.be/DlTUMjg7DD0?si=6urFyuyF_jCtZ0H-&t=1099 https://youtu.be/DlTUMjg7DD0?si=6urFyuyF_jCtZ0H-&t=1099 > This is not Loom, there is no iterative process a. you're wrong — the discussion and iteration have taken place on the amber-dev and the amber-spec-experts mailing lists — and b. I've received my share of accusations of "not listening" (and sometimes even worse) on Loom. It may not have been from you, though. :) As always, feedback that follows actual usage is taken very seriously and has a significant impact. You're right, however, that it's a much smaller feature than virtual threads, and so the public part of the design process didn't last for over four years but only for a little over two years (https://mail.openjdk.org/pipermail/amber-dev/2021-September/007076.html https://mail.openjdk.org/pipermail/amber-dev/2021-September/..., https://github.com/openjdk/amber-docs/blob/master/site/design-notes/templated-strings.md https://github.com/openjdk/amber-docs/blob/master/site/desig...). > The syntax of C# or Python is also lightweight, fine by me. Python has string interpolation but doesn't have string templates; Java has string templates but doesn't have string interpolation as a language feature. You're comparing syntax for two different features. As for C#, Java-like string templates can be mimicked [1], but the syntax isn't really lighter-weight. Instead of `SQL."SELECT * FROM SomeTable WHERE Age = \{age} AND Name = \{name}"` you'd write `SQL($"SELECT * FROM SomeTable WHERE Age = {age} AND Name = {name}")`; note that the method call to SQL is necessary to get a similar feature to Java's. > I get that, but not using a constant like STR is an anti-pattern, as you said it's a virtual method call. It's just a final field. You can do `final StringTemplate.Processor<String, RuntimeException> $ = STR;` and it's just as much of a "constant" as STR is. Of course, whether or not you should make string interpolation easier is up to you; after all, the reason we didn't add string interpolation to the language is because we think that making it easier is a bad idea given the vulnerabilities it has caused. > Ask designers to go to conferences and you will get real feedback. But they do. But just to clarify, feedback about a feature is from people who've actually used it; otherwise it's just a speculative opinion. [1]: https://bengribaudo.com/blog/2021/04/13/5596/intercepting-string-interpolation https://bengribaudo.com/blog/2021/04/13/5596/intercepting-st...