3 ms·

As someone who works on another language that is relatively reluctant to add language features (Java) we regularly face such dilemmas. A user shows up with a pr

by pron 3y ago

As someone who works on another language that is relatively reluctant to add language features (Java) we regularly face such dilemmas. A user shows up with a problem that could be helped by the language. The problem is real and a language feature would work, but there are many such problems, and adding features to solve all of them will make the language much bigger, overall causing greater harm (even those who don't themselves use the feature need to learn it to be able to read code). What we try to ascertain is how big of a problem it is, how many programs or lines of code it affects, and is there possibly a single feature that could solve multiple problems at once. So I would ask you this: what portion of your program suffers from a lack of user-defined infix operators and how big of a problem is it overall? Even if it turns out that the problem is worth fixing in the language, it often makes sense to wait some years and then prioritise the various problems that have been reported. Zig's simplicity and its no-overload (not just operator overloads!) single-dispatch is among its greatest features, and meant to be one of its greatest draws.

markisus 3y ago
In robotics, numerical linear algebra expressions comprise a large part of the code base. If not by line count, then definitely by the amount of time spent writing, reading, and debugging such code. This makes Zig unusable for these applications, at least not without additional tooling. You can get a feel for how unergonomic this is by avoiding the use of all arithmetic operators in your code and instead forcing yourself to use user defined plus(a,b), minus(a,b), assign(a,b), etc, or programming directly with the C blas api.
- hellcow 3y ago
  Using plus(a,b) for complex types sounds fine to me… I have to imagine if I were working with a huge file of these for a while it would start to feel normal, just like every language has a different syntax but you eventually feel comfortable using.
  - KerrAvon 3y ago
    Are you sure you would find this more ergonomically pleasing: assign(x, plus(a, plus(b, plus(c, b)))) When you could have: x = a + b + c + d; Or: (let x (+ a b c d)) ?
    - chrsig 3y ago
      is assign(x, plus(a, b, c, d)) not an option?
- erichocean 3y ago
  > You can get a feel for how unergonomic this is by avoiding the use of all arithmetic operators in your code and instead forcing yourself to use user defined plus(a,b), minus(a,b), assign(a,b), etc, or programming directly with the C blas api. You've dramatically overstated your case, since that's true of every Lisp-like language. Lisp is a perfectly suitable language for developing mathematics in, see SICM [0] for details. If you want to see SICM in action, the Emmy Computer Algebra System [1] [2] [3] [4] is a Clojure project that ported SICM to both Clojure and Clerk notebooks (like Jupyter notebooks, but better for programmers). [0] https://mitpress.mit.edu/9780262028967/structure-and-interpretation-of-classical-mechanics/ https://mitpress.mit.edu/9780262028967/structure-and-interpr... [1] Emmy project: https://emmy.mentat.org/ https://emmy.mentat.org/ [2] Emmy source code: https://github.com/mentat-collective/emmy https://github.com/mentat-collective/emmy [3] Emmy implementation talk (2017): "Physics in Clojure" https://www.youtube.com/watch?v=7PoajCqNKpg https://www.youtube.com/watch?v=7PoajCqNKpg [4] Emmy notebooks talk (2023): "Emmy: Moldable Physics and Lispy Microworlds": https://www.youtube.com/watch?v=B9kqD8vBuwU https://www.youtube.com/watch?v=B9kqD8vBuwU
  - KerrAvon 3y ago
    Why do you think this is true of Lisps? Emmy would not seem to be a good example because it actually does overload arithmetic operators to support extended data structures. Look at, for example: https://cljdoc.org/d/org.mentat/emmy/0.30.0/doc/data-types/matrix https://cljdoc.org/d/org.mentat/emmy/0.30.0/doc/data-types/m...
    - erichocean 3y ago
      > forcing yourself to use user defined plus(a,b), minus(a,b), assign(a,b) This is the complaint I was responding to. Here is that code in Clojure (a Lisp): // What the GP claims is bad for doing math: plus(a,b) minus(a,b) assign(a,b) // <= I have no idea what this does, or has to do with math. // Let's actually use the original math operators, but with function notation: +(a,b) -(a,b) // And here's the Clojure/Lisp syntax for the same: (+ a b) (- a b) Lisp doesn't have "operators", so it doesn't have "operator overloading." What it does have is multi-dispatch, so yeah, the implementation of `+` can depend on the (dynamic) types of both `a` and `b`. That's a good thing, it means that the `+` and `-` tokens aren't hard-coded to whatever the language designer decided they should be in year 0, with whatever precedence and evaluation rules they picked at the time. The point I'm making is that you absolutely DO NOT need to have special-cased, infix math operators to "do math" in a reasonable, readable way. SICP is proof, and Emmy is a breeze to work with. And it turns out, there are a lot of advantages in NOT hard-coding your infix operators and precedence rules into the syntax of the language.
- anonymoushn 3y ago
  You can use = for structs at least :)
