7 ms·

Zig indeed is pretty nice, i just wish it had some more sweet to it - my math type with + - * / overloads - simpler way to fill an array, i can never remember

Zig indeed is pretty nice, i just wish it had some more sweet to it - my math type with + - * / overloads - simpler way to fill an array, i can never remember the syntax, it doesn't feel natural `[_]u8{0} * 10;` - smarter type system, i am tired of casting everything twice A good language is not a language set in stone, a good language is a language that doesn't make me feel like i have to suffer because they made a stupid decision years ago and they refuse to make it better

wyldfire 4y ago
"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.
  - 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]
sharikous 4y ago
> A good language is not a language set in stone, a good language is a language that doesn't make me feel like i have to suffer because they made a stupid decision years ago and they refuse to make it better It depends. Low level coding the like of which zig is tailored to tends to involve a lot "write and forget about it" infrastructure stuff. At least that's my use case. It sucks to painfully go over that cryptographic hash, that codec or that compressing algorithm you wrote 15 years ago and still works flawlessly because it wouldn't compile with the modern version of the language. I think zig is very nice but I wouldn't use it even for my personal projects because it's still unstable (and from my POV it will remain that way for at least 5-10 years). C is terrible but it's not sufficiently terrible that I would use a language that is orders of magnitudes less popular and still in its infancy. Too risky.
- Tozen 4y ago
  Speaking truth and giving out reality checks.
ptato 4y ago
I agree that array initialization syntax is weird a.f., but the other two points are very deliberate. I feel like you're implying they're legacy cruft.
nulltype 4y ago
For operator overloading you can do something like this: https://github.com/christopher-hesse/tenet#interesting-features https://github.com/christopher-hesse/tenet#interesting-featu... You have to specify the names more times but you can also do any syntax you want.

wyldfire 4y ago

"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.
- 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]

sharikous 4y ago

> A good language is not a language set in stone, a good language is a language that doesn't make me feel like i have to suffer because they made a stupid decision years ago and they refuse to make it better It depends. Low level coding the like of which zig is tailored to tends to involve a lot "write and forget about it" infrastructure stuff. At least that's my use case. It sucks to painfully go over that cryptographic hash, that codec or that compressing algorithm you wrote 15 years ago and still works flawlessly because it wouldn't compile with the modern version of the language. I think zig is very nice but I wouldn't use it even for my personal projects because it's still unstable (and from my POV it will remain that way for at least 5-10 years). C is terrible but it's not sufficiently terrible that I would use a language that is orders of magnitudes less popular and still in its infancy. Too risky.

Tozen 4y ago
Speaking truth and giving out reality checks.

ptato 4y ago

I agree that array initialization syntax is weird a.f., but the other two points are very deliberate. I feel like you're implying they're legacy cruft.

nulltype 4y ago

For operator overloading you can do something like this: https://github.com/christopher-hesse/tenet#interesting-features https://github.com/christopher-hesse/tenet#interesting-featu... You have to specify the names more times but you can also do any syntax you want.