Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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)?


> 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)


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.


> 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.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: