Hacker News Reader

Comment by epolanski | Hacker News Reader

The amount of times I've been sad that multiply or sum are longer than + or * is limited to long formulas and even then it's a non issue.

Also, functions can be used as callbacks, and offer overloads to handle partial applications with ease, pipe(2, sum(3), multiply(2)), e.g.

View on HN

I don't think your experience is particularly universal, it vastly differs depending on what kind of programming you do. If you're doing games stuff or graphics or signal processing or any other number of subfields of programming that require a lot of math, operators are a god-send for readability.

This Zig change is the best of both worlds: avoid the ambiguity, but keep the readability.

I don't think character length of an expression is the issue. Reading chained operators is explicitly easier than reading nested functions by virtue of operators having infix notation and not explicitly requiring parantheses where they are not necessary to disambiguate order of operations. The prefix notation of functions moves the operation farther from the eye from operands and introduces the issue of parantheses-miscounting bugs. I'd hardly say the difference in readability of these is a non issue:

(a + b + c + d) * e

mult(add(a, add(b, add(c, d))), e)

Hence I said that operators are more readable for longer formulas.

mult(add(a, b, c, d), e)

At that point,

    (* (+ a b c d) e)

> (a + b + c + d) * e

   a
   |> add(b)
   |> add(c)
   |> add(d)
   |> mult(e)

> mult(add(a, add(b, add(c, d))), e)

    c
    |> add(d)
    |> add(b, _)
    |> add(a, _)
    |> mult(e)

What a lovely pipe operator you have there to chain the functions and contribute to code readability :)

There is also some irony that the function style makes the order of the different addition operations explicit - which in this case is not helpful, because the addition operation is associative. So the parentheses here are just noise.

(Well, almost. You might have weird floating point issues or other bugs, where the associativity does not apply anymore and knowing the evaluation order would be useful. But I think this would be rare situations)

There are plenty of languages, like e.g. Ruby, where operators are just sugar for functions or methods. Meaning they can still be partially applied, have their value taken, and/or passed as callbacks.

If your language doesn't allow you to do the same thing with operators as you can do with functions, that's a language design issue and has nothing to do with operators as a concept.

> The amount of times I've been sad that multiply or sum are longer than + or * is limited to long formulas and even then it's a non issue.

It depends on what things you work on. When I'm writing 'math-y' code (GPU shaders for renderng etc) then I want the expressions to look close to the reference paper and not artificially split them up into multiple lines of code with function calls instead of operators.

Operators can also support those things. Operators are just syntax sugar for functions, or at least they're capable of being such. If a language chooses not to support the full range of what functions can do for operators, that is a thing you can criticise the language for (and I do!), but it is not a reason to suggest operators should be disposed with in language design altogether.

Reply on news.ycombinator.com