5 ms·

I actually like how conservative Java has been with making language changes. People go nuts with language features because they can, not necessarily because th

by cletus 6y ago

I actually like how conservative Java has been with making language changes. People go nuts with language features because they can, not necessarily because they have a good reason. this it the big problem I have with Scala, for example. Sure arithmetic operator overloading with numeric types makes sense. Even the parenthesis operator overloading in C++ for functors makes sense. Then you have the Scala SBT build system and percent operator overloading. I actually like how Rust does this. You don't overload the operators per se. You implement traits with named methods like Add that will allow you to use the operators. This, to me, is the best of both worlds. I personally think Java has been just fine without operator overloading so there's no pressing need to add it now but, if they do, please follow the Rust model.

lmm 6y ago
> Then you have the Scala SBT build system and percent operator overloading. SBT is a fractal of bad design, the funny function names are just the most superficial of its problems. > I actually like how Rust does this. You don't overload the operators per se. You implement traits with named methods like Add that will allow you to use the operators. This, to me, is the best of both worlds. It's still just an extra unnecessary indirection where you have to remember which is which. What Scala does is much simpler - the + method is called +, the / method is called /, and so on. Yes, defining a function called %++< is probably a bad idea, but defining a function called YqqZ is probably a bad idea too, and few programming languages feel a need to ban that.
- deleted 6y ago
  [deleted]
winter_squirrel 6y ago
As someone who has to often work exclusively with bigdecimal / ... type code, not having operator overloading a thing makes code so much more verbose and hard to follow when doing mathematical expressions using them
aardvark179 6y ago
I mostly agree, but I think value types are likely to put pressure on this area. I think C++ style overloading would be a mistake, but maybe a monoid interface and some language changes to turn operators in to method calls could work. The thing that Java does well on is that it is easy to read and you wouldn’t want to break that property. Understanding the types of expressions can be hard enough without operators doing weird things, but having a system that doesn’t allow adding two different numerical types would also feel poor.
johnnycerberus 6y ago
I believe that once value types will be adopted by the JVM, operator overloading proposal for Java will be imminent. Meanwhile, there's actually a way to introduce operator overloading into your Java codebase today, the compiler plugin is called Manifold [1] [1] https://github.com/manifold-systems/manifold https://github.com/manifold-systems/manifold
habitue 6y ago
Agreed, the haskell / rust overloading where there's a loosely enforced[^1] but implied contract is probably the best of both worlds. But even without strong constraints, the language's culture is a huge aspect of whether it becomes a problem or not. For example, in python, the language has almost[^2] no constraints on overloading, but people generally use it in very reasonable ways. [^1] the typeclass/trait has an interface that is enforced, but there's usually also some implied laws that the type checker can't verify for you [^2] the big exception being comparison methods like `__leq__` which throw a runtime error if the result isn't a boolean, much to the consternation of DSL writers
- mantap 6y ago
  Haskell has the worst operator overloading of any language I've used. There's tons of niche operators, only some of which have names, it's so hard to Google them. Haskell should have enforced that every operator must have a `name`.
  - tome 6y ago
    > There's tons of niche operators, only some of which have names, it's so hard to Google them. Firstly, Hoogle is your friend https://www.stackage.org/lts-17.8/hoogle?q=%3E%3D%3E https://www.stackage.org/lts-17.8/hoogle?q=%3E%3D%3E Secondly, you can Google them these days https://www.google.com/search?hl=en&q=%3E%3D%3E https://www.google.com/search?hl=en&q=%3E%3D%3E
    - dllthomas 6y ago
      SymbolHound was invaluable, once upon a time.
thaumasiotes 6y ago
> I actually like how Rust does this. You don't overload the operators per se. You implement traits with named methods like Add that will allow you to use the operators. This, to me, is the best of both worlds. What's the difference supposed to be? Why do I care whether my "add two abstract data types" method is named "__add__" or "operator+"?
- Igelau 6y ago
  I don't Rust, but if I had to guess, it helps keep you from defining operators that don't make sense. Like a + that actually means concat. You could still do that, but now you'd be implementing it as something you're calling "add" and that might feel dirty. String concatenation probably isn't the best example, but it's the first one that came to mind.
  - CUViper 6y ago
    That's a funny example, because Rust's `String` does implement `Add` as concatenation! Many think this was a mistake though. https://doc.rust-lang.org/std/string/struct.String.html#impl-Add%3C%26%27_%20str%3E https://doc.rust-lang.org/std/string/struct.String.html#impl...

