Comment by erichocean | Hacker News Reader

Comment by erichocean | Hacker News Reader

Parent Full thread

> 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-interpr...

[1] Emmy project: https://emmy.mentat.org/

[2] Emmy source code: https://github.com/mentat-collective/emmy

[3] Emmy implementation talk (2017): "Physics in Clojure" 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

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/m...

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

By assign(a,b) I meant to denote the copying of the matrix b into the matrix a. The ability to use arithmetic symbols `+` and `-` as function identifiers definitely aids in readability but I don't think this is possible in Zig.

I am not familiar with Emmy but I'm guessing that the usual work flow will involve an interactive shell with many calls to `render` to display expressions in infix notation so that you can better check if the expression you typed is actually what you meant to type.

The infix notation, although arbitrary and not as logically simple as other notations, is almost universal in the math-speaking world. Most mathematicians and engineers have have years of experience staring at infix expressions on blackboards, and disseminate new knowledge using this notation, and do new calculations in this notation.

In reading your reply, I think that maybe some tooling that could auto-insert corresponding infix-like comments above an AST-like syntax could be a solution for writing such code in Zig.

Reply on news.ycombinator.com