7 ms·

"In the beginning the [operator overloading] was created. This has made a lot of people very angry and been widely regarded as a bad move." But in all seriousn

"In the beginning the [operator overloading] was created. This has made a lot of people very angry and been widely regarded as a bad move." But in all seriousness that's pretty much antithetical to zig's goals regarding explicitness.

Kukumber 4y ago
if we can do 1 + 1, we should be able to do vec2 + vec2, same with mat4 * mat4 Odin proved it that it can be made efficiently while keeping sanity
- stephc_int13 4y ago
  The thing about operator overloading is that it was abused during one of the worst era of C++. And vec2 + vec2 can probably be unambiguously translated to assembly code while mat4 * mat4 is an other story. In most cases it should be a function call, and not a trivial one, with SIMD it can be relatively fast but still several orders of magnitude slower than 1 + 1. (we're talking about more than 500 scalar-equivalent operations) And unfortunately, from my experience, if you let people (especially new coders) use this kind of powerful syntactic sugar they tend to ignore the performance characteristics because it look so simple and basic, like if the CPU had a special instruction to multiply two 4x4 matrices. I prefer when the function call is explicit, it is a bit more cumbersome to write, but there is less hidden complexity.
  - Kukumber 4y ago
    > I prefer when the function call is explicit, it is a bit more cumbersome to write, but there is less hidden complexity. you hide and obfuscate basic operations with functions, that's worse, specially when you have to chain arithmetic operations, with functions it becomes ugly and unreadable
    - stephc_int13 4y ago
      Show me an example and I am pretty sure that I can rewrite it in a way that is neither ugly nor unreadable.
    - stephc_int13 4y ago
      Matrix multiplication or even worse, matrix inversion, is NOT a basic operation. This is exactly the point.
      - littlestymaar 4y ago
        Integer division isn't a simple one either though… Matrix multiplication are “basic operations” in the sense that you use them as the basic block of your algorithms, and in code using such blocks you really appreciate having a simple operator for those instead of littering your formula with functions calls (which is basically writing your formulas in Polish notation, not the most legible way to write formulas …)
        dolmen 4y ago
        Matrix multiplication is a niche in the programming world.
        littlestymaar 4y ago
        The programming world is made of niches. That's why arithmetic operator overloading is nice, the language doesn't need to know which niche I'm in to satisfy my needs.
      - cycomanic 4y ago
        I somewhat agree with you, I argue that mat*mat should be an element wise operation and use a different operator for matrix operations (like numpy does it).
      - kllrnohj 4y ago
        > Matrix multiplication or even worse, matrix inversion, is NOT a basic operation. Neither is dividing floats, especially not on a softfloat & softdiv architecture. And yet, Zig is perfectly OK with you using division between 2 floats. Why does it get to insert expensive function calls behind operators but I can't? Zig also lets you do remainder division for floats, which is also not a "basic operation." It's slower even then taking the sqrt of a float! Zig then also has specialized operators like saturating addition, which also isn't a "basic operation" And then Zig also has `*` for array multiplication and `++` for array concatenation. Those are compile-time only, but still deviates from "basic operations only" territory surely. And also Zig overloads `||` to allow for the merging of enums (sorry, "error sets"), rather than only being a boolean OR.
- naikrovek 4y ago
  > if we can do 1 + 1, we should be able to do vec2 + vec2, same with mat4 * mat4 why? operator overloading doesn't help you solve any problems. you can have the readability with methods which are named appropriately. operator overloading seems so powerful and useful until you realize one day that it only changes the appearance of things, and makes no difference whatsoever to anything you are actually doing.
  - cycomanic 4y ago
    But we are using operator overloading already, + does work for the basic numeric types doesn't it? So why should the line be drawn at float or double (zig didn't have a complex type last I looked), why not vec?
  - Kukumber 4y ago
    i'm not asking for operator _overloading_, i am asking for having operators for my math types
    - renox 4y ago
      Good point, you could have + * / restricted to basic types, but have #* #+ #mod_add as (overloadable) operators.
  - adgjlsfhk1 4y ago
    readability is important. specifically, operator overloading is great because it makes code look more like math. when translating from math to code, this is highly useful.
  - WalterBright 4y ago
    Here's a sweet example of proper use of operator overloading: https://dlang.org/phobos/std_checkedint.html https://dlang.org/phobos/std_checkedint.html where operator overloading is used to create variations on integer types, like specifying the behavior when overflow happens. Besides, `a + b / (c * d)` is far more readable than `add(a, div(b, mul(c, d)));
