4 ms·

I never understand why operator overloading is said to make things more readable. If the meaning of an operator can change wildly with the operands then that's

I never understand why operator overloading is said to make things more readable. If the meaning of an operator can change wildly with the operands then that's just confusing - you can't assume that '==' means what you think it means and you have to go find out what it means. In comparison, having an actual function name to clue me in on what something does is useful. Like, how is "X[y==1,0]" more readable in this case than something like "filterElements(arrayToFilter, arrayOfBools)"? (if I've understood what the original was trying to do, which I'm not sure I have). People seem to confuse "less typing" with "simpler", and that's not true. One of the great strengths of Go is that it rejects this and embraces true simplicity.

grayclhn 6y ago
Long expressions with matrix operations is a pretty standard example. When people talk about operator overloading in data science, they usually mean “standard operations on various arrays of numbers,” which are defined in common libraries or the programming language. Not “I need to define my own ad hoc equalities.”
- marcus_holmes 6y ago
  yeah, I get this. If there are standard definitions of operations that everyone understands, that's fine. But I always think that maybe we should be using new operators for this, instead of overloading existing ones that have other, different, meanings in different contexts.
  - grayclhn 6y ago
    In a data science context, the key operations are math, so overloading makes a lot of sense and is massively helpful in implementing algorithms and equations. I go back and forth on the wisdom of some of the other common uses — filtering, etc. In addition to the problems that have been mentioned, there are often hidden and infrequent but painful performance issues.
    - marcus_holmes 6y ago
      I often think that maths could use the same slap around the chops. Less arcane operators and symbols, more explicit function names please!
      - grayclhn 6y ago
        I consider it kind of important that the notation for expressions like “A²” doesn’t depend on whether A is an integer, real number, complex number, matrix, random variable, etc., (even if the results do) or what the specific domain is, but if you feel like it’s important to embed all of that context in the exponent operator... give it a try :) (And whether “2” is integer, real, rational, complex, etc)
        marcus_holmes 6y ago
        Yeah, but operator overloading doesn't say any of that. You have no idea what the "^" operator does, depending on the operands
      - FridgeSeal 6y ago
        Ehhh, it would seem that way, but the compactness of the syntax functions to get out of the way and help you understand the overall structure. Having longer function names ends up getting in your way more often than not in my experience.
dragonwriter 6y ago
> I never understand why operator overloading is said to make things more readable. Because, used properly, it does. > If the meaning of an operator can change wildly with the operands then that's just confusing Yes, irresponsible use of operator overloading makes things confusing. Overloading enables preserving existing semantics with new types that have similar semantic roles, it also enables natural, concise, domain specific notation which may sometimes have different semantics than the standard use (while wild, unpredictable semantic swings hurt readability, humans are naturally quite good at incorporating context into interpretation of symbols/language, and avoiding context sensitivity for naive simplicity does not aid readability.) Verbosity can be quite bad for the ability to quickly grasp the meaning of things. > People seem to confuse "less typing" with "simpler Conciseness (not mere terseness, but clarity and terseness together) greatly aid readability. Verbosity is not zero-cost.
- marcus_holmes 6y ago
  > Conciseness (not mere terseness, but clarity and terseness together) greatly aid readability. Verbosity is not zero-cost. I've been coding for 40-ish years. I've never found this to be true. Simple expressions are (in my experience) more readable. I understand it like this: to understand a complex expression you have to unpack it in your head to a simpler version in order to grok it. This is an operation you don't need to do if the expression is in the simpler, more verbose, version in the first place. This is a known thing in writing, btw - complex sentences are harder to read. If you want your audience to understand you, write more, simpler, sentences.
  - dragonwriter 6y ago
    > I've been coding for 40-ish years. Good for you, I've only been coding for 38 years. > Simple expressions are (in my experience) more readable. Simple is not the inverse of concise; there may be times when simpler expressions are more verbose, but that's not even approximately generally the case. “x²+1” and “x*2+1” and “add(pow(2,x),1)” and “x raised to the second power plus one” are equally simple (or, at least, the later ones are not more simple), but they are progressively less concise. (It's true that expanding the space of concise expressions may require more complex notation, and when the notation is unfamiliar, that creates a learning curve for learning the notation, but there's a reason people familiar with domains develop notations that support more concise expressions. > I understand it like this: to understand a complex expression you have to unpack it in your head to a simpler version in order to grok it. That's true of complexity of expressions, but again that's not the issue here. And concise notation expands the kind of expressions that can be grokked by pattern recognition rather than unpacking.
