4 ms·
Overloaded operators are great. But overloaded operators that do something entirely different than their intended purpose is bad. So a + operator that does an
by wvenable 1y ago
Overloaded operators are great. But overloaded operators that do something entirely different than their intended purpose is bad. So a + operator that does an add in your custom numeric data type is good. But using << for output is bad.
- ecshafer 1y agoThe first programming language that used overloaded operators I really got into was Scala, and I still love it. I love that instead of Java's x.add(y); I can overload + so that it calls .add when between two objects of type a. It of course has to be used responsibly, but it makes a lot of code really more readable.
- Attrecomet 1y agoExactly, not allowing operator overload leads to Java hell, where we need verbose functions for calls that should be '+' or similar.
- lelanthran 1y ago> The first programming language that used overloaded operators I really got into was Scala, and I still love it. I love that instead of Java's x.add(y); I can overload + so that it calls .add when between two objects of type a. It of course has to be used responsibly, but it makes a lot of code really more readable. The problem, for me, with overloaded operators in something like C++ is that it frequently feels like an afterthought. Doing "overloaded operators" in Lisp (CLOS + MOP) has much better "vibes" to me than doing overloaded operators in C++ or Scala.
- LexiMax 1y agoI will die on the hill that string concatenation should have its own operator, and overloading + for the operation is a mistake. Languages that get it right: SQL, Lua, ML, Perl, PHP, Visual Basic.
- zevets 1y agoAlternatively, any implementation of operator+ should have a notional identity element, an inverse element and be commutative.
- AlotOfReading 1y agoC++ would be a very different language if you couldn't use floats: (NaN + 0.0) != 0.0 + NaN Inf + -Inf != Inf I suspect the algebraists would also be pissed if you took away their overloads for hypercomplex numbers and other exotic objects.
- o11c 1y agoI think it's fine when the language has sufficiently strict types for string concatenation. Unfortunately, many languages allow `string + int`, which is quite problematic. Java is to blame for some of this. And C++ is even worse since literals are `const char[]` which decays to pointer. Languages okay by my standard but not yours include: Python, Ruby.
- paulddraper 1y agoThis is so sad obvious it’s painful. Arithmetic addition and sequence concatenation are very very different. —— Scala got this right as well (except strings, Java holdover) Concatenation is ++
- Animats 1y agoPython managed to totally confuse this. "+" for built-in arrays is concatenation. "+" for NumPy arrays is elementwise addition. Some functions accept both types. That can end badly.
- 112233 1y agoTangential, but Lua is the most write-only language I have had pleasure working with. The implementation and language design are 12 out of 10, top class. But once you need to read someone else's code, and they use overloads liberally to implement MCP and OODB and stuff, all in one codebase, and you have no idea if "." will index table, launch Voyager, or dump core, because everything is dispatched at runtime, it's panic followed by ennui.
- jcelerier 1y agoIf you've done any university-level maths you should have seen the + sign used in many other contexts than adding numbers, why should that be a problem when programming?
- account42 1y agoThere is usually another operator used for concatenation in math though: | or || or ⊕ The first two are already used for bitwise and logical or and the third isn't available in ASCII so I still think overloading + was a reasonable choice and doesn't cause any actual problems IME.
- zbentley 1y agoRegrettably, “intended purpose” is highly subjective. Sure, << for stream output is pretty unintuitive and silly. But what about pipes for function chaining/composition (many languages overload thus), or overriding call to do e.g. HTML element wrapping, or overriding * for matrices multiplied by simple ints/vectors? Reasonable minds can and do differ about where the line is in many of those cases. And because of that variability of interpretation, we get extremely hard to understand code. As much as I have seen value in overloading at times, I’m forced to agree that it should probably not exist entirely.
- AnimalMuppet 1y agoDepends on what you're trying to understand. Let's say I have matrices, and I've overloaded * for multiplying a matrix by a matrix, and a matrix by a vector, and a matrix by a number. And now I write a = b * c; If I'm trying to understand this as one of a series of steps of linear algebra that I'm trying to make sure are right, that is far more comprehensible than a = mat_mult(b,c); because it uses math notation, and that's closer to the way linear algebra is written. But if I take the exact same line and try to understand exactly which functions get called, because I'm worried about numerical stability or performance or something, then the first approach hides the details and the second one is easier to understand. This is always the way it goes with abstraction. Abstraction hides the details, so we can think at a higher level. And that's good, when you're trying to think at the higher level. When you're not, then abstraction just hides what you're really trying to understand.
- fluorinerocket 1y agobut is it element by element multiplication, or matrix multiplication? I honestly just prefer calling matmul.
- wvenable 1y ago> we get extremely hard to understand code The thing is code without operator overloading is also hard to understand because you might have this math thing (BigIntegers, Matrices) and you can't use standard notation.
- butterisgood 1y agoI kind of like that OCaml, which I've also not used a great deal, has different operators for adding floats vs integers etc... Extremely clear at the "call site" what's going on.
- powerboat9 1y agoWhy is using << for output bad? From what I've seen, it's usually not too hard to figure out that the left hand side is some kind of stream and not a number.