7 ms·

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

by Noe2097 4y 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.

jacobn 4y ago
I'd also really have preferred $, but apparently there's some backwards compatibility issue with using that character?
- kaba0 4y ago
  “${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.
  - _old_dude_ 4y ago
    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.
    - kaba0 4y ago
      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 ${}.
      - Kwpolska 4y ago
        Swift’s choice is strange and ugly IMO, even if it did not involve backwards compatibility constraints.
        Someone 4y ago
        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)
        comex 4y ago
        Swift’s choice has the advantage of visually unifying the two cases where text in a string literal is interpreted as something other than the text itself. One is backslash escapes like \n and \\. The other is string interpolation.
    - Too 4y ago
      Isn’t the STR.” prefix enough to distinguish traditional strings from format strings?
    - Symbiote 4y ago
      ` 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.
cs02rm0 4y ago
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.
- nunobrito 4y ago
  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. ¯\_(ツ)_/¯
  - kaba0 4y ago
    > 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.
    - nunobrito 4y ago
      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.
  - imtringued 4y ago
    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.
kothar 4y ago
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.
- aardvark179 4y ago
  Bingo!
- layer8 4y ago
  More specifically: https://news.ycombinator.com/item?id=35016204 https://news.ycombinator.com/item?id=35016204
- dmitriid 4y ago
  This reminds me how PHP ended up with weird characters for various things (like namespace separators) because it was just easier to parse.
  - zelphirkalt 4y ago
    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.
  - sirsinsalot 4y ago
    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
    - colejohnson66 4y ago
      Interesting, but not surprising for a language where functions were "hashed" as their identifier's string length. Do you have a link?
pdevr 4y ago
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.
- SyrupThinker 4y ago
  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.
spankalee 4y ago
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?
- layer8 4y ago
  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.)
  - ec109685 4y ago
    Futzing around with quotes like that is worse to type and it’s nice having distinct characters for open and close.
    - layer8 4y ago
      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.
qw 4y ago
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.
- lenkite 4y ago
  What about parenthesis () and square brackets [] ? (writing a lisp DSL that might have users from non-US layouts)
  - qw 4y ago
    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.
    - Symbiote 4y ago
      I think the umlaut key exists on Norwegian and Danish keyboard so occasional Swedish and German names can be typed.
- bberrry 4y ago
  Agreed, the economics for this syntax is terrible.
kaba0 4y ago
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.
Too 4y ago
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?
saagarjha 4y ago
It’s the “escape” character.
agumonkey 4y ago
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.

jacobn 4y ago

I'd also really have preferred $, but apparently there's some backwards compatibility issue with using that character?

kaba0 4y ago
“${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.
- _old_dude_ 4y ago
  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.
  - kaba0 4y ago
    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 ${}.
    - Kwpolska 4y ago
      Swift’s choice is strange and ugly IMO, even if it did not involve backwards compatibility constraints.
      - Someone 4y ago
        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)
        comex 4y ago
        Swift’s choice has the advantage of visually unifying the two cases where text in a string literal is interpreted as something other than the text itself. One is backslash escapes like \n and \\. The other is string interpolation.
  - Too 4y ago
    Isn’t the STR.” prefix enough to distinguish traditional strings from format strings?
  - Symbiote 4y ago
    ` 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.

cs02rm0 4y ago

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.

nunobrito 4y ago
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. ¯\_(ツ)_/¯
- kaba0 4y ago
  > 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.
  - nunobrito 4y ago
    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.
- imtringued 4y ago
  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.

kothar 4y ago

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.

aardvark179 4y ago
Bingo!
layer8 4y ago
More specifically: https://news.ycombinator.com/item?id=35016204 https://news.ycombinator.com/item?id=35016204
dmitriid 4y ago
This reminds me how PHP ended up with weird characters for various things (like namespace separators) because it was just easier to parse.
- zelphirkalt 4y ago
  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.
- sirsinsalot 4y ago
  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
  - colejohnson66 4y ago
    Interesting, but not surprising for a language where functions were "hashed" as their identifier's string length. Do you have a link?

pdevr 4y ago

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.

SyrupThinker 4y ago
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.

spankalee 4y ago

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?

layer8 4y ago
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.)
- ec109685 4y ago
  Futzing around with quotes like that is worse to type and it’s nice having distinct characters for open and close.
  - layer8 4y ago
    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.

qw 4y ago

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.

lenkite 4y ago
What about parenthesis () and square brackets [] ? (writing a lisp DSL that might have users from non-US layouts)
- qw 4y ago
  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.
  - Symbiote 4y ago
    I think the umlaut key exists on Norwegian and Danish keyboard so occasional Swedish and German names can be typed.
bberrry 4y ago
Agreed, the economics for this syntax is terrible.

kaba0 4y ago

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.

Too 4y ago

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?

saagarjha 4y ago

It’s the “escape” character.

agumonkey 4y ago

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.