8 ms·

I recently started developing in Java and the thing I find most irritating is the lack of operators overload.

pcote 14y ago
Why? Sure, overloading a "+" operator can be elegant looking. But the aesthetic gain vs. maintainability doesn't seem to be worth the tradeoff 99% of the time. I certainly wouldn't want to be the one who has to debug the thing because someone accidentally side effected one of the "operands".
- shin_lao 14y ago
  Without operator overloading you cannot write an EDSL.
- stelonix 14y ago
  Nonsense. To paraphrase myself from a similar discussion on reddit: "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.
  - gjulianm 14y ago
    Absolutely agree with you. I haven't seen yet a real reason to avoid including operator overloading in any language.
    - twic 14y ago
      There is exactly one such reason: programmers. Python programmers were given operator overloading, and did a good job with it. C++ and Scala programmers were given operator overloading, and did a bad job with it (eg << in C++'s streams, ^ in Scala's specs2). 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.
      - stelonix 14y ago
        Well, it's time to disallow functions, since someone can misuse their names. And exceptions, since someone might use it as goto. Might as well get rid of non-primitive types, there might be a very bad person willing to name a class with a completely meaningless name.
  - smackfu 14y ago
    It just seems an odd hill to die on. Just a minor little feature that most people would use only occasionally in their objects.
    - stelonix 14y ago
      I disagree wholeheartedly: the verbosity caused by a lack of such an 'irrelevant' feature makes my eyes bleed. 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.
    - masklinn 14y ago
      > Just a minor little feature that most people would use only occasionally in their objects. Yeah until you have to work with java's Bignums one day, then you start wanting to choke people to death.
      - PySlice 14y ago
        Yeah, I guess it sucks if you work with Bignums. I would be happy if BigInteger and BigDecimal were promoted String-level language support: still implemented as classes, but with compiler support. They could add indexing [] for collections, but I can live with .get() and .put(). 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.
        smackfu 14y ago
        This same logic can be used to defend any "little feature". Language design is all about where you draw those lines.
  - pjmlp 14y ago
    That is what I keep repeating when people complain about operator overloading. 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.
  - smrtinsert 14y ago
    the nice part about java is the legibility. I can simply start with a new instance of your object and auto complete to the method that I want. Once operator overloading joins the fray everyone is off to the races for crappy dsl of the week. "here's how you do the XXX lib way". 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.
    - prodigal_erik 14y ago
      Java users are stuck with IDEs largely because it's so hard to design a decent DSL when you're confined to Java method syntax. Autocomplete doesn't make it any easier to read bulky verbose code, just gives you more of it.
- mikeash 14y ago
  It seems to me that it's a cultural problem more than anything. People know that they shouldn't take an existing, well-known method name and repurpose it for something completely different. But somehow a lot of people think it's OK to repurpose an operator to mean something completely different just because it's convenient. C++ being the classic example. << means bitshift. Just because it looks like arrows doesn't mean it's sane to repurpose it into a completely different "output this" operator. You wouldn't override "leftShift" to output stuff, so why do people do it with <<? I think it depends a lot on the languages. Operator overloading is easy and common in Python, but in my (limited) experience, it's used to create new classes which respond to existing operators with existing semantics, e.g. to make new number classes. For this, it's great. There's no particular reason the types built-in to the language should get special treatment for operators, as long as programmers can resist the temptation to be idiots.
  - stelonix 14y ago
    "But somehow a lot of people think it's OK to repurpose an operator to mean something completely different just because it's convenient. C++ being the classic example." Do you have any data to prove such assertions? A C++ STL operator chosen more than a decade ago is not enough statistical data for one to have such a narrow-minded vision and say these bold statements. Maybe you need to check all the nice C++ libraries that make use of operator overloading.
    - pjmlp 14y ago
      The common example people pull off the hat with C++ is the use of << operator for streams and some UI toolkits. Which I personally never had a problem with.
    - mikeash 14y ago
      You seem to have confused the phrase "classic example" with "the worst thing out there, with data to prove it". It's an example. Do you dispute that? It's classic. That's subjective, and I claim it by raw assertion. That's it.
    - tragomaskhalos 14y ago