WalterBright 4y ago
D initially wasn't going to do operator overloading, mainly because C++ iostreams was a disaster (in my not-so-humble opinion) as well as the awfulness of overloading operators to create a DSL. But I wound up being convinced that on balance it was a good thing. But I was able to inculcate a culture that operator overloading should be restricted to the creation of user arithmetic types. Not allowing the overloading of unary *, &, and dot also help discourage non-arithmetic overloading.
- 1980phipsi 4y ago
  What about something like R's custom infix operators? R has %*% for matrix multiplication (and a few other built-in ones), but you can define your own %op%. It lets users know that potentially "here be dragons".
  - WalterBright 4y ago
    That has come up a few times. Frankly, %*% looks even worse. Using Unicode sounds like a good idea, until one discovers that the source code is not parseable without semantic analysis.
- dfawcus 4y ago
  Well, there is always the limited form of arithmetic overloading which Ken Thompson added to his compiler: https://marc.info/?l=9fans&m=111559034637840&w=2 https://marc.info/?l=9fans&m=111559034637840&w=2
- int_19h 4y ago
  C# has had extensive operator overloading from day 1, and the only instance of (mild) abuse that I can think of is the use of implicit conversions from strings in XLINQ. It really is mostly down to culture, I think.
kllrnohj 4y ago
Then no operators should exist at all. After all, adding 2 ints and adding 2 floats are drastically different runtime characteristics - performance and errors are completely different! Anarchy! Chaos! And let's not forget about all those architectures where the division operator is, gasp, a function call! Also function overloads should never be allowed, either. After all, that's not explicit and the only thing that ever matters is being obsessively explicit for the sake of being explicit. How can I possibly tell what `min(a, b)` is going to do if function overloads or templates or macros exist?!? UNREADABLE! I think at this point it's pretty well established that operator overloading is a net-good, and languages that don't have it end up with far more bugs than languages that do. Or they come up with arbitrary nonsense rules on why some types are allowed to have it but not your types you dirty filthy casual. Looking at you, Java, where the Integer class is allowed to overload operators but BigInteger isn't. Which, then again, is something Scala and Kotlin immediately completely reversed.
properparity 4y ago
How is w=add(u, v) more explicit than w=u+v? Because operators "should not be function calls"? That would make zig unusable on soft float/soft div architectures, or would have to get rid of / for division and operators for floats. But I would also assume add() is inlined and not be a function call in a sane language/compiler, so the explicitness even falls apart from the start.
deleted 4y ago
[deleted]

Kukumber 4y ago

if we can do 1 + 1, we should be able to do vec2 + vec2, same with mat4 * mat4 Odin proved it that it can be made efficiently while keeping sanity

stephc_int13 4y ago
The thing about operator overloading is that it was abused during one of the worst era of C++. And vec2 + vec2 can probably be unambiguously translated to assembly code while mat4 * mat4 is an other story. In most cases it should be a function call, and not a trivial one, with SIMD it can be relatively fast but still several orders of magnitude slower than 1 + 1. (we're talking about more than 500 scalar-equivalent operations) And unfortunately, from my experience, if you let people (especially new coders) use this kind of powerful syntactic sugar they tend to ignore the performance characteristics because it look so simple and basic, like if the CPU had a special instruction to multiply two 4x4 matrices. I prefer when the function call is explicit, it is a bit more cumbersome to write, but there is less hidden complexity.
- Kukumber 4y ago
  > I prefer when the function call is explicit, it is a bit more cumbersome to write, but there is less hidden complexity. you hide and obfuscate basic operations with functions, that's worse, specially when you have to chain arithmetic operations, with functions it becomes ugly and unreadable
  - stephc_int13 4y ago
    Show me an example and I am pretty sure that I can rewrite it in a way that is neither ugly nor unreadable.
  - stephc_int13 4y ago
    Matrix multiplication or even worse, matrix inversion, is NOT a basic operation. This is exactly the point.
    - littlestymaar 4y ago
      Integer division isn't a simple one either though… Matrix multiplication are “basic operations” in the sense that you use them as the basic block of your algorithms, and in code using such blocks you really appreciate having a simple operator for those instead of littering your formula with functions calls (which is basically writing your formulas in Polish notation, not the most legible way to write formulas …)
      - dolmen 4y ago
        Matrix multiplication is a niche in the programming world.
        littlestymaar 4y ago
        The programming world is made of niches. That's why arithmetic operator overloading is nice, the language doesn't need to know which niche I'm in to satisfy my needs.
    - cycomanic 4y ago
      I somewhat agree with you, I argue that mat*mat should be an element wise operation and use a different operator for matrix operations (like numpy does it).
    - kllrnohj 4y ago
      > Matrix multiplication or even worse, matrix inversion, is NOT a basic operation. Neither is dividing floats, especially not on a softfloat & softdiv architecture. And yet, Zig is perfectly OK with you using division between 2 floats. Why does it get to insert expensive function calls behind operators but I can't? Zig also lets you do remainder division for floats, which is also not a "basic operation." It's slower even then taking the sqrt of a float! Zig then also has specialized operators like saturating addition, which also isn't a "basic operation" And then Zig also has `*` for array multiplication and `++` for array concatenation. Those are compile-time only, but still deviates from "basic operations only" territory surely. And also Zig overloads `||` to allow for the merging of enums (sorry, "error sets"), rather than only being a boolean OR.
naikrovek 4y ago
> if we can do 1 + 1, we should be able to do vec2 + vec2, same with mat4 * mat4 why? operator overloading doesn't help you solve any problems. you can have the readability with methods which are named appropriately. operator overloading seems so powerful and useful until you realize one day that it only changes the appearance of things, and makes no difference whatsoever to anything you are actually doing.
- cycomanic 4y ago
  But we are using operator overloading already, + does work for the basic numeric types doesn't it? So why should the line be drawn at float or double (zig didn't have a complex type last I looked), why not vec?
