It is just symbolic names, like doing abstract mathematics with letters instead of numbers.
Except for C, Java and Go, all the remaining mainstream languages allow for symbolic names in the functions/methods.
I never understood what was the big deal.
Yeah until you have to work with java's Bignums one day, then you start wanting to choke people to death.
Some people seem to think that if they don't use, then it doesn't matter. In many business applications, you don't even need floating point (you just transfer data to the database and back), anyway.
Are floats and doubles "little features"?
In computer graphics, you need lots of floating point calculations. Are ints and longs "little features"?
In embedded software, you usually don't want to use resizable strings (C doesn't even have this feature built-in), because reallocations are expensive or unavailable. Are resizable strings (or containers) "little features"?
Different programs have different needs. If you haven't stumbled upon a good use case, doesn't mean that it's useless.
Then you have to take into account a few other criteria, such as [1] internal coherence in the language, [2] difficulty in implementation (and explaining to others) [3] what your target audience is, and what they want, [4] what competitors are doing.
I think full operator overloading would hurt [2], but special-casing Bignums would not hurt [1], [2] at all (as I said, JSP EL already have +,-,*,/, etc. , String already have +, +=).
[3] This is what this thread is all about, no need to repeat :-D
And [4]... Well in this case Java is really playing catch up.
It doesn't really matter, some people see classes/objects as a minor feature too. I agree with him: operator overloading is not a minor feature and it's probably one of the reasons I am not very fond of Java.
There's an axiom to be found somewhere there. If it's a hill, someone will be willing to die on it.
I have never heard a convincing theory of why some language communities were careful in their use of operators, whilst others went overboard. In the absence of such a theory, it's a risky feature to add.
I'd prefer if that option stays off the table. Given that java users are on ides, autocompletion makes an api call a one character effort anyway and saves us from tons of stupid operators.
"List.add(otherList) <-- what does this do? Why, compared to operators, would a function name be any better than an operator? Mathematics are part of computer science, and denying basic operators for a reason like "because someone might misuse them" is like denying functions because someone may implement a sum() and call it lcm() (and then we're back to goto land). You're confusing a programmer's error (bad choice of a name/operator function) with a language feature. Just because people can write bad code it does not mean we should disallow them to write great code."
Honestly, it's about time the Java crowd stops with the mantra and starts thinking from themselves. Or at least, learn why the reason you hate operator overloading is fallacious.