swift 14y ago
In my opinion good uses of operator overloading are ones that preserve the mathematical properties of the operator, so that the operator is in some sense "the same operation", just for different types. By this standard "+" for string concatenation isn't a great choice since string concatenation isn't commutative, but addition is. The same can be said for using "*" for matrix multiplication. If you define these kinds of operator overloads, you have to be very conservative about writing generic code that uses the operator. Given these limitations, and the fact that most languages have relatively few built-in operators to choose from, I find that just operator overloading isn't enough. You really want the ability to define new operators as well. That's something Java (and C#, and C++, and many other languages) would really benefit from.
- kbenson 14y ago
  You mean like this? (not Java): multi infix:<plus>(Int $a, Int $b) { return $a + $b; } multi infix:<plus>(Str $a, Str $b) { return $a ~ $b; } say 10 plus 4; # 14 say "foo" plus "bar"; # foobar
  - iso8859-1 14y ago
    what's that? Perl 6?
    - kbenson 14y ago
      Yep. Much of the language is implemented in itself (at least in Rakudo), using such structures: https://github.com/rakudo/rakudo/blob/nom/src/core/Int.pm#L100 https://github.com/rakudo/rakudo/blob/nom/src/core/Int.pm#L1... NQP in that link is "Not Quite Perl", a subset of the language which is the what actually needs to be implemented to support Perl 6. This is what's almost done being ported to Java. Again, for Rakudo, which is one implementation.
- pjmlp 14y ago
  Quite a few languages allow the use of operators, or special characters if you prefer, as names. Without any restriction, except for a few basic ones.

pcote 14y ago

Why? Sure, overloading a "+" operator can be elegant looking. But the aesthetic gain vs. maintainability doesn't seem to be worth the tradeoff 99% of the time. I certainly wouldn't want to be the one who has to debug the thing because someone accidentally side effected one of the "operands".

shin_lao 14y ago
Without operator overloading you cannot write an EDSL.
stelonix 14y ago
Nonsense. To paraphrase myself from a similar discussion on reddit: "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.
- gjulianm 14y ago
  Absolutely agree with you. I haven't seen yet a real reason to avoid including operator overloading in any language.
  - twic 14y ago
    There is exactly one such reason: programmers. Python programmers were given operator overloading, and did a good job with it. C++ and Scala programmers were given operator overloading, and did a bad job with it (eg << in C++'s streams, ^ in Scala's specs2). 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.
    - stelonix 14y ago
      Well, it's time to disallow functions, since someone can misuse their names. And exceptions, since someone might use it as goto. Might as well get rid of non-primitive types, there might be a very bad person willing to name a class with a completely meaningless name.
- smackfu 14y ago
  It just seems an odd hill to die on. Just a minor little feature that most people would use only occasionally in their objects.
  - stelonix 14y ago
    I disagree wholeheartedly: the verbosity caused by a lack of such an 'irrelevant' feature makes my eyes bleed. 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.
  - masklinn 14y ago
    > Just a minor little feature that most people would use only occasionally in their objects. Yeah until you have to work with java's Bignums one day, then you start wanting to choke people to death.
    - PySlice 14y ago
      Yeah, I guess it sucks if you work with Bignums. I would be happy if BigInteger and BigDecimal were promoted String-level language support: still implemented as classes, but with compiler support. They could add indexing [] for collections, but I can live with .get() and .put(). 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.
      - smackfu 14y ago
        This same logic can be used to defend any "little feature". Language design is all about where you draw those lines.
- pjmlp 14y ago
  That is what I keep repeating when people complain about operator overloading. 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.
- smrtinsert 14y ago
  the nice part about java is the legibility. I can simply start with a new instance of your object and auto complete to the method that I want. Once operator overloading joins the fray everyone is off to the races for crappy dsl of the week. "here's how you do the XXX lib way". 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.
  - prodigal_erik 14y ago
    Java users are stuck with IDEs largely because it's so hard to design a decent DSL when you're confined to Java method syntax. Autocomplete doesn't make it any easier to read bulky verbose code, just gives you more of it.
mikeash 14y ago
It seems to me that it's a cultural problem more than anything. People know that they shouldn't take an existing, well-known method name and repurpose it for something completely different. But somehow a lot of people think it's OK to repurpose an operator to mean something completely different just because it's convenient. C++ being the classic example. << means bitshift. Just because it looks like arrows doesn't mean it's sane to repurpose it into a completely different "output this" operator. You wouldn't override "leftShift" to output stuff, so why do people do it with <<? I think it depends a lot on the languages. Operator overloading is easy and common in Python, but in my (limited) experience, it's used to create new classes which respond to existing operators with existing semantics, e.g. to make new number classes. For this, it's great. There's no particular reason the types built-in to the language should get special treatment for operators, as long as programmers can resist the temptation to be idiots.
- stelonix 14y ago
  "But somehow a lot of people think it's OK to repurpose an operator to mean something completely different just because it's convenient. C++ being the classic example." Do you have any data to prove such assertions? A C++ STL operator chosen more than a decade ago is not enough statistical data for one to have such a narrow-minded vision and say these bold statements. Maybe you need to check all the nice C++ libraries that make use of operator overloading.
  - pjmlp 14y ago
    The common example people pull off the hat with C++ is the use of << operator for streams and some UI toolkits. Which I personally never had a problem with.
  - mikeash 14y ago
    You seem to have confused the phrase "classic example" with "the worst thing out there, with data to prove it". It's an example. Do you dispute that? It's classic. That's subjective, and I claim it by raw assertion. That's it.
  - tragomaskhalos 14y ago

swift 14y ago

In my opinion good uses of operator overloading are ones that preserve the mathematical properties of the operator, so that the operator is in some sense "the same operation", just for different types. By this standard "+" for string concatenation isn't a great choice since string concatenation isn't commutative, but addition is. The same can be said for using "*" for matrix multiplication. If you define these kinds of operator overloads, you have to be very conservative about writing generic code that uses the operator. Given these limitations, and the fact that most languages have relatively few built-in operators to choose from, I find that just operator overloading isn't enough. You really want the ability to define new operators as well. That's something Java (and C#, and C++, and many other languages) would really benefit from.

kbenson 14y ago
You mean like this? (not Java): multi infix:<plus>(Int $a, Int $b) { return $a + $b; } multi infix:<plus>(Str $a, Str $b) { return $a ~ $b; } say 10 plus 4; # 14 say "foo" plus "bar"; # foobar
- iso8859-1 14y ago
  what's that? Perl 6?
  - kbenson 14y ago
    Yep. Much of the language is implemented in itself (at least in Rakudo), using such structures: https://github.com/rakudo/rakudo/blob/nom/src/core/Int.pm#L100 https://github.com/rakudo/rakudo/blob/nom/src/core/Int.pm#L1... NQP in that link is "Not Quite Perl", a subset of the language which is the what actually needs to be implemented to support Perl 6. This is what's almost done being ported to Java. Again, for Rakudo, which is one implementation.
pjmlp 14y ago
Quite a few languages allow the use of operators, or special characters if you prefer, as names. Without any restriction, except for a few basic ones.