undefined | Better HN

0 pointsahuth11y ago0 comments

There isn't much difference between this:

    "My name is #{name} and surname is #{surname}"

and this:

    "My name is " + name + " and surname is " + surname

or this:

    fmt.Println("My name is %s and surname is %s", name, surname)

Except the first one is much more readable.

String interpolation seems like a small thing, but I find myself wanting to use it all the time. It's definitely not a "magic" feature. Javascript really needs it as well.

0 comments

lazyjones11y ago

> Except the first one is much more readable.

I disagree, especially in the presence of syntax highlighting editors.

String interpolation would be a redundant alternative to existing mechanisms (the above plus text/template for longer strings) and just make parsing more complex. I don't think it would fit in well with Go's philosophy of providing pleasant, minimalistic syntax.

thescrewdriver11y ago

I find that there are some disturbing similarities between the Java community and the Go community when it comes to features and culture. There seems to be an unwritten assumption that the language is perfect in its current form and any additional features are a source of evil (up until the day when they are added, in which case they are suddenly evidence of the language's superiority).

lazyjones11y ago

> the language is perfect in its current form

It works really well in its current form, that is probably the general consensous.

> additional features are a source of evil

Some of us have walked down that path before (e.g. Perl, Scala) and think we have seen the light (or at least the darkness).

> up until the day when they are added, in which case they are suddenly evidence of the language's superiority

That sounded very much like flamebait. Could you name an example of a feature added to Go that was previously considered evil and then as evidence of Go's superiority?

2 more replies

ajanuary11y ago

> I disagree, especially in the presence of syntax highlighting editors.

Every syntax highlighter in an editor I've seen for Ruby handle highlighting string interpolation just fine.

ahuthOP11y ago

You're probably right. Also, I obviously should've said, "Except the first one is much more readable to me."

I definitely don't have a problem with the Go developers keeping out random syntax additions unless they think its a really good idea.

Along the same lines, I really miss not having `map`, `reduce`, and `filter` in Go. However, it doesn't seem like those would be efficient in Go, or that they fit in with as well with systems programming, which Go was designed for. So I can't hate them for not including these.

NateDad11y ago

For what it's worth, I do think it's more readable, but it's just not a good idea. It's too easy for people to inject variables into their strings and get your code to print out data that's in memory.

map, reduce, filter, etc will be easy to code up once there are generics. There will almost certainly be generics in Go at some point, that point is just not right now (and almost certainly not before 2.0).

1 more reply

rogerbinns11y ago

There is one huge difference - it is far easier to internationalize the first one. The second one is impossible, and the third has ordering issues.

What is the Go best practise for i18n? A google search seems to provide various solutions but not one best practise.

ajanuary11y ago

What do you mean by being easier to internationalize? Do you mean you can lookup the string at runtime and it will then interpolate on that? That's not a safe way for interpolation to work, because then random strings from unsafe sources can start including any variables from your environment. String interpolation should only apply to string literals. What you actually want (no idea if it's available in Go) is something akin to Sprintf but with named instead of positional arguments, and then explicitly provide a map of those arguments rather than letting it get them from the lexical environment as interpolation does.

rogerbinns11y ago

You have made the assumption that the values provided just come from the enclosing scopes. The various packages I found all require an explicit map/dictionary passed in - ie there is nothing unsafe - only named values intended for formatting can be used. (The OP likely didn't show the map/dict because that wasn't relevant to their point.)

sisalcat11y ago

The first one (string with variable interpolation) is not internationalizable, only the third one is.

> the third has ordering issues

In Go you can specify the order in format strings: fmt.Sprintf("%[2]d %[1]d\n", 11, 22)

http://golang.org/pkg/fmt/

axaxs11y ago

The last example is different - remember to use Printf, else you get: My name is %s and my surname is %s John Smith

I do this unfortunately way more than I want to admit...

ahuthOP11y ago

Thanks. I'm definitely not an expert at Go.

teyc11y ago

String interpolation is wrong in a world where there are so many variants of escaping strings. It is not useful for templating HTML, SQL, CSV, JSON, XML.

This only leaves us console programs and backdoors. I'm happy to give these two up for a stronger language.

ajanuary11y ago

One difference is that the first one, with a good implementation, will be more efficient because it doesn't need to allocate intermediate strings.

I don't think such a micro-optimisation is enough to sway the argument though.

j / k navigate · click thread line to collapse

0 comments

lazyjones11y ago

> Except the first one is much more readable.

I disagree, especially in the presence of syntax highlighting editors.

thescrewdriver11y ago

lazyjones11y ago

> the language is perfect in its current form

It works really well in its current form, that is probably the general consensous.

> additional features are a source of evil

Some of us have walked down that path before (e.g. Perl, Scala) and think we have seen the light (or at least the darkness).

> up until the day when they are added, in which case they are suddenly evidence of the language's superiority

That sounded very much like flamebait. Could you name an example of a feature added to Go that was previously considered evil and then as evidence of Go's superiority?

2 more replies

ajanuary11y ago

> I disagree, especially in the presence of syntax highlighting editors.

Every syntax highlighter in an editor I've seen for Ruby handle highlighting string interpolation just fine.

ahuthOP11y ago

You're probably right. Also, I obviously should've said, "Except the first one is much more readable to me."

I definitely don't have a problem with the Go developers keeping out random syntax additions unless they think its a really good idea.

NateDad11y ago

1 more reply

rogerbinns11y ago

There is one huge difference - it is far easier to internationalize the first one. The second one is impossible, and the third has ordering issues.

What is the Go best practise for i18n? A google search seems to provide various solutions but not one best practise.

ajanuary11y ago

rogerbinns11y ago

sisalcat11y ago

The first one (string with variable interpolation) is not internationalizable, only the third one is.

> the third has ordering issues

In Go you can specify the order in format strings: fmt.Sprintf("%[2]d %[1]d\n", 11, 22)

http://golang.org/pkg/fmt/

axaxs11y ago

The last example is different - remember to use Printf, else you get: My name is %s and my surname is %s John Smith

I do this unfortunately way more than I want to admit...

ahuthOP11y ago

Thanks. I'm definitely not an expert at Go.

teyc11y ago

String interpolation is wrong in a world where there are so many variants of escaping strings. It is not useful for templating HTML, SQL, CSV, JSON, XML.

This only leaves us console programs and backdoors. I'm happy to give these two up for a stronger language.

ajanuary11y ago

One difference is that the first one, with a good implementation, will be more efficient because it doesn't need to allocate intermediate strings.

I don't think such a micro-optimisation is enough to sway the argument though.

j / k navigate · click thread line to collapse