3 ms·

> Were there ever any real objective [hah] studies done about how much it improved software development? And did they show a significant improvement? I think y

> Were there ever any real objective [hah] studies done about how much it improved software development? And did they show a significant improvement? I think years of hard experience across the industry found out that, for example, multiple inheritance and operator overloading caused more problems than they solved. Both features were taught and advocated back in the day, and now "there be dragons" signs have sprung up and most of the literature today warns the journeyman programmer to avoid them.

throwawaylinux 5y ago
Right. What I want to know is, what was the basis for claiming all this would be so great in the first place? It appears to have been almost entirely free of any evidence, as far as I've been able to tell. It's mind boggling to me when we see the kinds of people in the industry and their demands for data and evidence when it comes to other subjects.
jcranberry 5y ago
I've actually never really encountered issues with operator overloading. Is it just ADL, or are there any other canonical operator overloading issues?
- tonyedgecombe 5y ago
  It was abused a lot in C++, mostly because of weaknesses in other parts of the language.
  - bsenftner 5y ago
    Bullshit, it was the weakness in those developer's minds that screwed their use of this perfectly fine language feature. This is a propaganda war, people. We are being told we are too dumb to handle knives. And the truth is, our industry lets incompetents play our roles, and we (those smart enough to use knives) must suffer the ramifications of those who stab themselves repeatedly and they cry out "it's the language!"
    - zanellato19 5y ago
      Is this parody?
spacechild1 5y ago
> operator overloading caused more problems than they solved [citation needed] Just because operator overloading can be abused doesn't mean that it isn't a massive boon in certain problem spaces (e.g. math libraries, SIMD libraries, etc.)
- aeldidi 5y ago
  I mean, the standard way to do IO in C++ involves spamming the left shift operator (<<), I can only assume because it looks like an arrow? This is definitely a shallow thing, but I'd argue that for this single reason operator overloading definitely causes more problems than it solves (in C++), due to things like: 1. translating format strings to other languages is extremely difficult because the position of expressions in the message is fixed. 2. modifying how things are printed requires modifying global state, and it's easy to forget to reset the flags on std::cout after setting the precision of floats or something. There's also the famous question of "what does the multiplication operator do on vectors?" problem, but that's something that could be solved by simply having a standard "vector" interface that defines it in a particular way. Overall I don't fully disagree, but seeing as it happened once with C++, I can imagine it can happen again in some equally widespread language (Javascript with it's + operator on strings maybe?).
  - spacechild1 5y ago
    > 2. modifying how things are printed requires modifying global state This only applies to std:: cout and std::cerr. Other stream interfaces, like std::fstream or std::stringstream don't have this problem. Also, it is orthogonal to operator overloading.

throwawaylinux 5y ago

Right. What I want to know is, what was the basis for claiming all this would be so great in the first place? It appears to have been almost entirely free of any evidence, as far as I've been able to tell. It's mind boggling to me when we see the kinds of people in the industry and their demands for data and evidence when it comes to other subjects.

jcranberry 5y ago

I've actually never really encountered issues with operator overloading. Is it just ADL, or are there any other canonical operator overloading issues?

tonyedgecombe 5y ago
It was abused a lot in C++, mostly because of weaknesses in other parts of the language.
- bsenftner 5y ago
  Bullshit, it was the weakness in those developer's minds that screwed their use of this perfectly fine language feature. This is a propaganda war, people. We are being told we are too dumb to handle knives. And the truth is, our industry lets incompetents play our roles, and we (those smart enough to use knives) must suffer the ramifications of those who stab themselves repeatedly and they cry out "it's the language!"
  - zanellato19 5y ago
    Is this parody?

spacechild1 5y ago

> operator overloading caused more problems than they solved [citation needed] Just because operator overloading can be abused doesn't mean that it isn't a massive boon in certain problem spaces (e.g. math libraries, SIMD libraries, etc.)

aeldidi 5y ago
I mean, the standard way to do IO in C++ involves spamming the left shift operator (<<), I can only assume because it looks like an arrow? This is definitely a shallow thing, but I'd argue that for this single reason operator overloading definitely causes more problems than it solves (in C++), due to things like: 1. translating format strings to other languages is extremely difficult because the position of expressions in the message is fixed. 2. modifying how things are printed requires modifying global state, and it's easy to forget to reset the flags on std::cout after setting the precision of floats or something. There's also the famous question of "what does the multiplication operator do on vectors?" problem, but that's something that could be solved by simply having a standard "vector" interface that defines it in a particular way. Overall I don't fully disagree, but seeing as it happened once with C++, I can imagine it can happen again in some equally widespread language (Javascript with it's + operator on strings maybe?).
- spacechild1 5y ago
  > 2. modifying how things are printed requires modifying global state This only applies to std:: cout and std::cerr. Other stream interfaces, like std::fstream or std::stringstream don't have this problem. Also, it is orthogonal to operator overloading.