3 ms·

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 r

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.

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.