5 ms·

In a way, simple Scala code resembles Swift, as commented by this person: https://leverich.github.io/swiftislikescala/ https://leverich.github.io/swiftislikesca

In a way, simple Scala code resembles Swift, as commented by this person: https://leverich.github.io/swiftislikescala/ https://leverich.github.io/swiftislikescala/ Now the type system of course is entirely different.

kbenson 10y ago
val label = "The width is " val width = 94 val widthLabel = label + width I really wish more languages would distinguish concatenation from addition, especially when they do type coercion. There's a very specific reason Perl opted for '.' to concatenate strings instead of +, which is that it disambiguates the following: val first = "2" val second = 3 val together1 = first + second val together2 = second + first Not to mention, addition is commutative and concatenation is not (1+2 == 2+1, but "one" + "two" != "two" + "one") Hopefully Scala at least has some very well defined and easy rules for exactly how string concatenation works, but I think it's an uphill battle to argue that '+' is a good concatenation operator.
- coldtea 10y ago
  Maybe, but in 20 years of programming (and 10+ of them with dynamic languages) I don't think I have had that issue more than 2-3 times. (1) Passing an int/string when a function expects the other type? Yes, I had that happen lots. (2) Concatenating a string and a (coerced) int? It's either a much narrower subproblem of (1), or exactly what I wanted to happen in the first place (e.g. print "Your score is: " + n + " points".
  - kbenson 10y ago
    I've dealt with it lots. While concatenating variable and string literals like your example is very rarely ambiguous, but what can be is using + to operating on two variables whose input has been returned from elsewhere. Does that function that gets the user supplied value for height automatically convert to a numerical type, or is it a string? What about the function that gets the user supplied value for width? Is it stored in a back-end format that strictly types those fields to ensure that if the data is set from some less frequently used method it has the same type (e.g. are you storing as JSON, and can this JSON be created from multiple code paths?) Given a simple statement like "foo = bar + baz", why should there be ambiguity when there doesn't need to be? The glib answer to the problem is to tell people to use better variable names, or document their functions better, or any number of suggestions that put the onus on the programmer, when this is a very simple to solve problem. Don't overload operators in the core language for conceptually different actions. We don't "add" strings, we concatenate them. Add is at best, shorthand for "add to end of" which means to append. Coercion can be a useful tool, except for when it creates confusion. There are well known and tested ways to combat this confusion, so I'm not sure why we haven't adopted them widely where coercion is in use. P.S. It's not just addition. Testing for equality is another common case where coercion can cause problems. The answer to that is equally as simple, use a different operator (such as "eq" and "ne" for string equality in Perl). Numeric equality is not the same as string equality (10.0 is equivalent to 10, but "foo." is not equivalent to "foo"), and making the programmer think (not not!) about what will happen when using an overloaded equality operator on two variables just shifts a small amount of up-front cost when learning the language (we have different operators for string concatenation and equivalence testing, learn them) to a cost imposed every time the programmer has to use those operators.
    - AzzieElbab 10y ago
      I think concats like 1 + "111" can be disabled with import scala.Predef.{find_right_implicit => _,_}. Cant imagine how many things it will break though
- edko 10y ago
  You can also use: s"The width is $width"
  - kbenson 10y ago
    Which is good, but interpolation is really just a specialized case of concatenating string literals and variables, not variables to other variables, which is where some ambiguity is introduced.
    - edko 10y ago
      You can also do s"$varOne$varTwo" and that concatenates two variables.
      - kbenson 10y ago
        Yes, as an alternate syntax, interpolation works well to disambiguate your intent, which supports my point. It's really just a highly specialized form of a different operator, which says I work on strings, so anything I see that isn't a string coerce to a string. For example, in Perl $varOne . $varTwo Is entirely equivalent to "$varOne$varTwo" The question is why Scala chose to use + when it had other, non-ambiguous options, like above.
        airless_bar 10y ago
        To be more familiar to Java developers. There are some thoughts about migrating people away from + toward string interpolation. But automated conversion tools are required before this can happen.
- int_19h 10y ago
  '+' works great as a concatenation operator, so long as you don't ever try to implicitly convert the values. Case in point - Python: >>> 1+2 3 >>> "1"+"2" '12' >>> "1"+2 Traceback (most recent call last): File "<stdin>", line 1, in <module> TypeError: Can't convert 'int' object to str implicitly
  - kbenson 10y ago
    Those are literals, not variables. My whole argument is about the ambiguity introduced when you are implicitly coercing variables. But yes, if the language does not coerce between string and numeric types, it's a non-issue. I'm specifically talking about supporting coercion but continuing to use '+' for concatenation of strings (and ==/!= for equivalence testing of strings as well).
- munificent 10y ago
  > There's a very specific reason Perl opted for '.' to concatenate strings instead of + I don't see making string concatenation ambiguous with property access being a real improvement. At least use `..` or some other unused punctuation.
  - kbenson 10y ago
    In Perl, '.' is not property access. I'm not trying to imply '.' is the best solution for a language where it's already in use, but that a separate, unambiguous symbol would be better. For example, Perl 6 moved to using '.' for calling methods, and uses '~' for concatenation. It's not like just changing '+' is sufficient anyway, there is still string equivalence to consider (outlined in my other replies).
- skoczymroczny 10y ago
  D uses + for addition and ~ for concatenation
- FraaJad 10y ago
  D does. auto greeting = "Hello" ~ " World!"; immutable x = 9 + 99; auto:immutable::var:val

kbenson 10y ago

val label = "The width is " val width = 94 val widthLabel = label + width I really wish more languages would distinguish concatenation from addition, especially when they do type coercion. There's a very specific reason Perl opted for '.' to concatenate strings instead of +, which is that it disambiguates the following: val first = "2" val second = 3 val together1 = first + second val together2 = second + first Not to mention, addition is commutative and concatenation is not (1+2 == 2+1, but "one" + "two" != "two" + "one") Hopefully Scala at least has some very well defined and easy rules for exactly how string concatenation works, but I think it's an uphill battle to argue that '+' is a good concatenation operator.

coldtea 10y ago
Maybe, but in 20 years of programming (and 10+ of them with dynamic languages) I don't think I have had that issue more than 2-3 times. (1) Passing an int/string when a function expects the other type? Yes, I had that happen lots. (2) Concatenating a string and a (coerced) int? It's either a much narrower subproblem of (1), or exactly what I wanted to happen in the first place (e.g. print "Your score is: " + n + " points".
- kbenson 10y ago
  I've dealt with it lots. While concatenating variable and string literals like your example is very rarely ambiguous, but what can be is using + to operating on two variables whose input has been returned from elsewhere. Does that function that gets the user supplied value for height automatically convert to a numerical type, or is it a string? What about the function that gets the user supplied value for width? Is it stored in a back-end format that strictly types those fields to ensure that if the data is set from some less frequently used method it has the same type (e.g. are you storing as JSON, and can this JSON be created from multiple code paths?) Given a simple statement like "foo = bar + baz", why should there be ambiguity when there doesn't need to be? The glib answer to the problem is to tell people to use better variable names, or document their functions better, or any number of suggestions that put the onus on the programmer, when this is a very simple to solve problem. Don't overload operators in the core language for conceptually different actions. We don't "add" strings, we concatenate them. Add is at best, shorthand for "add to end of" which means to append. Coercion can be a useful tool, except for when it creates confusion. There are well known and tested ways to combat this confusion, so I'm not sure why we haven't adopted them widely where coercion is in use. P.S. It's not just addition. Testing for equality is another common case where coercion can cause problems. The answer to that is equally as simple, use a different operator (such as "eq" and "ne" for string equality in Perl). Numeric equality is not the same as string equality (10.0 is equivalent to 10, but "foo." is not equivalent to "foo"), and making the programmer think (not not!) about what will happen when using an overloaded equality operator on two variables just shifts a small amount of up-front cost when learning the language (we have different operators for string concatenation and equivalence testing, learn them) to a cost imposed every time the programmer has to use those operators.
  - AzzieElbab 10y ago
    I think concats like 1 + "111" can be disabled with import scala.Predef.{find_right_implicit => _,_}. Cant imagine how many things it will break though
edko 10y ago
You can also use: s"The width is $width"
- kbenson 10y ago
  Which is good, but interpolation is really just a specialized case of concatenating string literals and variables, not variables to other variables, which is where some ambiguity is introduced.
  - edko 10y ago
    You can also do s"$varOne$varTwo" and that concatenates two variables.
    - kbenson 10y ago
      Yes, as an alternate syntax, interpolation works well to disambiguate your intent, which supports my point. It's really just a highly specialized form of a different operator, which says I work on strings, so anything I see that isn't a string coerce to a string. For example, in Perl $varOne . $varTwo Is entirely equivalent to "$varOne$varTwo" The question is why Scala chose to use + when it had other, non-ambiguous options, like above.
      - airless_bar 10y ago
        To be more familiar to Java developers. There are some thoughts about migrating people away from + toward string interpolation. But automated conversion tools are required before this can happen.
int_19h 10y ago
'+' works great as a concatenation operator, so long as you don't ever try to implicitly convert the values. Case in point - Python: >>> 1+2 3 >>> "1"+"2" '12' >>> "1"+2 Traceback (most recent call last): File "<stdin>", line 1, in <module> TypeError: Can't convert 'int' object to str implicitly
- kbenson 10y ago
  Those are literals, not variables. My whole argument is about the ambiguity introduced when you are implicitly coercing variables. But yes, if the language does not coerce between string and numeric types, it's a non-issue. I'm specifically talking about supporting coercion but continuing to use '+' for concatenation of strings (and ==/!= for equivalence testing of strings as well).
munificent 10y ago
> There's a very specific reason Perl opted for '.' to concatenate strings instead of + I don't see making string concatenation ambiguous with property access being a real improvement. At least use `..` or some other unused punctuation.
- kbenson 10y ago
  In Perl, '.' is not property access. I'm not trying to imply '.' is the best solution for a language where it's already in use, but that a separate, unambiguous symbol would be better. For example, Perl 6 moved to using '.' for calling methods, and uses '~' for concatenation. It's not like just changing '+' is sufficient anyway, there is still string equivalence to consider (outlined in my other replies).
skoczymroczny 10y ago
D uses + for addition and ~ for concatenation
FraaJad 10y ago
D does. auto greeting = "Hello" ~ " World!"; immutable x = 9 + 99; auto:immutable::var:val