yiyus 6y ago
> how is "X[y==1,0]" more readable in this case than something like "filterElements(arrayToFilter, arrayOfBools)"? Just the same way that a[i] *= b[j] is more readable than a.IndexElement(firstIndex).MultiplyByFloat(b.IndexElement(secondIndex))
- marcus_holmes 6y ago
  yeah, sorry, but I didn't understand the first one at all, and totally understood the second one. Your definition of "readable" and mine differ ;)
  - renox 6y ago
    Bah, it's the same as Maths: notations 'compress' the formulas but at the cost of having to learn these notations..
    - marcus_holmes 6y ago
      yes, this. Completely. Is that more readable or less?
      - renox 6y ago
        For who? Beginners or experts?
        FridgeSeal 6y ago
        Experts. Optimising your whole notation for beginners is pre-emptively putting up a skill ceiling. Beginners stop being beginners (at which point they’ll outgrow the beginner oriented syntax) but experts will remain experts. Instead, optimise for teaching/learning the skills better rather than capping everyone’s skills. The presence of a learning curve is not an inherently bad thing. Edit: re-reading your previous comments, I think you and I are in furious agreement haha
  - yiyus 6y ago
AlexCoventry 6y ago
It's not so much a matter of reduced typing as that if you're invoking an operation many times, developing a concise notation for it can cut down on the noise it creates for a reader. It should be used very sparingly and heavily documented, though, for exactly the reason you outline. It really comes down to who you're writing the code for. For something like numpy, whose users will mostly be familiar with matrix notations, operator overloading enables a huge improvement.
sampo 6y ago
> I never understand why operator overloading is said to make things more readable. Ocaml doesn't overload even the arithmetic operators, so you write for integers 1 + t * A and for floating point 1 +. t *. A and for matrices you would make something like scal_mat_add(1, scal_mat_mul(t, A)) Do you really prefer these three, over writing 1 + t * A for all cases?

grayclhn 6y ago

Long expressions with matrix operations is a pretty standard example. When people talk about operator overloading in data science, they usually mean “standard operations on various arrays of numbers,” which are defined in common libraries or the programming language. Not “I need to define my own ad hoc equalities.”

marcus_holmes 6y ago
yeah, I get this. If there are standard definitions of operations that everyone understands, that's fine. But I always think that maybe we should be using new operators for this, instead of overloading existing ones that have other, different, meanings in different contexts.
- grayclhn 6y ago
  In a data science context, the key operations are math, so overloading makes a lot of sense and is massively helpful in implementing algorithms and equations. I go back and forth on the wisdom of some of the other common uses — filtering, etc. In addition to the problems that have been mentioned, there are often hidden and infrequent but painful performance issues.
  - marcus_holmes 6y ago
    I often think that maths could use the same slap around the chops. Less arcane operators and symbols, more explicit function names please!
    - grayclhn 6y ago
      I consider it kind of important that the notation for expressions like “A²” doesn’t depend on whether A is an integer, real number, complex number, matrix, random variable, etc., (even if the results do) or what the specific domain is, but if you feel like it’s important to embed all of that context in the exponent operator... give it a try :) (And whether “2” is integer, real, rational, complex, etc)
      - marcus_holmes 6y ago
        Yeah, but operator overloading doesn't say any of that. You have no idea what the "^" operator does, depending on the operands
    - FridgeSeal 6y ago
      Ehhh, it would seem that way, but the compactness of the syntax functions to get out of the way and help you understand the overall structure. Having longer function names ends up getting in your way more often than not in my experience.

dragonwriter 6y ago

