[omnigoat]

Well, in the interests of actually furthering discussion:

I feel as if string and map simply could have been part of the standard library. My solution to the this for prism was to have a section of the standard library (which doesn't exist yet) marked as "integral", to effectively have an implicit "import string, map from std.__integral__" at the top of every translation unit.

The absence of overloading operators seems to contradict their claims of improving the visual "flow" and feel of programming. There are cases where savvy operator overloading works wonders: vectors/matrices/quaternions, strings, complex numbers, etc. To be able to write my_string + my_other_string is far more elegant than strcat(my_string, my_otherstring). Consider what happens when you have four of five strings you'd like to concatenate!

The choice of CSP reflects Google's mentality: Their problems lend themselves very well to CSP. Other domains (in my opinion) work better with a STM model. But that's clearly a design choice, and I think it's fine!

[oconnor0]

I'm not a huge fan of "+" for string concatenation as "+" is, traditionally, commutative; I like Lua's "..". That being said I like "+" more than "strcat".

[agl]

Operator overloading has good points and bad points: we're erring on the side of simplicity for now.

However, you can write "abc" + "def" in Go and it does what you expect.

[astine]

=> "egi"?

[blasdel]

Thankfully strings in Go are completely distinct from Arrays -- immutable, and with hard baked-in UTF-8 support.

[spicyj]

I'm sorry if this is a stupid question, but where'd you get that? I don't get it. :(

[skarlath]

"abc" + "def"

a + d = e (1 + 4 = 5 = e) b + e = g (2 + 5 = 7 = g) c + f = i (3 + 6 = 9 = i)

I think he was making a joke about how + with strings doesn't necessarily mean string concatenation.

[patio11]

I think the point is even better than a joke: there is a danger in allowing things like, e.g., operator overloading (or redefining methods in the standard library), because programmers have different feelings about what the code "obviously" means.

If in your language, + means string concatenation by convention, then + darn well means string concatenation. If in your language + means "contextually appropriate depending on what arguments you pass to it", then

"abc" + "def" => "egi"

doesn't strike me as obviously wrong.

More broadly, consider a language in which we teach initiates that "Plus adds things in the way you'd expect!"

map = {}

map2 = map + {"key" => "contents"}

What are the contents of map and map2 now? Uh oh. More worrisome:

map = MemcachedWrapper.new

map2 = map + {"key" => "contents"}

What just happened?

[tsuraan]

This whole line of reasoning reminds me of the Java3D API. Java, of course, takes the approach that only the designers of the langauge were smart enough to know when to abuse operator overloading (e.g. with strings), so for the Java3D math API, they couldn't have nice syntax for vector arithmetic. Instead of having nice operators for addition (+) and accumulation (+=), they just have english, and they want it to be terse, so the accumulation method is .add, and there is no addition method for vectors. It's not terribly confusing, but seeing vec1.add(vec2) rather than vec1 += vec2 is ugly and you still have to read the documentation to know what the .add method does.

Avoiding operator overload doesn't avoid poorly named methods, nor does it avoid the need for documentation. All that it does is force programmers to do ugly things when dealing with math, and there is a lot of math-based programming out there.

[omnigoat]

I'd like to make two points in response...

1) I did say 'savvy'. Sort of because I don't get to use that word enough, but also because it is possible to abuse operator overloading. String concatenation with the addition operator isn't going to suprise anyone, even if you come from another language (well, it might, but the choice of the + operator isn't an unintuitive one). Furthermore, nobody's jumping at things with well-defined operators, like vectors/matrices, etc. I've written very little outside of a maths library that used operator overloading, but it's a godsend for the cases where it's appropriate... probably a truism.

Secondly, they're just functions. You can look them up (y'know, assuming you can), you can optimise them, and you can document them. A programmer encountering an operator doesn't have to rely on their interpretation alone, and indeed shouldn't. They should know what that operator does. Now of course, if the operator has absolutely no contextual reason for existing, or is suprising divergent from its apparent purpose... well, see point 1.

As for your example, how do you do a greater-than-or-equal comparison on strings? :D

[btilly]

And he could have expected 18AB to point out that those strings wouldn't necessarily be interpreted as strings in a math context.

[spicyj]

Oh, element-wise addition. Somehow I didn't figure that out. Thanks.

[d0m]

:P Nice one, made me smile

[aidenn0]

I always thought a huge benefit of lisp using S expressions is the lack of infix operators saves a lot of time and energy arguing whether/when they should be overloaded.