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.
Then being walled in by backwards compatibility
Another absolute horror parser was the wikipedia wikitext parser. An ambiguous hand written mess of epic disgust.
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 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.
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)
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.
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?
> 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?
String info = "My name is \{name}.";
String info = "My name is ${name}.";
———
However, what they could have done instead is to use a syntax like
String info = "My name is "(name)".";
This is simply replacing the existing
"My name is " + name + "."
"My name is " (name) "."
"My name is " ("John") "."
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.
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.
¯\_(ツ)_/¯
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.
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.
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.
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.
In current Java you would have to escape \, so only “\\{val}” could have existed before.
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.
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)
On European (other than British/Irish) keyboards where it exists, it will often be a dead key.