- Kukumber 4y ago
  i'm not asking for operator _overloading_, i am asking for having operators for my math types
  - renox 4y ago
    Good point, you could have + * / restricted to basic types, but have #* #+ #mod_add as (overloadable) operators.
- adgjlsfhk1 4y ago
  readability is important. specifically, operator overloading is great because it makes code look more like math. when translating from math to code, this is highly useful.
- WalterBright 4y ago
  Here's a sweet example of proper use of operator overloading: https://dlang.org/phobos/std_checkedint.html https://dlang.org/phobos/std_checkedint.html where operator overloading is used to create variations on integer types, like specifying the behavior when overflow happens. Besides, `a + b / (c * d)` is far more readable than `add(a, div(b, mul(c, d)));

WalterBright 4y ago

D initially wasn't going to do operator overloading, mainly because C++ iostreams was a disaster (in my not-so-humble opinion) as well as the awfulness of overloading operators to create a DSL. But I wound up being convinced that on balance it was a good thing. But I was able to inculcate a culture that operator overloading should be restricted to the creation of user arithmetic types. Not allowing the overloading of unary *, &, and dot also help discourage non-arithmetic overloading.

1980phipsi 4y ago
What about something like R's custom infix operators? R has %*% for matrix multiplication (and a few other built-in ones), but you can define your own %op%. It lets users know that potentially "here be dragons".
- WalterBright 4y ago
  That has come up a few times. Frankly, %*% looks even worse. Using Unicode sounds like a good idea, until one discovers that the source code is not parseable without semantic analysis.
dfawcus 4y ago
Well, there is always the limited form of arithmetic overloading which Ken Thompson added to his compiler: https://marc.info/?l=9fans&m=111559034637840&w=2 https://marc.info/?l=9fans&m=111559034637840&w=2
int_19h 4y ago
C# has had extensive operator overloading from day 1, and the only instance of (mild) abuse that I can think of is the use of implicit conversions from strings in XLINQ. It really is mostly down to culture, I think.

kllrnohj 4y ago

Then no operators should exist at all. After all, adding 2 ints and adding 2 floats are drastically different runtime characteristics - performance and errors are completely different! Anarchy! Chaos! And let's not forget about all those architectures where the division operator is, gasp, a function call! Also function overloads should never be allowed, either. After all, that's not explicit and the only thing that ever matters is being obsessively explicit for the sake of being explicit. How can I possibly tell what `min(a, b)` is going to do if function overloads or templates or macros exist?!? UNREADABLE! I think at this point it's pretty well established that operator overloading is a net-good, and languages that don't have it end up with far more bugs than languages that do. Or they come up with arbitrary nonsense rules on why some types are allowed to have it but not your types you dirty filthy casual. Looking at you, Java, where the Integer class is allowed to overload operators but BigInteger isn't. Which, then again, is something Scala and Kotlin immediately completely reversed.

properparity 4y ago

How is w=add(u, v) more explicit than w=u+v? Because operators "should not be function calls"? That would make zig unusable on soft float/soft div architectures, or would have to get rid of / for division and operators for floats. But I would also assume add() is inlined and not be a function call in a sane language/compiler, so the explicitness even falls apart from the start.

deleted 4y ago

[deleted]