> I never understand why operator overloading is said to make things more readable. Because, used properly, it does. > If the meaning of an operator can change wildly with the operands then that's just confusing Yes, irresponsible use of operator overloading makes things confusing. Overloading enables preserving existing semantics with new types that have similar semantic roles, it also enables natural, concise, domain specific notation which may sometimes have different semantics than the standard use (while wild, unpredictable semantic swings hurt readability, humans are naturally quite good at incorporating context into interpretation of symbols/language, and avoiding context sensitivity for naive simplicity does not aid readability.) Verbosity can be quite bad for the ability to quickly grasp the meaning of things. > People seem to confuse "less typing" with "simpler Conciseness (not mere terseness, but clarity and terseness together) greatly aid readability. Verbosity is not zero-cost.

marcus_holmes 6y ago
> Conciseness (not mere terseness, but clarity and terseness together) greatly aid readability. Verbosity is not zero-cost. I've been coding for 40-ish years. I've never found this to be true. Simple expressions are (in my experience) more readable. I understand it like this: to understand a complex expression you have to unpack it in your head to a simpler version in order to grok it. This is an operation you don't need to do if the expression is in the simpler, more verbose, version in the first place. This is a known thing in writing, btw - complex sentences are harder to read. If you want your audience to understand you, write more, simpler, sentences.
- dragonwriter 6y ago
  > I've been coding for 40-ish years. Good for you, I've only been coding for 38 years. > Simple expressions are (in my experience) more readable. Simple is not the inverse of concise; there may be times when simpler expressions are more verbose, but that's not even approximately generally the case. “x²+1” and “x*2+1” and “add(pow(2,x),1)” and “x raised to the second power plus one” are equally simple (or, at least, the later ones are not more simple), but they are progressively less concise. (It's true that expanding the space of concise expressions may require more complex notation, and when the notation is unfamiliar, that creates a learning curve for learning the notation, but there's a reason people familiar with domains develop notations that support more concise expressions. > I understand it like this: to understand a complex expression you have to unpack it in your head to a simpler version in order to grok it. That's true of complexity of expressions, but again that's not the issue here. And concise notation expands the kind of expressions that can be grokked by pattern recognition rather than unpacking.

yiyus 6y ago

> how is "X[y==1,0]" more readable in this case than something like "filterElements(arrayToFilter, arrayOfBools)"? Just the same way that a[i] *= b[j] is more readable than a.IndexElement(firstIndex).MultiplyByFloat(b.IndexElement(secondIndex))

marcus_holmes 6y ago
yeah, sorry, but I didn't understand the first one at all, and totally understood the second one. Your definition of "readable" and mine differ ;)
- renox 6y ago
  Bah, it's the same as Maths: notations 'compress' the formulas but at the cost of having to learn these notations..
  - marcus_holmes 6y ago
    yes, this. Completely. Is that more readable or less?
    - renox 6y ago
      For who? Beginners or experts?
      - FridgeSeal 6y ago
        Experts. Optimising your whole notation for beginners is pre-emptively putting up a skill ceiling. Beginners stop being beginners (at which point they’ll outgrow the beginner oriented syntax) but experts will remain experts. Instead, optimise for teaching/learning the skills better rather than capping everyone’s skills. The presence of a learning curve is not an inherently bad thing. Edit: re-reading your previous comments, I think you and I are in furious agreement haha
- yiyus 6y ago

AlexCoventry 6y ago

It's not so much a matter of reduced typing as that if you're invoking an operation many times, developing a concise notation for it can cut down on the noise it creates for a reader. It should be used very sparingly and heavily documented, though, for exactly the reason you outline. It really comes down to who you're writing the code for. For something like numpy, whose users will mostly be familiar with matrix notations, operator overloading enables a huge improvement.

sampo 6y ago

> I never understand why operator overloading is said to make things more readable. Ocaml doesn't overload even the arithmetic operators, so you write for integers 1 + t * A and for floating point 1 +. t *. A and for matrices you would make something like scal_mat_add(1, scal_mat_mul(t, A)) Do you really prefer these three, over writing 1 + t * A for all cases?