Hacker News new | ask | show | jobs
by Noe2097 1203 days ago
Why oh why is that a backslash!?

Over the 9 languages mentioned: 5 languages (inc. JVM ones like groovy and kotlin) are using `$`, 1 language (swift) is using `\`.

`\` is a pain to type on many keyboard layouts -- actually most but the US one. It seemed to me that `$` would have been a much more "conventional" choice.

This really makes me sad. It looks like the choice was made on purpose to be different.

10 comments

I assume because `\{` was not a valid escape sequence, which means any use of this character pair can be identified as a template without changing the semantics of existing string literals.
But you need the `FOO.` prefix anyways. So there was never any ambiguity. It seems that it would be good to either make the prefix optional (presumably something equivalent to the `STR.` processor would be default) or keep the interpolation syntax clean. (IMHO just `STR."Hello {name}!"` would have been ideal). But instead they require both the prefix and the ugly interpretation syntax.
Bingo!
This reminds me how PHP ended up with weird characters for various things (like namespace separators) because it was just easier to parse.
PHP never stood out as a language with very clean syntax. It is very PHPesque to put the burden on the user of the language instead of going the extra mile and implement something that might be harder to parse, but would be more consistent. Inonsistency in general is one of PHP's issues.
if you ever had the misfortune of seeing the code for the parser and lexer of earlier versions of PHP youd see that it wasnt due to parsing simplicity but rather the author making poor syntax decisions due to a lack of understanding.

Then being walled in by backwards compatibility

Interesting, but not surprising for a language where functions were "hashed" as their identifier's string length. Do you have a link?
I do not, it'll be in whatever version control php is in though I'm sure.

Another absolute horror parser was the wikipedia wikitext parser. An ambiguous hand written mess of epic disgust.

I don’t mind the typing ergonomy. More that it is visually ugly and counter-intuitive. Because in every other language a backslash would mean you want to keep the braces instead of interpolating the variable inside. They even have a comparison table at the top of the document, where they didn’t dare to put the Java option next to the others because it would stand out as being too different. Why not just follow the established conventions?
I agree. On my keyboard I need to press ⌥ + ⌘ + 7

It's actually made worse because { and } also need special combinations.

To type \{X} I need to press

  (⌥ + ⌘ + 7) (SHIFT + ⌥ + 8) X (SHIFT + ⌥ + 9)
I know this is something we need to live with due to historical reasons, but I would prefer that new syntax is made simpler.
You just made me to get my MacBook out of closet :) (I stopped using it two months ago and moved to X1 carbon right before pandemic)

The ergonomic of \{X} is exactly the same on it as on my carbon x1, my keychron tls and four other keyboards I happen to have in my drawer.

Are You using modified Apple II like Rebecca Heineman or some kind of super small keyboard that looks like someone forgot to put all the keys in :) ?

Either way its on you not Java.

(Dont take this wrong way - this is an honest question - here in Poland almost all keyboard are backslash friendly and I would live to knowe where this is not the case)

It's a standard full sized external Mac keyboard for Norway bought directly from the Apple store. We share the keyboard with Denmark too I think. The Swedes and Finns have different keyboards, but I think they use a similar combination for backslash.

So the Mac issue applies to 4 countries in the Nordics at least. Please note that traditional PC keyboards use a different layout for some characters and may in some cases have a dedicated key for backslash too, in case you Google Norwegian keyboards. It's one of those Mac vs PC things we are used to.

Before anyone starts suggesting connecting a PC keyboard to my MacBook Pro, keep in mind that I use the built in keyboard almost 50% of the time and having two different key mappings is a hassle

Regarding backslashes and other special characters, I never said it's on Java specifically, but the US centric culture in general. K&R used curly brackets when they designed C because they fit the US teletype character set of the 60s/70s, but that doesn't mean it's the best choice today.

I'm not suggesting we use special unicode symbols like arrows and emojis, but just pause for a minute and look beyond the US keyboard and see if we can find a solution that also works ergonomically for at least some non-US countries.

Yeah, I agree that it would be nice to have option that works for all and takes all National quirks under consideration.

Do You have some specific way of template definition in mind that You think would work here?

And what about curly brackets, especially in context of templates, what would you use instead?

What about parenthesis () and square brackets [] ? (writing a lisp DSL that might have users from non-US layouts)
They are ok to use

I press ⌥ + 8 for square brackets and SHIFT + 8 for parentheses.

It's probably not possible to find better alternatives for Mac keyboards that could be used for a language based on Lisp syntax.

The Mac keyboard simply doesn't have any dedicated keys that are not used for normal text, except for "@". For some unknown reason, they have a dedicated key for umlauts ("¨") that we don't use in our language. I guess I could map it to brackets, but SHIFT + UMLAUT returns a "^" that is often used in regexps and I don't want to lose that.

Windows keyboards has a different layout that is slightly more programmer friendly if you have a full sized keyboard. They do have a backslash key but lack the dedicated "@" key. Windows needs a dedicated backslash due to the file paths, unlike Mac. It is an acceptable tradeoff for Mac users, as non-developers are more likely to use "@" than "\".

Let's just say that there is a reason why I love my IDE that will automatically add closing curly brackets when it detects a block.

I think the umlaut key exists on Norwegian and Danish keyboard so occasional Swedish and German names can be typed.
Agreed, the economics for this syntax is terrible.
I don't understand this rationale either:

> For the syntax of embedded expressions we considered using ${...}, but that would require a tag on string templates (either a prefix or a delimiter other than ") to avoid conflicts with legacy code.

Can't the template processor expression itself function as the tag? Is STR."..." already legal now?

They want

  String info = "My name is \{name}.";
to be a compile-time error because it is missing the template processor (e.g. the `STR.` prefix). Since existing code like

  String info = "My name is ${name}.";
is valid, they can’t use that syntax, or any other syntax that is currently allowed, as otherwise they would lose the ability to make it an error.

———

However, what they could have done instead is to use a syntax like

  String info = "My name is "(name)".";
i.e. place the interpolated expressions outside of string literals. Slightly longer, but maybe more readable and typable, and currently invalid syntax. (The parentheses would be mandatory.)
Futzing around with quotes like that is worse to type and it’s nice having distinct characters for open and close.
It makes perfect sense to have the expressions outside of the string literals, exactly because they are expressions and not literal. Quotes express literalness, the opposite of evaluation.

This is simply replacing the existing

  "My name is " + name + "."
by

  "My name is " (name) "."
by eliminating the plusses, and adding parentheses to make expressions like

  "My name is " ("John") "."
unambiguous (a string template with one parameter that happens to be a string literal). The parentheses also indicate that this is a parameter, like for a function call, that is immediately evaluated. (The whole string template feature is really just syntactic sugar for a function call.)

That way you don’t have to “interrupt” string literals with an expression. Instead you end the string literal normally and then comes an expression.

A string template would be defined as any sequence of string literals and parenthesized expressions.

I get that, but it’s hard to type accurately.
I'm not a fan either. Java seems to be declining in prevalence in my corner of industry, I'm sure these changes are made by wiser minds than mine, but I'm sceptical about whether such a choice is really right for users.
I remain to be convinced and program daily in Java for a long time.

It seems just as difficult to remember/useless as lambda expressions that look fine as vanity one-line expressions and then get difficult to write for most programmers.

We don't really need vanity innovation in the Java world. I would have asked for priority on the FX replacement to Swing, or support for running on ESP32 IoT devices as replacement to the Arduino platform.

Instead we get some weird looking syntax for what is basically a non-problem.

¯\_(ツ)_/¯

JavaScript basically has the same functionality but with ${}. Anyone who uses named parameters in HQL or SQL queries would be very grateful for this feature as it means you no longer have to type out the same name three times for each parameter.
Still don't get the need for it.

You could always use the + operator to join strings. Even a external library would do just fine when you want to insert some kind of variable name inside strings for that purpose.

Don't really get the need for this to be a core function with such a java-unlike grammar.

> We don't really need vanity innovation in the Java world. I would have asked for priority on the FX replacement to Swing, or support for running on ESP32 IoT devices as replacement to the Arduino platform.

Which are entirely unrelated projects to this one with very different engineers working on it. Those are easily parallelized, if you will. I don’t see why having progress completely elsewhere by different people is detrimental to these goals at all.

Because this thing here adds complexity to the language.

I'll be fine and ignore it completely like I've done with lambdas. I just pity the fools who enter Java world to learn the language and will suffer trying to learn what they believe is something normal programmers use.

Poor souls.

Seriously, yes. Great thought process behind the design, marred by the good-for-nothing (subjective opinion) backslash.

If any of you design a language or a DSL, please, please - avoid the backslash - for the reasons stated above. Hard to type, introduces unseen problems, most will hate it. It (backslash) is unbecoming, of anything elegant.

But if you do follow that advice consider if it is worth just using a different escape character for all interpolations. That way could still make use of this very sensible syntax of reusing the escape for interpolation whilst avoiding the backslash issues.
I'd also really have preferred $, but apparently there's some backwards compatibility issue with using that character?
“${val}” is a legal string literal that is certainly used in plenty of existing programs.

In current Java you would have to escape \, so only “\\{val}” could have existed before.

That's why JS use ` and not reuse ".

You want the lexer to be able to make the difference between a constant string and a template string and you want users to be able to read the code.

This JEP solves the former not the later.

It’s not as bad as people make it out to be. Swift without any backwards compatibility constraints chose “\(val)”. It does need a slight getting used to but it is not any worse than ${}.
Swift’s choice is strange and ugly IMO, even if it did not involve backwards compatibility constraints.
For another n=1 opinion, I like Swift’s choice, even though it’s different from convention. It’s lighter, typographically. ‘${‘ draws more attention to the delimiters than ‘\(‘.

And yes, the delimiters could be made less obtrusive using syntax coloring, but not all tools will do that (e.g. when using grep on a code base)

Isn’t the STR.” prefix enough to distinguish traditional strings from format strings?
` would be even more difficult to type, and is easily confused with '.

On European (other than British/Irish) keyboards where it exists, it will often be a dead key.

Slightly unrelated, but I only buy ISO keyboards and have my native tongue layout (Hungarian) and English easily switched. The former absolutely sucked for any programming work, so I think we just sort of have to accept that programming is done with an en-us layout, the same way that (hopefully) all identifiers/comments are also in English.
It's horrible but I can't get over it. The value of string template is also aesthetic.. and these are like staples. Java once again.
It’s the “escape” character.