by cletus 6y ago

lmm 6y ago

> Then you have the Scala SBT build system and percent operator overloading. SBT is a fractal of bad design, the funny function names are just the most superficial of its problems. > I actually like how Rust does this. You don't overload the operators per se. You implement traits with named methods like Add that will allow you to use the operators. This, to me, is the best of both worlds. It's still just an extra unnecessary indirection where you have to remember which is which. What Scala does is much simpler - the + method is called +, the / method is called /, and so on. Yes, defining a function called %++< is probably a bad idea, but defining a function called YqqZ is probably a bad idea too, and few programming languages feel a need to ban that.

deleted 6y ago
[deleted]

winter_squirrel 6y ago

As someone who has to often work exclusively with bigdecimal / ... type code, not having operator overloading a thing makes code so much more verbose and hard to follow when doing mathematical expressions using them

aardvark179 6y ago

I mostly agree, but I think value types are likely to put pressure on this area. I think C++ style overloading would be a mistake, but maybe a monoid interface and some language changes to turn operators in to method calls could work. The thing that Java does well on is that it is easy to read and you wouldn’t want to break that property. Understanding the types of expressions can be hard enough without operators doing weird things, but having a system that doesn’t allow adding two different numerical types would also feel poor.

johnnycerberus 6y ago

I believe that once value types will be adopted by the JVM, operator overloading proposal for Java will be imminent. Meanwhile, there's actually a way to introduce operator overloading into your Java codebase today, the compiler plugin is called Manifold [1] [1] https://github.com/manifold-systems/manifold https://github.com/manifold-systems/manifold

habitue 6y ago

Agreed, the haskell / rust overloading where there's a loosely enforced[^1] but implied contract is probably the best of both worlds. But even without strong constraints, the language's culture is a huge aspect of whether it becomes a problem or not. For example, in python, the language has almost[^2] no constraints on overloading, but people generally use it in very reasonable ways. [^1] the typeclass/trait has an interface that is enforced, but there's usually also some implied laws that the type checker can't verify for you [^2] the big exception being comparison methods like `__leq__` which throw a runtime error if the result isn't a boolean, much to the consternation of DSL writers

mantap 6y ago
Haskell has the worst operator overloading of any language I've used. There's tons of niche operators, only some of which have names, it's so hard to Google them. Haskell should have enforced that every operator must have a `name`.
- tome 6y ago
  > There's tons of niche operators, only some of which have names, it's so hard to Google them. Firstly, Hoogle is your friend https://www.stackage.org/lts-17.8/hoogle?q=%3E%3D%3E https://www.stackage.org/lts-17.8/hoogle?q=%3E%3D%3E Secondly, you can Google them these days https://www.google.com/search?hl=en&q=%3E%3D%3E https://www.google.com/search?hl=en&q=%3E%3D%3E
  - dllthomas 6y ago
    SymbolHound was invaluable, once upon a time.

thaumasiotes 6y ago

> I actually like how Rust does this. You don't overload the operators per se. You implement traits with named methods like Add that will allow you to use the operators. This, to me, is the best of both worlds. What's the difference supposed to be? Why do I care whether my "add two abstract data types" method is named "__add__" or "operator+"?

Igelau 6y ago
I don't Rust, but if I had to guess, it helps keep you from defining operators that don't make sense. Like a + that actually means concat. You could still do that, but now you'd be implementing it as something you're calling "add" and that might feel dirty. String concatenation probably isn't the best example, but it's the first one that came to mind.
- CUViper 6y ago
  That's a funny example, because Rust's `String` does implement `Add` as concatenation! Many think this was a mistake though. https://doc.rust-lang.org/std/string/struct.String.html#impl-Add%3C%26%27_%20str%3E https://doc.rust-lang.org/std/string/struct.String.html#impl...