6 ms·

>> Experience from languages that support those features has shown that what we gain in the very few situations where those extensions make sense Nope, this is

>> Experience from languages that support those features has shown that what we gain in the very few situations where those extensions make sense Nope, this is just incorrect. The C++ is completely dominant in large swaths of the software industry largely because operator overloading allows the writing of generic algorithms (which allows you to write large scale software without losing C-like performance). Without operator overloading, it is much harder to write a function that can be specialized on types that weren't specifically designed for such use. In Python, Numpy, the Decimal class, I could really give examples for days of cases where operator overloading is essential. Go doesn't have it, Go doesn't have a lot of things, and Go will always be an also-ran language that isn't adopted outside of a very narrow domain. The fact that built in types are 'special' and only they can support operators such as [] is enough for me to avoid the language. The complete lack of generic programming is more than enough.

fixermark 11y ago
I think we're talking about different things. Can you give an example of how operator overloading improves one's ability to write a function that can be specialized on types that weren't specifically designed for such use?
- justin_vanw 11y ago
  Type 1 defines: .add(x) Type 2 defines: .plus(x) Type 3 defines: .vector_add(x) Now, implement a function 'average' that can work on any of these three types. If you can get everyone in the world to agree to a convention of how to express 'addition', then there is no difference, except we already have a convention for 500 years, and it is the '+' operator. Why you think the '+' operator is confusing but .plus() is not, that is what confuses me. Or how about 'minimum'. In C people end up writing a minimum C macro, because there's not even a way to write one function that works on int, long, float! What a sad world that is, where you have to meta program to implement min(x,y).
  - coldpie 11y ago
    > Now, implement a function 'average' that can work on any of these three types. I'm not convinced this is such a large problem that its solution is worth the myriad downsides that operator overloading is chained to. There's lots of schoolbook examples like this, but I've almost never seen operator overloading used well in practice. There's a few examples, like boost shared pointers are somewhat easier to read, but they're few and far between
    - kllrnohj 11y ago
      Please elaborate on the myriad of downsides that operator overloading is chained to. I am honestly not aware of any downsides that are unique to operator overloading Hint: Things like "they can be abused" or "you can do crazy things like have + return a dot product" are not unique to operators. I can very easily define .clone() in Java to return a dot product as well, or have .equals() do in-place addition.
    - pcwalton 11y ago
      > There's lots of schoolbook examples like this, but I've almost never seen operator overloading used well in practice. I do graphics programming and I literally rely on it all the time.
      - woah 11y ago
        As someone above was mentioning, I don't think that go was ever intended for heavy math programming. It's a great language for writing network applications that is more performant and deployable than scripting languages, yet easier to use than low level languages. Use rust or c.
  - innerspirit 11y ago
    At this point, operator overloading would simply be another convention, would it not? Your type would not work with mine if I used .add instead. You did not solve the problem of having to get everyone to agree on a convention.
tptacek 11y ago
Could you go into more detail about why operator overloading enables generic functions in a way simple functions don't? I don't see it.
- justin_vanw 11y ago
  Because you would have to come up with a naming convention ahead of time.
  - tptacek 11y ago
    And you're suggesting that nowhere in what used to be called the C++ Standard Template Library is there a place where they didn't have to come up with a naming convention for functions? I think you may have the causality swapped here; I think <algorithm> looks the way it does because they limited themselves to things that could be easily expressed with operators --- for a long time, to the detriment of the language; see: STL associative containers, operator<, and the longstanding lack of a standard hash table.
    - blub 11y ago
      How was <algorithm> preventing the introduction of a hash table? The hash function is a template parameter, predefined for standard types, no operator needed. Josuttis claims that hash tables didn't make it in C++98 due to lack of time.
- pcwalton 11y ago
  Without operator overloading, it's hard to make generic numeric algorithms palatable. Compare (fake Go-with-Swift-generics syntax): func Distance<N>(x N, y N) N where N Number { return x.Mul(x).Add(y.Mul(y)).Sqrt() } Versus: func Distance<N>(x N, y N) N where N Number { return Sqrt(x * x + y * y) } If your reaction is "well, Distance doesn't look too bad like that", I can replace it with matrix multiplication or point-inside-triangle testing. Not having overloading quickly fails to scale.
  - 11y ago

fixermark 11y ago

I think we're talking about different things. Can you give an example of how operator overloading improves one's ability to write a function that can be specialized on types that weren't specifically designed for such use?

justin_vanw 11y ago
Type 1 defines: .add(x) Type 2 defines: .plus(x) Type 3 defines: .vector_add(x) Now, implement a function 'average' that can work on any of these three types. If you can get everyone in the world to agree to a convention of how to express 'addition', then there is no difference, except we already have a convention for 500 years, and it is the '+' operator. Why you think the '+' operator is confusing but .plus() is not, that is what confuses me. Or how about 'minimum'. In C people end up writing a minimum C macro, because there's not even a way to write one function that works on int, long, float! What a sad world that is, where you have to meta program to implement min(x,y).
- coldpie 11y ago
  > Now, implement a function 'average' that can work on any of these three types. I'm not convinced this is such a large problem that its solution is worth the myriad downsides that operator overloading is chained to. There's lots of schoolbook examples like this, but I've almost never seen operator overloading used well in practice. There's a few examples, like boost shared pointers are somewhat easier to read, but they're few and far between
  - kllrnohj 11y ago
    Please elaborate on the myriad of downsides that operator overloading is chained to. I am honestly not aware of any downsides that are unique to operator overloading Hint: Things like "they can be abused" or "you can do crazy things like have + return a dot product" are not unique to operators. I can very easily define .clone() in Java to return a dot product as well, or have .equals() do in-place addition.
  - pcwalton 11y ago
    > There's lots of schoolbook examples like this, but I've almost never seen operator overloading used well in practice. I do graphics programming and I literally rely on it all the time.
    - woah 11y ago
      As someone above was mentioning, I don't think that go was ever intended for heavy math programming. It's a great language for writing network applications that is more performant and deployable than scripting languages, yet easier to use than low level languages. Use rust or c.
- innerspirit 11y ago
  At this point, operator overloading would simply be another convention, would it not? Your type would not work with mine if I used .add instead. You did not solve the problem of having to get everyone to agree on a convention.

tptacek 11y ago

Could you go into more detail about why operator overloading enables generic functions in a way simple functions don't? I don't see it.

justin_vanw 11y ago
Because you would have to come up with a naming convention ahead of time.
- tptacek 11y ago
  And you're suggesting that nowhere in what used to be called the C++ Standard Template Library is there a place where they didn't have to come up with a naming convention for functions? I think you may have the causality swapped here; I think <algorithm> looks the way it does because they limited themselves to things that could be easily expressed with operators --- for a long time, to the detriment of the language; see: STL associative containers, operator<, and the longstanding lack of a standard hash table.
  - blub 11y ago
    How was <algorithm> preventing the introduction of a hash table? The hash function is a template parameter, predefined for standard types, no operator needed. Josuttis claims that hash tables didn't make it in C++98 due to lack of time.
pcwalton 11y ago
Without operator overloading, it's hard to make generic numeric algorithms palatable. Compare (fake Go-with-Swift-generics syntax): func Distance<N>(x N, y N) N where N Number { return x.Mul(x).Add(y.Mul(y)).Sqrt() } Versus: func Distance<N>(x N, y N) N where N Number { return Sqrt(x * x + y * y) } If your reaction is "well, Distance doesn't look too bad like that", I can replace it with matrix multiplication or point-inside-triangle testing. Not having overloading quickly fails to scale.
- 11y ago