QQ00 3y ago
>and adding features to solve all of them will make the language much bigger, overall causing greater harm (even those who don't themselves use the feature need to learn it to be able to read code). I agree that adding too many features can make a language too large and bloated. However, I disagree that this is always the case. For example, adding features that make it easier to code math is not necessarily a bad thing. In fact, it is a good thing, as it can make programming more accessible to a wider range of people. Additionally, math is often used in fields that require high speed, such as computer graphics and game development, Computer vision, Robotics, Machine learning, Natural language processing (NLP), Mathematical modeling, all kinds of scientific computing (Computational physics, Computational chemistry, Computational biology...) As a result, low-level programming languages are often used to implement the core code in these fields. As you see, Math is essential for many fields.

by pron 3y ago

markisus 3y ago

In robotics, numerical linear algebra expressions comprise a large part of the code base. If not by line count, then definitely by the amount of time spent writing, reading, and debugging such code. This makes Zig unusable for these applications, at least not without additional tooling. You can get a feel for how unergonomic this is by avoiding the use of all arithmetic operators in your code and instead forcing yourself to use user defined plus(a,b), minus(a,b), assign(a,b), etc, or programming directly with the C blas api.

hellcow 3y ago
Using plus(a,b) for complex types sounds fine to me… I have to imagine if I were working with a huge file of these for a while it would start to feel normal, just like every language has a different syntax but you eventually feel comfortable using.
- KerrAvon 3y ago
  Are you sure you would find this more ergonomically pleasing: assign(x, plus(a, plus(b, plus(c, b)))) When you could have: x = a + b + c + d; Or: (let x (+ a b c d)) ?
  - chrsig 3y ago
    is assign(x, plus(a, b, c, d)) not an option?
erichocean 3y ago
> You can get a feel for how unergonomic this is by avoiding the use of all arithmetic operators in your code and instead forcing yourself to use user defined plus(a,b), minus(a,b), assign(a,b), etc, or programming directly with the C blas api. You've dramatically overstated your case, since that's true of every Lisp-like language. Lisp is a perfectly suitable language for developing mathematics in, see SICM [0] for details. If you want to see SICM in action, the Emmy Computer Algebra System [1] [2] [3] [4] is a Clojure project that ported SICM to both Clojure and Clerk notebooks (like Jupyter notebooks, but better for programmers). [0] https://mitpress.mit.edu/9780262028967/structure-and-interpretation-of-classical-mechanics/ https://mitpress.mit.edu/9780262028967/structure-and-interpr... [1] Emmy project: https://emmy.mentat.org/ https://emmy.mentat.org/ [2] Emmy source code: https://github.com/mentat-collective/emmy https://github.com/mentat-collective/emmy [3] Emmy implementation talk (2017): "Physics in Clojure" https://www.youtube.com/watch?v=7PoajCqNKpg https://www.youtube.com/watch?v=7PoajCqNKpg [4] Emmy notebooks talk (2023): "Emmy: Moldable Physics and Lispy Microworlds": https://www.youtube.com/watch?v=B9kqD8vBuwU https://www.youtube.com/watch?v=B9kqD8vBuwU
- KerrAvon 3y ago
  Why do you think this is true of Lisps? Emmy would not seem to be a good example because it actually does overload arithmetic operators to support extended data structures. Look at, for example: https://cljdoc.org/d/org.mentat/emmy/0.30.0/doc/data-types/matrix https://cljdoc.org/d/org.mentat/emmy/0.30.0/doc/data-types/m...
  - erichocean 3y ago
    > forcing yourself to use user defined plus(a,b), minus(a,b), assign(a,b) This is the complaint I was responding to. Here is that code in Clojure (a Lisp): // What the GP claims is bad for doing math: plus(a,b) minus(a,b) assign(a,b) // <= I have no idea what this does, or has to do with math. // Let's actually use the original math operators, but with function notation: +(a,b) -(a,b) // And here's the Clojure/Lisp syntax for the same: (+ a b) (- a b) Lisp doesn't have "operators", so it doesn't have "operator overloading." What it does have is multi-dispatch, so yeah, the implementation of `+` can depend on the (dynamic) types of both `a` and `b`. That's a good thing, it means that the `+` and `-` tokens aren't hard-coded to whatever the language designer decided they should be in year 0, with whatever precedence and evaluation rules they picked at the time. The point I'm making is that you absolutely DO NOT need to have special-cased, infix math operators to "do math" in a reasonable, readable way. SICP is proof, and Emmy is a breeze to work with. And it turns out, there are a lot of advantages in NOT hard-coding your infix operators and precedence rules into the syntax of the language.
anonymoushn 3y ago
You can use = for structs at least :)

QQ00 3y ago

>and adding features to solve all of them will make the language much bigger, overall causing greater harm (even those who don't themselves use the feature need to learn it to be able to read code). I agree that adding too many features can make a language too large and bloated. However, I disagree that this is always the case. For example, adding features that make it easier to code math is not necessarily a bad thing. In fact, it is a good thing, as it can make programming more accessible to a wider range of people. Additionally, math is often used in fields that require high speed, such as computer graphics and game development, Computer vision, Robotics, Machine learning, Natural language processing (NLP), Mathematical modeling, all kinds of scientific computing (Computational physics, Computational chemistry, Computational biology...) As a result, low-level programming languages are often used to implement the core code in these fields. As you see, Math is essential for many fields.