I don't pay by the character but I do read by the character. I think there's a huge readability gain in having classes that fit on a single screen, which just isn't practical in Java (if nothing else, because of all the getters and setters that scala's uniform access principle lets you avoid).
I think the focus on operator overloading is misplaced; in C you might not be able to write "a + b" and have it launch some missiles, but you can write "add(a, b)" and have it launch some missiles, which is just as bad. If anything Scala is more predictable and uniform here - "a + b" is just sugar for "a.+(b)", methods and operators work the same way, and the operator precedence list you have to memorize is much shorter than C's.
In a well-designed library, it does what it looks like - whatever "~" means in the language of that domain. In a badly-designed library it could do anything. Just like .add().
(It's normal for the same symbol to mean different things in different domains, even in Java. If a and b are BigIntegers, a.add(b) means one thing; if a and b are Wicket components, a.add(b) means something quite different. Wicket remains a respected, well-designed library even though it "overloads" the word "add" in this way)
(Another reply points out that it has the same meaning on numeric types - bitwise negation - as in Java, but I doubt that's what you're asking about)
When dealing with arithmetic equations the cognitive burden of add vs + can be quite high. Not allowing the overriding of arithmetic operators means that all new mathematical code you right will be second class vs primitives, encouraging people to not use special types in math operations. This leads to unit mismatches and other sorts of bugs.
The ~ operator in scala is the same as in java (if it isn't overloaded)
Comments
I don't pay by the character but I do read by the character. I think there's a huge readability gain in having classes that fit on a single screen, which just isn't practical in Java (if nothing else, because of all the getters and setters that scala's uniform access principle lets you avoid).
I think the focus on operator overloading is misplaced; in C you might not be able to write "a + b" and have it launch some missiles, but you can write "add(a, b)" and have it launch some missiles, which is just as bad. If anything Scala is more predictable and uniform here - "a + b" is just sugar for "a.+(b)", methods and operators work the same way, and the operator precedence list you have to memorize is much shorter than C's.
Humans read by the word, not by the individual letters. + vs add() is not a real cognitive burden.
Btw what does the operator ~ do in scala?
In a well-designed library, it does what it looks like - whatever "~" means in the language of that domain. In a badly-designed library it could do anything. Just like .add().
(It's normal for the same symbol to mean different things in different domains, even in Java. If a and b are BigIntegers, a.add(b) means one thing; if a and b are Wicket components, a.add(b) means something quite different. Wicket remains a respected, well-designed library even though it "overloads" the word "add" in this way)
(Another reply points out that it has the same meaning on numeric types - bitwise negation - as in Java, but I doubt that's what you're asking about)
I'm not sure what you mean by word, but + vs. add() definitely have different levels of cognitive burden:
Compare: (a + (b + c)) + d vs. add(add(a, add(b, c)), d)
One is arithmetic, the other is polish notation.
Even polish notation benefits from +, IMO.
+ + a + b c d
We can also (with mainstream OO syntax) make add infix and it's still ugly:
a.add(b.add(c)).add(d)
Yuck, really? I find that much less readable than "add(add(a, add(b, c)), d)"
shrug I've probably done more rpn. A huge component of "readable" is "how similar is it to stuff I am used to reading".
I do have to read it backward and build the stack, but that's basically intuitive at this point.
When dealing with arithmetic equations the cognitive burden of add vs + can be quite high. Not allowing the overriding of arithmetic operators means that all new mathematical code you right will be second class vs primitives, encouraging people to not use special types in math operations. This leads to unit mismatches and other sorts of bugs.
The ~ operator in scala is the same as in java (if it isn't overloaded)