Why Operators Are Useful

That’s semantically not an “add”, it’s a “merge” or “update”

But, this argument defeats itself. At least, in practice.

If I look at how 'operator overloading' is used in practice, _rarely_ do you get commutativity, or even anticommutativity, associativity, or distributivity.

Take list addition, where operator overloading often shows up:

    someList += someElement

is shorthand for:

    someList.add(someElement)

add is not commutative; the elements used in the operation aren't even the same type.

The point being, the manipulation and simplification that is, according to GvR, much easier to spot if operators are used aren't even relevant here.

If we're talking about, say, introducing a class 'Complex', representing complex numbers, and wishing that the language is such that one can add the ability to use mathematical operators here, observing that it is both [A] common in the domain of complex numbers to use, say, the symbol `+` to indicate addition, and [B] these properties of operations such as commutativity apply to many mathematical operations one might want to perform on complex numbers, I'd agree: Yeah, the language kinda sucks if you can't write `Complex(a, b) + Complex(c, d)`.

But how often does that actually occur?

Separately, if you go down this route, the abstraction should be as complete as it can be. Therefore, this:

    `Complex(2, 3) + 5`

Should work, and should evaluate to `Complex(7, 3)`. But.. this:

    `5 + Complex(2, 3)`

should also work. Which requires either scala's `implicit` system or python's take on this, involving `__rplus__`. These operations introduce their own complications.

Thus, the debate on operator overloading boils down, as language feature debates usually do, as a cost v. benefits analysis. The costs are heavy: There is a lot of proof out there that even experienced coders just insist on abusing operator overloading (or, to be a bit less judgemental: That opinions are rather divided on how they ought to be used, given the amount of complaints about `cout Are the benefits worth it? Possibly.

But I don't think GvR's article takes the cost side seriously, and the benefits stated, at least in my experience, tend not to apply at all there where op overloading tends to end up.

It’s an operator, there are no optional arguments. Though it’s OK to also have a function like you propose.

We do have f(x, y) in mathematics notation, as well as notations like { a, b, c }, ( 1, 2 ). The inventor of vector and matrix notation finally had the brilliant idea of dropping the silly commas [ i j k ]. Think of how ugly matrices would look with commas.

Now in mathematics, there is no equivalent of a 200,000 line piece of software. The number of identifiers a mathematician works with in any given work is small, even if the work is large (many pages of derivation).

Mathematics notation is ambiguous and inconsistent. One letter names are preferred so that xy can denote the product of x * y. So much so that mathematicians reach for other scripts like Greek rather than make a multi-letter name. Then, inconsistently, we have things like sin(x).

Consider that xy(z + w) is likely interpreted as the product of x, y and z + w. It has the same syntax as ln(z + w), the natural logarithm of z + w, not the product of l and n.

Professionally printed mathematics resorts to the use of special fonts to visually resolve these things. This problem is so serious that everyone who is anyone in mathematics goes to the trouble of professional typesetting, even in minor papers.

In software, the program-defined functions form vast vocabularies. They cannot all be assigned to infix operators without creating mayhem. Many functions have 3 arguments. Seven argument functions are not uncommon. Those also cannot be infix.

In spite of what the author may say, real Python code is chock full of "import foo" and "foo.bar.baz(this.or.that(), other.thing())".

tbh, if you're writing a lot of equations like this in a program, the Lisp version should probably be something like

    (eqn x * (y + z) = x * z + y * z)

where you write and test an `eqn` macro that rewrites everything in the correct syntax.