3 ms·

Even after reading this proposal over the past months over and over in all its iterations, I still don't get it. Is this what many developers want? I fear peopl

by rf15 3y ago

Even after reading this proposal over the past months over and over in all its iterations, I still don't get it. Is this what many developers want? I fear people will just stick with +concatenation because it's less verbose than this.

LatticeAnimal 3y ago
STR.”what is so bad about \{this}?”
- rf15 3y ago
  `"what is so bad about" + this` uses 4 less characters, and that includes the spaces around the plus.
  - quacker 3y ago
    Except it’s more if I have text following a variable. Try this: STR.”x=\{x} y=\{y} z=\{z}.” Compared to: “x=“ + x + “ y=“ + y + “ z=“ + z + “.” A string template incurs an overhead of 3 characters per variable (“\“, “{“, and “}”) plus the leading “STR.”, which is 4 characters. Concatenation incurs an overhead of 4 non-whitespace characters per variable (`”+` and `+”`), and that’s ignoring whitespace. If you have more than 3-4 variables, string templates are shorter. The concatenation example is less readable as well. Have I included whitespace to exactly match the string template example? It’s a little hard to tell at a glance because I have to distinguish what is code whitespace and what’s included in the string.
  - BenoitP 3y ago
    You may have a point for strings. But this is about guarantees for more convoluted expressions in other languages. If you include validating SQL being injection-free, this is waaay less verbose. Also this is about enabling a _system_ of templating, and potentially letting the IDE treat it as such and warn you at compile-time. Small snippets tend to creep all over a codebase. Some use-case that this enables: * HTML templating React-server-side-style: response.send(HTML_PART."""<div>\{name}</div>"""). Here both the HTML is validated, and the variable is escaped; at compile-time. How do you beat this? * Query-building: businessFilterClause.add(WHERE_VALIDATE."""PRODUCT_MODEL IN \{authorizedModels}"""). And at compile-time or build-time having it validated against a database schema, and the compatibility of your types.
orf 3y ago
F-strings have been the fastest ever adopted syntax change to Python, and is the overall most popular of the recent post-3.6 additions. That’s Python, but it shares similarities with Java in terms of numerous different ways of formatting strings. They are very, very useful, but lots of people said similar things to you about not getting it. Then… they used them, I guess. \{} is not very verbose either, and the use of generic formatters is a really nice addition.
- rf15 3y ago
  I'm always happy to have stuff like f-strings in languages. This on the other hand feels much too overladen with separate requirements of safety/etc. which reduces its general usability. Suddenly you don't have to prefix it with "f" / "{}" but "STR." and "\{}", which (unlike f-strings) keeps cluttering your reading space more, something you actually try to improve on with this very feature in other languages. Neither the prefix nor the curly braces are optional for simple terms sadly, unlike in some other languages.

by rf15 3y ago

LatticeAnimal 3y ago

STR.”what is so bad about \{this}?”

rf15 3y ago
`"what is so bad about" + this` uses 4 less characters, and that includes the spaces around the plus.
- quacker 3y ago
  Except it’s more if I have text following a variable. Try this: STR.”x=\{x} y=\{y} z=\{z}.” Compared to: “x=“ + x + “ y=“ + y + “ z=“ + z + “.” A string template incurs an overhead of 3 characters per variable (“\“, “{“, and “}”) plus the leading “STR.”, which is 4 characters. Concatenation incurs an overhead of 4 non-whitespace characters per variable (`”+` and `+”`), and that’s ignoring whitespace. If you have more than 3-4 variables, string templates are shorter. The concatenation example is less readable as well. Have I included whitespace to exactly match the string template example? It’s a little hard to tell at a glance because I have to distinguish what is code whitespace and what’s included in the string.
- BenoitP 3y ago
  You may have a point for strings. But this is about guarantees for more convoluted expressions in other languages. If you include validating SQL being injection-free, this is waaay less verbose. Also this is about enabling a _system_ of templating, and potentially letting the IDE treat it as such and warn you at compile-time. Small snippets tend to creep all over a codebase. Some use-case that this enables: * HTML templating React-server-side-style: response.send(HTML_PART."""<div>\{name}</div>"""). Here both the HTML is validated, and the variable is escaped; at compile-time. How do you beat this? * Query-building: businessFilterClause.add(WHERE_VALIDATE."""PRODUCT_MODEL IN \{authorizedModels}"""). And at compile-time or build-time having it validated against a database schema, and the compatibility of your types.

orf 3y ago

F-strings have been the fastest ever adopted syntax change to Python, and is the overall most popular of the recent post-3.6 additions. That’s Python, but it shares similarities with Java in terms of numerous different ways of formatting strings. They are very, very useful, but lots of people said similar things to you about not getting it. Then… they used them, I guess. \{} is not very verbose either, and the use of generic formatters is a really nice addition.

rf15 3y ago
I'm always happy to have stuff like f-strings in languages. This on the other hand feels much too overladen with separate requirements of safety/etc. which reduces its general usability. Suddenly you don't have to prefix it with "f" / "{}" but "STR." and "\{}", which (unlike f-strings) keeps cluttering your reading space more, something you actually try to improve on with this very feature in other languages. Neither the prefix nor the curly braces are optional for simple terms sadly, unlike in some other languages.