6 ms·

Automatic interpolation of variables into string literals is a bad idea IMHO. Couple that with variable hoisting (function scope) and hilarity can ensue when v

by wulczer 15y ago

Automatic interpolation of variables into string literals is a bad idea IMHO. Couple that with variable hoisting (function scope) and hilarity can ensue when variables defined further down a function influence the value of another variable that looks like it just contains a string literal.

lclarkmichalek 15y ago
Every time I try Ruby, this features seems odd, yet I never see much discussion of it. It feels unnatural to me, coming from a python background, and the only real advantage I can see is the fact that you do not have to type `.format(foo")` after the string, or some similar construct. What advantages did I miss? I doubt that the creators of ruby did not put any thought into this, and I'd be interested in their justification.
- telemachos 15y ago
  >> I doubt that the creators of ruby did not put any thought into this, and I'd be interested in their justification. I don't know what Matz's thinking was, but it may just be that Ruby owes a great deal to Perl. Interpolation in double-quoted strings is present in Perl (and used constantly).
  - ajuc 15y ago
    I think the bad part of string interpolation is that it encourages to use it constantly, in place, instead of extracting it to method. Gluing strings together is the weak point of application, and should be hard to do, to encourage people to wrap it in functions, that can also validate input, escape what needs to be escaped, etc. Maybe that's my "discipline and bodage" part talking :)
    - telemachos 15y ago
      I'm a very small-scale, amateur programmer, but that sounds like over-engineering to me. Getting variable values into strings is often necessary. A programming language shouldn't make something common hard, just to enforce a particular view of best practices. Note: I'm not saying that "make it a method" is a bad idea - in general or in the case of a specific project or a specific size of codebase. But I don't like the idea of the language enforcing such a restriction. Having said that, my first language was Perl, and I'm still a fan of TMTOWTDI and making common things easy.
- riffraff 15y ago
  I don't believe it's the rationale, but it does have a tiny advantage in readability compared to old style format strings, e.g "hello $name we welcome you in hour team '$teamName' of ${members.size}" vs "hello %s we welcome you in hour team '%s' of %d" % (name, teamName, members.size) While, comparing it to modern python's str.format, which would be (i believe please correct me if I'm wrong) "hello {name} we welcome you in hour team '{teamName}' of {members_size}".format(name=name, teamName=teamName, members_size=len(members)) ...I guess my question would be the opposite: why is that better than string interpolation (which has also been around for decades)?
  - masklinn 15y ago
    > why is that better than string interpolation (which has also been around for decades)? For my money, you can't use string interpolation for i18n alongside a semi-arbitrary access site (e.g. Transifex or Launchpad's Rosetta) and it's riskier for logging (for performance-related reasons, as it forces an eager interpolation where the logging API can provide for lazy formatting)
    - riffraff 15y ago
      these are good reasons for having a string templating system in a library, but I was referring to the 90% use case of having a script that outputs something it computes. The things don't seem mutually exclusive to me.
      - masklinn 15y ago
        > The things don't seem mutually exclusive to me. Sure but now you have two very different ways to format your strings and language users need to realize they should be using the one they're not used to for these specific tasks, even though there's pretty much nothing helping make them realize it. That significantly increases the user's cognitive load, and the risks of misusing APIs unless your language is able to express (and safegard against) the danger of string interpolation in specific contexts.
funksta 15y ago
Does anyone know what the rationale was for choosing this instead of printf or python3-style interpolation (where you explicitly specify the variables to be interpolated)?
lars 15y ago
It's syntactic sugar for string concatenation. The same bugs would happen today if you were concatenating strings. I don't see the problem, honestly.
Tichy 15y ago
Somehow you have to get those values into the String, though. How do you propose doing it? Seems to me you can either concatenate Strings ("hello "+name) or interpolate ("hello #{name}")? Interpolating actually looks cleaner to me. Or of course create_string("hello $1", name) or something like that.
- masklinn 15y ago
  > Interpolating actually looks cleaner to me. Definitely. It can't be used for i18n though, which is problematic (interpolation usually uses full expressions, so it's essentially a vector of code injection). > Or of course create_string("hello $1", name) or something like that. There are already string formatting minilanguages, no need to make up your own: you can use printf's format or C#-style string formats (I think the C# one is rather nice, especially its extensions in Python which allow for implicit positional and named formatting)
nene 15y ago
It's not really automatic interpolation. You have to very explicitly place the variable name inside ${var}. I'm puzzled in how you would think this will happen accidentally, or more accidentally than writing "+var+". I've used Ruby quite a while and never experienced any problems with the very same construct in there.
- FuzzyDunlop 15y ago
  You can also get away with doing just "$var", though, which is the problem. We encountered a strange bug the other day where having a string containing "$3" meant it never appeared on the page after (with it being converted to null).
ootachi 15y ago
Strings with interpolation look different in ES6. They don't just look like string literals. You can easily see where the variable substitutions happen. Also, I don't know what your argument about PHP is all about. I don't agree with the idea that string interpolation is going to lead to people writing code vulnerable to SQL injection, for example. You can just as easily write "select * from foo where name=\"" + name + "\"" as `select * from foo where name="${name}"`.
- masklinn 15y ago
  > You can just as easily write No you can't. You've got 8% more character and 2 switches between string context and expression context. It does not "flow" it's something which is forced on the user by limitations of the language.

