Hacker News Reader

Comment by shortrounddev2 | Hacker News Reader

Oracle managed to create one of the least ergonomic string interpolation syntaxes of any language I've ever seen. Using backslashes is truly a terrible move

View on HN

In the JEP (https://openjdk.org/jeps/430) there is a bunch of prior art:

    C#             $"{x} plus {y} equals {x + y}"
    Visual Basic   $"{x} plus {y} equals {x + y}"
    Python         f"{x} plus {y} equals {x + y}"
    Scala          s"$x plus $y equals ${x + y}"
    Groovy         "$x plus $y equals ${x + y}"
    Kotlin         "$x plus $y equals ${x + y}"
    JavaScript     `${x} plus ${y} equals ${x + y}`
    Ruby           "#{x} plus #{y} equals #{x + y}"
    Swift          "\(x) plus \(y) equals \(x + y)"

Is any of those actually better? You have a non-existing better suggestion that works in the same cases they outline in the JEP?

I think the following is the main part to keep in mind:

> For Java, we would like to have a string composition feature that achieves the clarity of interpolation but achieves a safer result out-of-the-box, perhaps trading off a small amount of convenience to gain a large amount of safety.

Yes, all of those except swift are better

I agree that $ is more common and causes less visual friction, but what I like about \{} is that on my keyboard they are three keys adjacent to each other.

Bikeshedding of the noblest kind. It is all subjective.

I’d say valuing shorter syntax is better which is subjective, but then measuring it is objective. Requiring 3 chars per variable is silly when many languages only require 1

They are maintaining backward compatibility.

  "A \{variable}"

is currently invalid syntax, so it's fine to use. Something else like

  "A ${variable}"

is valid syntax, so using that would break existing code.

It's fine to break backwards compatibility when introducing an entirely new feature across a major version, actually. What's even the point of a major version bump?

Not everyone uses semver, although in any case Java "major" versions are actually a continuation of what was called the 1.x line -- they gave up on writing out the "1." a couple of decades ago. They're semver minor release, not semver major.

Plus, prepending the string with `STR.` changes the syntax entirely. Those strings are still invalid if you don't prepend `STR.` (which is another thing I hate, but not quite as much).

In C#, the string `"""Hello world"` is invalid, but `@"""Hello world"` is, because double quotes are valid with verbatim string literals.

There's plenty of languages that have your attitude. Java doesn't. Feel free to use one of those other languages.

Oracle has broken compatibility between versions before, at least in the runtime. URL Decoder's constructor was taken private after JDK 11:

https://docs.oracle.com/en/java/javase/11/docs/api/java.base...

https://docs.oracle.com/en/java/javase/17/docs/api/java.base...

There was a nice long deprecation period between those versions, where everyone using it got a warning. And then, when it was finally removed, everyone using it got an error, and they were forced to change their code. By contrast, a string literal could silently change meaning if it used syntax that was previously valid in strings. This is the exact same reason JS chose to require backticks to delimit interpolable strings - because otherwise existing string literals could silently change meaning.

Not if string literals are prepended with `STR.`. Old strings won't be affected

I hadn't caught that this was required, but then it'd lock them out of removing that requirement. Plus it'd complicate the parser, to have there be two different kinds of string literals syntactically.

They are just following that other famous language for developing mobile apps.

While I don't like it, all other alternatives were kind of taken by libraries.

And who knows, since it is preview, it might still change.

May I introduce to Swift? They even decided on that without any backwards compatibility limitations. It really is not bad, does it really matter if it’s a $ or a \ ?

using backslashes for anything other than escaping a characters (e.g: \" or \n) makes it a nightmare to try to coerce the compiler into understanding what you're trying to do if you combine escape characters and syntax in the same string

You get a giant ass bracket after it. How is it not readable?

“\{a}+\{b}=\{ a + b }\n”

Do you also criticize this? “Price: $${price}”?

Try, for example, generating a regular expression which features backslashes in it. You will get an unreadable mess and probably have to play with it for a while before java will even compile it

I very hope you are not generating regexes based on user data..

Also, I’m fairly sure $ is a special character in regexes..

Not all variables are user data

A template processor implementing regexes should be used for that situation.

The backslash is actually perfectly appropriate because they are doing more than interpolating strings (even though that's what `STR` is doing). They are also supposed to safely escape the contents of the values.

It's only a matter of time before IntelliJ (or some plugin) translates it on-the-fly. Reviews on GitHub will be annoying though.

Just use a custom template processor

Reply on news.ycombinator.com