4 ms·

I don't know nothin' about Go. But this complaint really surprised me: > Go not letting you do operator overloading, harking back to the Java days where a ==

I don't know nothin' about Go. But this complaint really surprised me: > Go not letting you do operator overloading, harking back to the Java days where a == b isn't the same as a.equals(b) Does this guy really not understand that in a mutable language, (eq ...) is not the same as (equalp ...) and should never be confused with it? Also: operator overloading is the spawn of Satan.

WalterBright 4y ago
> operator overloading is the spawn of Satan I used to agree with you, because of the abuse of operator overloading like iostreams and making DSLs with it. D does support it, but in a way that discourages non-arithmetic uses (such as it won't allow < <= >= > to be overloaded separately). Operator overloading allows for things like complex numbers, arbitrary precision numeric types, etc., to be done with a library module.
- nemo1618 4y ago
  > Operator overloading allows for things like complex numbers, arbitrary precision numeric types, etc., to be done with a library module. Why is this desirable vs. implementing those types in the language itself? I think we've gone down a weird path where implementing things "in userspace" is seen as an inherent good -- why?
  - WalterBright 4y ago
    > Why is this desirable vs. implementing those types in the language itself? That's a very good question. 1. It's simpler. In D, we transitioned from a builtin complex type to a library type. It was a happy experience. The simpler the compiler, the easier it is to deal with. 2. Most any programmer can create a library type. Relatively few can modify a compiler to add a new type. 3. It takes the pressure off the compiler team to develop more arithmetic types. 4. Users can add arithmetic types without needing anybody's consent, and can do it right now. 5. It tests and verifies the metaprogramming abilities of the language.
    - joshuamorton 4y ago
      Elaborating on 3/4: the domain experts don't need to be compiler experts too. There are always going to be more numeric-like types (int, float, complex, bigint, rational, symbolic-comp types etc.). Numeric vectors that act like numbers are useful (see: numpy), and trying to stick those all into the language is far harder than allowing extensibility.
  - kaba0 4y ago
    This is probably the best talk ever on the general topic: https://m.youtube.com/watch?v=_ahvzDzKdB0 https://m.youtube.com/watch?v=_ahvzDzKdB0 [Growing a language by Guy Steele], seriously give it a look if you have the time and do put up with the seemingly strange start. But at around the end it asks this (paraphrasing): Should a language have complex numbers implemented natively? Should it have numbers module n implemented natively? What about intervals, or rational numbers? I also dislike the ridiculous overloading of cryptic symbols, but neither extreme is good. Not allowing overloading will give you BigDecimal.of(3).add(BigDecimal.ONE).divide… , while allowing it unrestricted will give you things like msg #!! something. But perhaps a sane middle ground is to allow only basic operators (+,-,*,/) to be overloadable.
delta64 4y ago
The author definitely understands that. The point is: when you don't have operator overloading you get stuff like that which does demonstrably confuse many people In languages with operator overloading this just isn't a concern at all because == does the obvious thing
- AnimalMuppet 4y ago
  == should do the obvious thing. But with operator overloading, it's not clear that it does, unless you need to read the implementation of == very carefully.
  - delta64 4y ago
    How is that any different to some opaque method call? By the same logic `a.equals(b)` might be doing something funky under the hood
    - AnimalMuppet 4y ago
      True. But people think about it a bit differently. People don't always expect == to be a function call.
      - delta64 4y ago
        Sure, but I think '== might be a function call' is a lot less confusing than '== sometimes compares for equal value and sometimes doesn't'
- SeanLuke 4y ago
  > In languages with operator overloading this just isn't a concern at all because == does the obvious thing And what is the obvious thing? It varies wildly among languages, even within C++ itself.
  - delta64 4y ago
    The obvious thing is to check if the contents are equal. I don't know what cursed C++ you're looking at if you're finding a ton of string implementations not doing exactly that...
josephcsible 4y ago
Usually you do want to compare by value, so it should get the obvious syntax. When you want to compare by reference, you should write if(&a == &b) or ReferenceEquals(a, b) or something.
jeroenhd 4y ago
I don't get the problem with operator overloading. Yes, it can be implemented badly, but so can the equals() override. You can't even call a.equals(b) safely in many programming languages because either a or b could be null. I've run into so many null pointer exceptions in Java because someone wrote a.equals(b) when they clearly meant a!=null && a.equals(b). Every time I have to write `BigDecimal sum = one.add(two).add(three).minus(four)` I cry a little. This is effectively no different from operator overloading and it's what special number implementations in all languages without operator overloading seem to end up doing out of necessity.
ak217 4y ago
Without operator overloading, it is basically impossible to adapt a language for numerical computing/data science applications. Yeah, operator overloading is a powerful tool that's easy to abuse; no, it's not optional if you want the language to succeed at all in a whole bunch of applications.
- SeanLuke 4y ago
  Mathematica works just fine without user-defined operator overloading.
SubjectToChange 4y ago
> Also: operator overloading is the spawn of Satan. It's necessary for "powerful" generic programming. In fact, the entire reason user-defined data types can be easily used in C++ libraries like CGAL, Eigen, fmt, Kokkos, ranges-v3, etc, is because of operator overloading.
zigger69 4y ago
> Also: operator overloading is the spawn of Satan. It is. And I'm glad Zig has none of that. `==` only works for primitives and you will never be confused.
- oxnrtr 4y ago
  Not sure that's a good idea. The concept of some types being special should not be something exposed to the user.

WalterBright 4y ago

> operator overloading is the spawn of Satan I used to agree with you, because of the abuse of operator overloading like iostreams and making DSLs with it. D does support it, but in a way that discourages non-arithmetic uses (such as it won't allow < <= >= > to be overloaded separately). Operator overloading allows for things like complex numbers, arbitrary precision numeric types, etc., to be done with a library module.

nemo1618 4y ago
> Operator overloading allows for things like complex numbers, arbitrary precision numeric types, etc., to be done with a library module. Why is this desirable vs. implementing those types in the language itself? I think we've gone down a weird path where implementing things "in userspace" is seen as an inherent good -- why?
- WalterBright 4y ago
  > Why is this desirable vs. implementing those types in the language itself? That's a very good question. 1. It's simpler. In D, we transitioned from a builtin complex type to a library type. It was a happy experience. The simpler the compiler, the easier it is to deal with. 2. Most any programmer can create a library type. Relatively few can modify a compiler to add a new type. 3. It takes the pressure off the compiler team to develop more arithmetic types. 4. Users can add arithmetic types without needing anybody's consent, and can do it right now. 5. It tests and verifies the metaprogramming abilities of the language.
  - joshuamorton 4y ago
    Elaborating on 3/4: the domain experts don't need to be compiler experts too. There are always going to be more numeric-like types (int, float, complex, bigint, rational, symbolic-comp types etc.). Numeric vectors that act like numbers are useful (see: numpy), and trying to stick those all into the language is far harder than allowing extensibility.
- kaba0 4y ago
  This is probably the best talk ever on the general topic: https://m.youtube.com/watch?v=_ahvzDzKdB0 https://m.youtube.com/watch?v=_ahvzDzKdB0 [Growing a language by Guy Steele], seriously give it a look if you have the time and do put up with the seemingly strange start. But at around the end it asks this (paraphrasing): Should a language have complex numbers implemented natively? Should it have numbers module n implemented natively? What about intervals, or rational numbers? I also dislike the ridiculous overloading of cryptic symbols, but neither extreme is good. Not allowing overloading will give you BigDecimal.of(3).add(BigDecimal.ONE).divide… , while allowing it unrestricted will give you things like msg #!! something. But perhaps a sane middle ground is to allow only basic operators (+,-,*,/) to be overloadable.

delta64 4y ago

The author definitely understands that. The point is: when you don't have operator overloading you get stuff like that which does demonstrably confuse many people In languages with operator overloading this just isn't a concern at all because == does the obvious thing

AnimalMuppet 4y ago
== should do the obvious thing. But with operator overloading, it's not clear that it does, unless you need to read the implementation of == very carefully.
- delta64 4y ago
  How is that any different to some opaque method call? By the same logic `a.equals(b)` might be doing something funky under the hood
  - AnimalMuppet 4y ago
    True. But people think about it a bit differently. People don't always expect == to be a function call.
    - delta64 4y ago
      Sure, but I think '== might be a function call' is a lot less confusing than '== sometimes compares for equal value and sometimes doesn't'
SeanLuke 4y ago
> In languages with operator overloading this just isn't a concern at all because == does the obvious thing And what is the obvious thing? It varies wildly among languages, even within C++ itself.
- delta64 4y ago
  The obvious thing is to check if the contents are equal. I don't know what cursed C++ you're looking at if you're finding a ton of string implementations not doing exactly that...

josephcsible 4y ago

Usually you do want to compare by value, so it should get the obvious syntax. When you want to compare by reference, you should write if(&a == &b) or ReferenceEquals(a, b) or something.

jeroenhd 4y ago

I don't get the problem with operator overloading. Yes, it can be implemented badly, but so can the equals() override. You can't even call a.equals(b) safely in many programming languages because either a or b could be null. I've run into so many null pointer exceptions in Java because someone wrote a.equals(b) when they clearly meant a!=null && a.equals(b). Every time I have to write `BigDecimal sum = one.add(two).add(three).minus(four)` I cry a little. This is effectively no different from operator overloading and it's what special number implementations in all languages without operator overloading seem to end up doing out of necessity.

ak217 4y ago

Without operator overloading, it is basically impossible to adapt a language for numerical computing/data science applications. Yeah, operator overloading is a powerful tool that's easy to abuse; no, it's not optional if you want the language to succeed at all in a whole bunch of applications.

SeanLuke 4y ago
Mathematica works just fine without user-defined operator overloading.

SubjectToChange 4y ago

> Also: operator overloading is the spawn of Satan. It's necessary for "powerful" generic programming. In fact, the entire reason user-defined data types can be easily used in C++ libraries like CGAL, Eigen, fmt, Kokkos, ranges-v3, etc, is because of operator overloading.

zigger69 4y ago

> Also: operator overloading is the spawn of Satan. It is. And I'm glad Zig has none of that. `==` only works for primitives and you will never be confused.

oxnrtr 4y ago
Not sure that's a good idea. The concept of some types being special should not be something exposed to the user.