Hacker News Reader

Comment by tptacek | Hacker News Reader

Could you go into more detail about why operator overloading enables generic functions in a way simple functions don't? I don't see it.

View on HN

Without operator overloading, it's hard to make generic numeric algorithms palatable.

Compare (fake Go-with-Swift-generics syntax):

    func Distance<N>(x N, y N) N where N Number {
        return x.Mul(x).Add(y.Mul(y)).Sqrt()
    }

Versus:

    func Distance<N>(x N, y N) N where N Number {
        return Sqrt(x * x + y * y)
    }

If your reaction is "well, Distance doesn't look too bad like that", I can replace it with matrix multiplication or point-inside-triangle testing. Not having overloading quickly fails to scale.

Wouldn't breaking it down into components instead of using a one liner be an appropriate response for readability's sake?

For the distance formula? That's about the simplest graphics routine in the world. If you can't readably write distance without temporaries, the language isn't really usable for (generic) graphics programming. Replace distance with bilerp or point-triangle intersection tests (as I did in a sibling comment) and you'll see what I mean.

(It's totally fine for a language to be not interested in that domain. But that doesn't mean operator overloading is bad. Overloaded operators are essential for some domains.)

That's true. We had to write our own (generic) GLM library in university. Definitely wouldn't want to be doing that in Go.

Actually your distance implementation is a good example of needless stuffing of expressions into a single function.

Many times you don't care for the (costly) square root, so a distance-squared function can be useful.

Multiplying x by itself ("squaring") can also be a useful function that is used a lot.

    (defun distance (x y) (sqrt (distance-squared x y)))
    (defun distance-squared (x y) (+ (square x) (square y)))
    (defun square (x) (* x x))

In the same way that we can decompose our code, we can also decompose the concept of "operator overloading": it gives you is the ability to use one-letter (1), fixed-arity and precedence-following (P), infix (I), operators for your own or someone else's operations (G).

In languages that support 1PI properties, you'd often overlook such decompositions because it's quick and easy to write sqrt(x * x + y * y). To read it, also, but then you find yourself doing more and more complex calculations in-line. Reading suffers. You may end up with something that's worse than the corresponding code in a language that encourages defining small functions instead. (Lisp, of course, lets you use any combination of these properties, but the latter style is the one normally used.)

Yes, this is a Go thread... but I'll leave it here anyway.

Of course, you frequently don't want operator overloading for matrix multiplication. Avoiding allocations is a big deal for speed, and so c.Mul(a,b) is often the right answer even with operator overloading.

How does allocation relate to operator overloading?

It gives you more explicit control over the storage being used for expression evaluation.

Can you give an example? I don't understand.

I'm not aware of a language that allows operator overloading for matrix operations, but denies you access to c.Mul(a,b) or the equivalent when you need it. I find operator overloading pretty crucial for prototyping this sort of algorithm even if I'm later going to refactor it for performance.

edit: rereading the earlier comments, this may be orthogonal to the GP's claim that operator overloading is crucial for generics. Ooops. :)

Because you would have to come up with a naming convention ahead of time.

And you're suggesting that nowhere in what used to be called the C++ Standard Template Library is there a place where they didn't have to come up with a naming convention for functions?

I think you may have the causality swapped here; I think <algorithm> looks the way it does because they limited themselves to things that could be easily expressed with operators --- for a long time, to the detriment of the language; see: STL associative containers, operator<, and the longstanding lack of a standard hash table.

How was <algorithm> preventing the introduction of a hash table? The hash function is a template parameter, predefined for standard types, no operator needed.

Josuttis claims that hash tables didn't make it in C++98 due to lack of time.

Reply on news.ycombinator.com