by wulczer 15y ago

lclarkmichalek 15y ago

Every time I try Ruby, this features seems odd, yet I never see much discussion of it. It feels unnatural to me, coming from a python background, and the only real advantage I can see is the fact that you do not have to type `.format(foo")` after the string, or some similar construct. What advantages did I miss? I doubt that the creators of ruby did not put any thought into this, and I'd be interested in their justification.

telemachos 15y ago
>> I doubt that the creators of ruby did not put any thought into this, and I'd be interested in their justification. I don't know what Matz's thinking was, but it may just be that Ruby owes a great deal to Perl. Interpolation in double-quoted strings is present in Perl (and used constantly).
- ajuc 15y ago
  I think the bad part of string interpolation is that it encourages to use it constantly, in place, instead of extracting it to method. Gluing strings together is the weak point of application, and should be hard to do, to encourage people to wrap it in functions, that can also validate input, escape what needs to be escaped, etc. Maybe that's my "discipline and bodage" part talking :)
  - telemachos 15y ago
    I'm a very small-scale, amateur programmer, but that sounds like over-engineering to me. Getting variable values into strings is often necessary. A programming language shouldn't make something common hard, just to enforce a particular view of best practices. Note: I'm not saying that "make it a method" is a bad idea - in general or in the case of a specific project or a specific size of codebase. But I don't like the idea of the language enforcing such a restriction. Having said that, my first language was Perl, and I'm still a fan of TMTOWTDI and making common things easy.
riffraff 15y ago
I don't believe it's the rationale, but it does have a tiny advantage in readability compared to old style format strings, e.g "hello $name we welcome you in hour team '$teamName' of ${members.size}" vs "hello %s we welcome you in hour team '%s' of %d" % (name, teamName, members.size) While, comparing it to modern python's str.format, which would be (i believe please correct me if I'm wrong) "hello {name} we welcome you in hour team '{teamName}' of {members_size}".format(name=name, teamName=teamName, members_size=len(members)) ...I guess my question would be the opposite: why is that better than string interpolation (which has also been around for decades)?
- masklinn 15y ago
  > why is that better than string interpolation (which has also been around for decades)? For my money, you can't use string interpolation for i18n alongside a semi-arbitrary access site (e.g. Transifex or Launchpad's Rosetta) and it's riskier for logging (for performance-related reasons, as it forces an eager interpolation where the logging API can provide for lazy formatting)
  - riffraff 15y ago
    these are good reasons for having a string templating system in a library, but I was referring to the 90% use case of having a script that outputs something it computes. The things don't seem mutually exclusive to me.
    - masklinn 15y ago
      > The things don't seem mutually exclusive to me. Sure but now you have two very different ways to format your strings and language users need to realize they should be using the one they're not used to for these specific tasks, even though there's pretty much nothing helping make them realize it. That significantly increases the user's cognitive load, and the risks of misusing APIs unless your language is able to express (and safegard against) the danger of string interpolation in specific contexts.

funksta 15y ago

Does anyone know what the rationale was for choosing this instead of printf or python3-style interpolation (where you explicitly specify the variables to be interpolated)?

lars 15y ago

It's syntactic sugar for string concatenation. The same bugs would happen today if you were concatenating strings. I don't see the problem, honestly.

Tichy 15y ago

Somehow you have to get those values into the String, though. How do you propose doing it? Seems to me you can either concatenate Strings ("hello "+name) or interpolate ("hello #{name}")? Interpolating actually looks cleaner to me. Or of course create_string("hello $1", name) or something like that.

masklinn 15y ago
> Interpolating actually looks cleaner to me. Definitely. It can't be used for i18n though, which is problematic (interpolation usually uses full expressions, so it's essentially a vector of code injection). > Or of course create_string("hello $1", name) or something like that. There are already string formatting minilanguages, no need to make up your own: you can use printf's format or C#-style string formats (I think the C# one is rather nice, especially its extensions in Python which allow for implicit positional and named formatting)

nene 15y ago

It's not really automatic interpolation. You have to very explicitly place the variable name inside ${var}. I'm puzzled in how you would think this will happen accidentally, or more accidentally than writing "+var+". I've used Ruby quite a while and never experienced any problems with the very same construct in there.

FuzzyDunlop 15y ago
You can also get away with doing just "$var", though, which is the problem. We encountered a strange bug the other day where having a string containing "$3" meant it never appeared on the page after (with it being converted to null).

ootachi 15y ago

Strings with interpolation look different in ES6. They don't just look like string literals. You can easily see where the variable substitutions happen. Also, I don't know what your argument about PHP is all about. I don't agree with the idea that string interpolation is going to lead to people writing code vulnerable to SQL injection, for example. You can just as easily write "select * from foo where name=\"" + name + "\"" as `select * from foo where name="${name}"`.

masklinn 15y ago
> You can just as easily write No you can't. You've got 8% more character and 2 switches between string context and expression context. It does not "flow" it's something which is forced on the user by limitations of the language.