Why operators are useful (2019) | Hacker News Reader

Why operators are useful (2019)

mail.python.org

122 pointsedward132 comments

Slightly orthogonal to the original point, but worth noting that operators can also increase confusion when they don't interact with each other in expected ways. For example, in Python, 'x += y' isn't equivalent to 'x = x + y' in all contexts. Example:

  >>> a_tuple = ([1, 2], [3, 4], [5, 6])
  >>> a_tuple[2] += ['foo', 'bar']
  TypeError: 'tuple' object does not support item assignment
  >>> a_tuple
  ([1, 2], [3, 4], [5, 6, 'foo', 'bar'])

  >>> a_tuple = ([1, 2], [3, 4], [5, 6])
  >>> a_tuple[2] = a_tuple[2] + ['foo', 'bar']
  TypeError: 'tuple' object does not support item assignment
  >>> a_tuple
  ([1, 2], [3, 4], [5, 6])

Edited to add, to understand what's happening here, check out the documentation on in place operators: https://docs.python.org/3/library/operator.html#in-place-ope...

I agree, I find it awkward when a programming language (like Java and JS) provide operators for their built in types, but if you want to use different types (say, complex numbers, numbers with different precision, ...) you have to use much less readable functions instead.

About the argument that operator overloading can be abused for unreadable code: so can functions, naming, or anything else.

I much prefer languages which simply do not make a distinction between functions and operators.

This distinction seems useful only in the context of lower-level languages like C where the operators translate directly to single machine code instructions and thus they provide clues about performance.

But in a higher-level language this distinction is superficial. It's just another function, just with a much shorter name and perhaps using infix instead of prefix notation. E.g. in Lisps there is no such distinction. "+" is a valid function name. In Haskell - same, but you also have a built-in syntax for specifying that you want your function to be called using infix notation by default.

In principle I agree with this. But as a relative beginner to Haskell operators and their precedence levels are a barrier.

Operators/functions like `+` have well-understood semantics but I don't see how anyone could have an intuition for what `.:` does.

On precedence, I find myself wishing my editor could show me the expression fully parenthesised so I can see if I'm not mentally parsing it correctly.

If we teach operators to children they won't become adults biased against some operators they haven't learned.

See Silhouette's post that is parallel to the parent. These operators don't make sense until you know the underlying concepts. Teaching the whole thing to children seems ambitious enough to probably be unrealistic.

Operators/functions like `+` have well-understood semantics but I don't see how anyone could have an intuition for what `.:` does.

As with many concepts in programming, or any other field that has its own language for that matter, a lot of this comes down to experience.

If you're used to OO-friendly languages like Java or Python, you probably think of the operator (.) as looking up a field or method on an object. If you're used to FP-friendly languages like Haskell, you probably think of (.) as function composition, and it's just as familiar and everyday a sight.

To someone who is new to Haskell or broader functional programming concepts, it might not be immediately clear why ($) is useful if you already have (.), but it's something you soon use as second nature. Before long, you come across concepts like Functor, Applicable and Monad, and with them operators like (<$>), (< * >) and (>>=). The behaviours those operators represent don't even exist outside the context of the underlying abstractions, so someone who isn't familiar with the abstractions won't understand what those operators mean or why they are useful. Again, though, in Haskell these things are routine, everyday tools, just like using (++) to increment a variable in a language like C or JavaScript. That increment operation makes little sense in a functional language where mutability is not the default, and Haskell has no direct equivalent and indeed uses (++) to mean something completely different.

By the same token, to someone who uses (.) all the time for composition of two unary functions, using (.:) for composition of a unary and a binary function is only a small mental jump and makes sense.

None of this is to say you can't take things too far, but it's important to distinguish between using unnecessarily cryptic notations for no good reason (usually a bad idea) and using notations that might appear cryptic to someone who doesn't yet know the concepts but that provide a concise notation for something that is used all the time by someone who does (often a good thing).

How do you deal with namespaces (or anything analogous like package names) there?

E.g. if you have a function named "+", it can likely clash with other functions named "+"

If the programming language supports function overloading that can be resolved through the types

By the way, I actually like RPN calculators, and low level stack based programming languages, where operators and functions also work the same way, but that is mostly interactive or for small self contained programs

This is a problem of the model of polymorphism a language has. It's orthogonal to the function/operator distinction. It doesn't arise based on having this distinction or not.

In Haskell you use typeclasses (you can think of them as Go interfaces or Rust traits) and without them you cannot introduce nameclashes. In Scheme (the Lisp that I know)... you don't have anything. You import things from libraries, define variable bindings and depending on the order of all this your variable is going to be bound to something, most likely a procedure... but which one? Depends on the order. Not great. I prefer the Haskell approach to this, but then Haskell is a bit complicated in other areas. :/

But again, this has little to do with "operators vs functions".

> But again, this has little to do with "operators vs functions".

It has to do with it in the sense that you can add package names or namespaces to function names which are already text, but it looks bad to do this with symbolic infix operators like "+"

It would be nice if everything that operates looks exactly the same, but maybe the field of mathematics could start with fixing their notation then instead: mathematics uses a bit of everything you can imagine:

add, subtract, multiply, division, power, root and log are all binary operators and instead of making them all look the same, mathematicians have chosen to:

* infix symbol for add and subtract

* no symbol at all (usually) for multiply

* superscript for power

* horizontal bar and put things on top of each other for division

* another horizontal bar and a superscript on the left for root

* function-name notation with subscript for log

Maybe this is a global optimum that math has converged to because this mix of different things actually is the easiest way for the human brain to read formulas the fastest, e.g. the arbitrary grouping that division creates and the fact that this eliminates the need for some parenthesis, and the easy visual difference between all the different notations, may really help. In some programming languages, if you've got dozens of parenthesis or deeply nested indentation, can you easily tell which argument is to which function?

Or, it's just a historically grown monster that could as well have turned out entirely different and can have other forms that would be faster to interpret.

A lot of these things were established long before mathematicians started talking about functions, let alone give a robust definition of what a function is. It may have obscured the fact that these things are very similar to each other.

At the point when there was an effort to formalize these things ideas like RPN starting popping up.

Mathematics also deals with a much more flexible medium. It's written on a plane, in 2 dimensions, whereas programmers confine themselves to just one. Mathematicians are also free to make up their own notation and symbols, whereas programmers are confined to a single alphabet and most often can't extend the syntax.

EDIT: Case in point: some mathematicians argued for a while if abs (absolute value) is a function. Some argued that it's not, because you need two formulas to define it. When somebody pointed out that (for real numbers) it's just "sqrt(x^2)", the first ones agreed. Sounds silly in retrospect now that we have a set-theoretic definition, but at the time it wasn't obvious and all these functions looked very different from each other.

> Case in point: some mathematicians argued for a while if abs (absolute value) is a function. Some argued that it's not, because you need two formulas to define it. When somebody pointed out that (for real numbers) it's just "sqrt(x^2)", the first ones agreed.

Isn't that a circular definition, though? sqrt(x²) = ±x, which isn't a function since there are two values in the domain for each value in the range (other than zero). The version they're equating with abs(x) is the absolute value of the square root, or abs(x) = abs(sqrt(x²)), which is true but wouldn't help prove that abs(x) is a function.

Of course, the underlying problem was the premise that a function must be defined by exactly one formula.

When people take the square root of a number during working with real numbers, they almost always mean the non-negative root. It's a convention. Only when they start considering complex numbers, this convention breaks, and the square root ceases to be a function - even according to the modern definition -, because "non-negative" still doesn't narrow it down to a single number in the general case.

Isn't that basically what I said? The convention is that sqrt(x) is generally read as abs(sqrt(x)). The definition is that sqrt(x²) = x, which has positive and negative solutions in x for any x² > 0. You can choose to ignore the negative solutions (or the positive solutions) to make it a function, but I wouldn't consider that any simpler or closer to a single formula than the piecewise-defined version of abs(x). It's an arbitrary restriction—much like the mistaken idea that a function must be defined by exactly one formula.

Why not just say that abs(x) = ±x, ignoring the negative solutions? If you'll accept "the non-negative square root of x²" then I see no reason to reject "the non-negative component of ±x". Both are single formulas with positive and negative solutions combined with a qualifier rejecting the negative solutions.

> The definition is that sqrt(x²) = x, which has positive and negative solutions in x for any x² > 0.

When people write "sqrt", they mean the function, or, "principal square root". "A square root" is a different thing. Saying "the definition" makes sense only within the context where the definition is established, otherwise we have to fallback to the common usage. Wittgenstein would laugh at this conversation.

Also, I'm not arguing for this convention ("it needs to have a single formula to be a function"). And when you start substituting symbols, almost nothing withstands this test. Because then you can always always twist the formula into several cases. And generally thinking about functions as something that is defined by formulas is a very limiting view. Almost all functions cannot be defined by formulas.

In C++, argument-dependent lookup (https://en.cppreference.com/w/cpp/language/adl) lets you specify operators in the same namespace as the type of (any of) their arguments.

It's mostly true that operators are equivalent to functions, but there's an important distinction at parse time too for most languages.

You can have functions named foo, bar, and foobar, but without some sort of convention (usually whitespace or other delimiters) it isn't possible to look at the string foobar and identify whether this is supposed to refer to the single function by that name or to whatever having foo and bar adjacent means in your language (probably composition or application).

Contrast that with operators like +, which serve as delimiters by themselves and can be unambiguously placed next to other function names because they're drawn from a different character set.

Whether that convenience is worthwhile is up for debate, but I think it would be surprising to type a+b and get some kind of parse error that can be rectified just by typing a + b instead.

> Whether that convenience is worthwhile is up for debate, but I think it would be surprising to type a+b and get some kind of parse error that can be rectified just by typing a + b instead.

I kinda prefer that a+b lexes as one identifier: a+b. Also rabbits-are-cute.

Exactly.

a+b should be the same as a.add.b

A high level programming language should be designed for communication instead of dictating the computations.

> For mathematicians, operators are essential to how they think.

But programming is not math, just like it isn't text, or color, or datetimes, or any other type of value our programs deal with. Even in programs I've written whose purpose is numerical processing, a vanishingly small fraction of the program involves doing math.

We have no problem using a domain-specific language (like regular expressions) for the occasions where we need to work with text. Likewise for querying a database (SQL), or text styling (HTML). We shouldn't need to infect the rest of the language with all the massive complexity of "operators" just to be able to write "a+b" in every possible context.

In fact, even when I need to do math, the built-in operators are too weak to support half the math I need to do. We're paying a huge cost, and not getting our complexity's worth.

It's not even visually correct. The example here is:

    x + (y + z) == (x + y) + z

which is true in mathematics but not true in most programming languages, where the values could be implicitly promoted modulo integers of different widths, or IEEE-754 floating-point values. He says he wants operators so you can see that addition is associative, but in his language, it's not.

My favorite design, in terms of separating the syntax, is actually Tcl. Remove the complexity of needing infix arithmetic operators from 99% of the language, but keep it available for the times when you want it. It still doesn't support half the math I need, but at least the language was kept simple by having math ("expr") and text ("regexp") off in their own commands.

Operators are a tradeoff between compactness and ambiguity. They add ambiguity because they are polymorphic, and the order of operations becomes implicit, governed by the operator's priority (for infix or mixed pre/postfix).

Many programming languages abuse the + operator for string concatenation, which is not commutative. This is where my tolerance for operators ends.

I can imagine there exists advanced math where addition is also not commutative, yet they probably use `+` there too. Aren't you throwing the baby away with the bath water?

Such usage may exist, but it should be rare. In the words of Wikipedia, It is conventional to use the plus sign to only denote commutative operations.

For possible alternatives, Perl6 uses ~ for string concatenation (and prefix ~ for stringification). I like it.

Please note that Perl 6 has been renamed to Raku (https://raku.org using the #rakulang tag on social media). With regards to using ~ , nothing has changed :-)

I understand your confusion, but in math the + operator does not have to be commutative either. It often is, but just like in programming, you can define in it anyway you want.

By convention the + operator is usually reserved for commutative operations though.

I have never seen + be used for a non-commutative operation in mathematics. I have seen it used for something which is to-be-proven-to-be-commutative in the next page or so. Similarly, I have only ever seen juxtaposition (like “ab”) used for associative operations, I.e satisfying a(bc) = (ab)c.

Multiplication of octonions is non-associative and usually expressed by simple juxtaposition.

This is a recurring problem when working with floating point values. Intuitions about concepts like associativity or even equality don't necessarily hold, but in many cases you will still get away with it, so it can feel like there's inconsistent or unpredictable behaviour. That can be a big stumbling block for inexperienced programmers working with this type of data at first, and it surely leads to many bugs.

With experience, programmers adjust their intuitive expectations and guarding against these kinds of bugs becomes second nature, and to some extent that is probably the best we can do because of the nature of the beast. However, it does illustrate the cost of violating intuitive expectations about how familiar operators and functions will behave.

> Many programming languages abuse the + operator for string concatenation, which is not commutative.

This is why Julia uses `*` for string concatenation, which they claim is “more natural” than `+`. Not sure I agree - I’d rather see a completely separate operator for concatenation, such as Haskell’s `++` or Lua’s `..`.

Arguably the simplest notation for string concatenation would be just concatenation (which would be the notation for multiplication, hence why Julia's choice could be argued to eb the most natural). Unfortunately programming languages can't quite deal with the ambiguity of having `a (x + y)` and `f(x)` refer to different operations.

Some languages seem to allow it for string literals though.

In Julia, you can actually omit the `*` for multiplication, if it involves literals, i.e.

  julia> x = 10
  10
  julia> 2x
  20
  julia> 2 x
  ERROR: syntax: extra token "x" after end of expression

But you have to be careful not to use white space either.

That’s quite clever, actually. This way you could chain a complex string together with parentheses without needing a lot of pluses.

Not the most useful of features, but it does explain why * is the concat operator.

Well now I want a language to overload white space as an operator

C++2000 has you covered: http://www.stroustrup.com/whitespace98.pdf

But that doesn't help, because * also commutes, and string concatenation still doesn't.

> * also commutes

It does for numbers, but not generally - e.g. for matrices.

Are you ok with using + on floating point numbers as it's not truly communative their either.

The PEP adding a matrix multiplication operator to Python also contains a section about the advantage of an operator in that case: https://www.python.org/dev/peps/pep-0465/#why-should-matrix-...

On the other hand adding a ~ operator similar to R seems was just rejected: https://mail.python.org/archives/list/python-ideas@python.or...

Yes, well known operators like `+` with well known meanings are useful.

Why would you write a post about this? Is there some kind of disagreement out there about this? I can't think of any popular language that doesn't have it!

Now, consider this instead:

    n <> x &~ n

Not only do you not know how to parse this without further knowledge, you also can't pronouce it in a meaningful way or hope to guess what it means.

Is this legal python?

Yes. At least in Python 2. "<>" was an alternative spelling of "!=".

<> is gone in python 3

When you're unsure about how Python treats an expression, then the ast¹ module is your friend:

    >>> ast.dump(ast.parse('n != x &~ n'), False)
    Module([Expr(Compare(Name('n', Load()), [NotEq()], [BinOp(Name('x', Load()), BitAnd(), UnaryOp(Invert(), Name('n', Load())))]))])

It can make it easier to reason through the curiosities, such as the precedence in the given example.

Note: Suggesting `ast` as a solution surely proves continuational's point ;)

1. https://docs.python.org/3/library/ast.html

And it's not easy to Google, which is arguably more important than being pronounceable

> Not only do you not know how to parse this without further knowledge, you also can't pronouce it in a meaningful way...

Therein often lies the problem, if you mentally cannot translate the symbols into meaningful concepts it's hard or impossible to work with them. For example, there are primitive tribes who's language only has words for the amounts of one, two and three. All amounts above that are simply referred to as 'many', no matter if it's four or a hundred. These people cannot (or at least not easily) be thought basic mathematics because they probably can mentally picture 2+2=4 being different from 2+3=5.

So if you can find words for these symbols or make up words for your own for that matter and are able to read this expression in these words it will be a lot easier to parse and understand, maybe even intuitively.

edit: another example in the Python domain for me would be list and dict comprehensions. When I first encountered them in other people's code I had a hard time understanding what they did. Searching for them was also hard, since I could only describe them (ie: loop within square brackets) and not name them. Finally when I found their name in an reply on SO I was able to search directly for the concepts and find meaningful answers on how to apply them in certain cases.

> Searching for them was also hard, since I could only describe them (ie: loop within square brackets) and not name them.

I hope one day someone invents an interactive machine, the user of which can point at a thing and ask "what is this", and get documentation.

Like explainshell.com, but as an editor extension?

A new operator is just a letter/word you haven't learned yet. The only things wrong with operators is that non-Asian speakers don't like learning new letters and search engines refuse to index them.

Seems easy to parse for people used to working with bit sets in C. The &~ operator is actually two operators frequently used together to do a set difference(†). So it's asking whether n is different from removing all the bits of n from x. The answer is true.

†: It's so frequently used that on x86_64 there's a single instruction for that, ANDN.

Unless of course you are talking about Haskell and its semigroup combine operator and its lens update operator. In that case the expression can't type check: n has type State s a, x has type s, and n also has type s, which means s is an infinite type and fails occurs check.

Even in C bit twiddling, I'd write

  x & ~n

rather than

  x &~ n

The former is much easier to parse (at least to me). ~ is a unary operator, so it's easy to think of ~n as one thing. But &~ is two operators, which I think of as two things, not as one (even if the combination is common).

This may have been mentioned elsewhere, but Python already has a syntactic way of merging dictionaries:

  d = {**d1, **d2}

which arguably has all the visual benefits argued for.

d = d1 + d2 is way easier to parse.

As mentioned elsewhere in this thread, the mathematical + operator is commutative: d1 + d2 == d2 + d1. How does the + operator maintain that commutativity in the face of duplicate keys?

The + symbol doesn't denote any particural operation mathematics. it widely used for vector space where commutativity is a condition though.

A symbol's property depend on the operation, the multiplication symbol for example is commutative in some cases and not in others.

It is a convention, not a rule, in mathematics to use (+) to represent operations that are commutative (i.e. abelian) groups.

But this convention is not at all respected in programming (e.g. + for string concatenation in many languages) so I have to admit that it's pretty irrelevant.

The war to keep programming operators at all consistent with mathematics was lost long ago, with `=` and `==` being the worst offenders.

To be fair, mathematics uses = to indicate assignment as well, e.g. for summation limits.

Operators are polymorphic. While the + operator is commutative when using on integers/float, it is not currently when used on lists:

>>> [1,2,3] + [4,5,6]

[1, 2, 3, 4, 5, 6]

>>> [4,5,6] + [1,2,3]

[4, 5, 6, 1, 2, 3]

In dictionaries it would behave differently as well (duplicated keys, etc.)

It's also not commutative on strings and that is the case in many languages, not just Python.

That already falls apart when the + operator is used for string concatenation so I think the answer is people are using it in a less rigorous sense already.

The + here is not a mathematical + per se.

The PEP [1] addresses this:

Few people would be able to guess what it means the first time they see it, or think of it as the "obvious way" to merge two dicts

[...]

{d1, d2} ignores the types of the mappings and always returns a dict. type(d1)({d1, d2}) fails for dict subclasses such as defaultdict that have an incompatible __init__ method.

Though I'm not personally convinced that + would be more obvious or that dict subtypes are merged often enough for this to matter.

[1] https://www.python.org/dev/peps/pep-0584/#d1-d2

Great PEP :-)

It also mentions further down, that for lists er have both

  a + b

and

  [*a, *b]

As well as other ones I hadn't even thought about like a[len(a):] = b.

Unrelated, but I think this is the first time I've seen Mailman with actual CSS applied to it…

Is that from a mailing list? I really like it, it's much more readable / user friendly than most mailing list posts I've seen. Call me an inverse luddite or something but I never could get into mailing lists.

Yup, it looks like it's using HyperKitty.

It's been about 15 years since I last installed and configured GNU mailman but I thought it was a solid application for what it does. It's great to see UI improvements in the web interface side of it.

To save others from having to use a search engine, the project page is at https://gitlab.com/mailman/hyperkitty with documentation at https://hyperkitty.readthedocs.io/en/latest/

This is the kind of thing that wouldn't hurt if would be contributed back to mailman and became the default. Many of these Open Source projects have really poorly thought out defaults (if anybody even thought of these default values, at all).

I think that's the default for mailman 3

That's great to hear. I hope more projects upgrade, then :-)

Interesting point. This might also explain why Lisp never really went mainstream.

Counterpoint: Java.

Java was designed during a time when operator overloading was considered abysmal language design.

But that was mostly due to the experiences collected with C++ (or maybe also Perl?).

I have dreams of throttling the person who decided that operator overloading was overrated every time I work with BigInteger.

Do you have examples of real world code you had to write with BigInteger? just for amusements sake

I can't seem to find the file for it, but I solved #2 on this with Java and wanted to die by the end of it: http://socalcontest.org/history/2017/SC2017ICPCProblems.pdf

It's one of the things I really like about scala, x call y is always equivalent to x.call(y)

This combined with relaxed method name restrictions allow you to do "operator overloading" in quite a sane way and allow you to write bigint + 1 or set contains element.

Kotlin is a bit more conservative and only translated the built-in operators to fixed methods: + to the plus method etc.

Write your program on ints and then transform it with sed before compiling.

That sounds significantly more difficult.

The worst part is there is a talk by Steele called Growing a Language about designing Java where specifically talks about the importance of overloading so that things like future number representations like BigInteger can be first class

Perl 5.000 came out in 1994, the same year as Java.

Perl didn't even have objects before that.

So no it wasn't from experience with Perl.

It might also be that your brain is just more used (years of extra experience) to infix notation. So why not take advantage of this ? In the monad world, people also prefer (>>=) to bind. OTOH, how long does your brain need to get used to other notations? As an aside, his arguments are completely debunked if you use RPN.

   > Commutative: a b + == b a + 
   > Associative: a b c + + == a b + c +
   > ...

Why do you use infix for ==?

otherwise the challenged would not understand my point ;)

I thought I might get some anecdotal evidence for this by teaching our daughter Scheme (and prefix notation) before she enters elementary school :-)

That sounds great. The syntactic simplicity of prefix notation and Scheme seem particularly suited for early education. I imagine it will help form a intuitive mental model of computation and mathematics, before being taught the classic infix notation. I guess you'll see!

> It might also be that your brain is just more used (years of extra experience) to infix notation.

Maybe infix notations is preferred because it aligns more closely to natural language grammar (for some languages)

Infix notation is preferred because the binary operator is visually close to both of its operands. The same equations as GP, but == is also postfix:

   > Commutative: a b + b a + ==
   > Associative: a b c + + a b + c + ==
   > ...

As expressions getting larger and larger the operands are getting farther away from their operators. RPN is great for computers to read and maybe humans to write (RPN calculators). Not so much for humans to read.

> It might also be that your brain is just more used (years of extra experience) to infix notation.

I’ve recently started to work with a program that uses Reverse Polish (postfix) notation [1] to implement mathematical equations and I find it very hard to make sense of the equations from the syntax. I hadn’t previously been aware that there were other alternatives to infix notation.

[1] https://en.wikipedia.org/wiki/Reverse_Polish_notation

function1 >>= function2 >>= function3 >>= function4

bind bind bind function1 function2 function3 function4 -- Throw parentheses at random until it compiles

It's very easy to see why people prefer the operators.

There are two things I hate when dealing with maths heavy code.

  1. Lack of operator overloads.
  2. Long variable names.

The first I find uncontroversial, the second is where I have met with disagreement.

So he's saying that operator notation engages "system 1" mental processing whereas the function call notation requires "system 2".[1]

[1] https://en.m.wikipedia.org/wiki/Thinking,_Fast_and_Slow

It's almost like notation is a tool of thought, or something.

For the uninitiated, "notation as a tool of thought" is a paper by Ken Iverson (https://m-cacm.acm.org/magazines/1980/8/10988-notation-as-a-...), creator of APL programming language

For example take a look at the Python API for Z3. Because of operator overloading it is just beautiful. Much better then raw SMT2.

https://ericpony.github.io/z3py-tutorial/guide-examples.htm

Sympy is nice too.

Please, please, please, a pipe forward operator. <3

Operators for all my friends!

https://www.ozonehouse.com/mark/periodic/

The range exclusive operator is the most friendly, I think.

Operators can be useful in a setting where they are expected and natural - numbers, strings etc. Overriding them for dictionaries, streams custom classes has been shown to be a bad idea that makes the authors feel clever but results in code that is both less readable and harder to lookup - your IDE could bring up the right documentation when asked on dict.union but without some advanced syntax and type analysis will not be able to guess what | means for dicts and you'll get the documentation for bitwise or

It's weird to blame a language design for what's simply a bug in your IDE.

Leaving the substantive comments to the mathematicians, this was an enjoyable read that was easy to understand.

Especially “Of course, it's definitely possible to overdo this -- then you get Perl.”

> it doesn't matter whether the + operator binds tighter to the left or to the right

Depending on the language, (a+b) + c may or may not be the equivalent of a + (b + c)

Interesting. Apparently this is true in Python because it uses bignum numbers.

As I understand it, it's true in Java too, because (signed) integer overflow is defined to wrap-around. It's not true in C, where signed overflow invokes undefined behaviour. In C# it depends on the mode whether you get wrap-around or an exception on overflow.

And of course it's never true with floating-point.

Reducing cognitive load [1a], transforming representations into something we can understand (e.g. x86 vs Python) [1b] and engaging our visual cortices [2] are all amazing things to get ourselves to be more productive.

[1a] Cognitive psychology: working memory 4 to 10 items

[1b] Cognitive psychology: I read it in some textbook how this works well, it also makes intuitive sense to me.

[2] This idea was stated out loud in one of 3Blue1Brown's videos, and well, in his case he demonstrates how true it is.

Without operator we’d still be MOVing and ADDing

We might be using Lisp.

In a discussion on the usefulness/overuse of operators, I'm surprised nobody has mentioned J. Here's quicksort in J:

  (($:@(<#[), (=#[), $:@(>#[)) ({~ ?@#)) ^: (1<#)

Good luck understanding that!

I like the example about the distributive law. But for the associative law, one could also simply write:

  add(x, add(y, z)) == add(x, y, z)

No. That assumes that "add" is left-associative, i.e. it expands to add((add(x, y), z)). It's not obvious.

OK, but for operators that are both left- and right-associative, this notation (variable number of arguments) is already used, e.g. in LISP, right?

Both... at the same time? I.e. they are associative?

If only one at a time, then perhaps there is. But TBH I can't think of an example from the top of my head right now.

Yes, I meant (fully) associative.

In this case it's justified, because there is no ambiguity. Just as a mathematician would write using traditional notation without parentheses. At the courses I attended in group theory, module theory etc. we were always required to prove that things are associative before dropping parentheses. Lisp notation just requires less characters (the '+' isn't repeated), but the convention is the same.

assumption that ‘add’ is a function of two arguments is wrong if not deliberately misleading

Why? In math, that's actually how operators are defined.

Because you’re limiting expressiveness of the function by applying unnecessary restrictions

I see now and agree fully. On my first reading I managed to misinterpret your comment in a way I can't imagine now.

You were grammatically overloaded. That's why words are bad -- they are ambiguous even after using context.

Sure, so prove that add(x1, x2, ..., xn) is equal to any permutation of the numbers x1, ..., xn. You still need to prove that add(x, add(y, z)) = add(x, y, z). So now you have two things to prove...

“Sure” what? I don’t need to prove any of that to use variadic ‘add’ function. Pretending like it’s function of just two args is just a cherry-picked example to make operators look nicer.

Surely you still want to know about properties like add(x, add(y, z)) = add(x, y, z), to take advantage of the variadic functions. I was just pointing out that making something variadic doesn’t mean you have less work to do correctness-wise - it’s strictly a quality-of-life improvement for using the operator.

The difference between function add and operator plus are solely in the resulting parsing tree. Chaining pluses together is the same as adding arguments to add. Proving correctness of operators and stuff is just not something I do when I write python code.

> Chaining pluses together is the same as adding arguments to add

No, chaining multiple pluses together in Python (as in most widely-used programming languages) is exactly the same as doing multiple two-argument additions, and is not the same as doing a multiple-argument addition.

You can see that in this Python code:

    n = 2.0 ** 53
    print("(1)", n + 1 + 1)
    print("(2)", (n + 1) + 1)
    print("(3)", n + (1 + 1))

the line (1) has the same result as line (2), but is different from (3).

That's because addition of floating point numbers is only defined for two numbers and is not associative, so `n+1+1` is parsed as `(n+1)+1` and not some magical three-argument floating point addition, which would give the same result as (3).

irrelevant edge cases

chaining pluses is the same as adding arguments to add

watch:

1+1+1 == add(1,1,1) == 3

you dont have to be so pedantic about implementation quirks, it's not going to become important in your lifetime, unless you consider this comment thread important, in which case, congrats.

Depends on your language. In Lisp, + takes any number of arguments. In C++, it takes exactly two.

(I'm presuming that by 'add', you mean '+'. If not, then 'add' takes however many arguments it is defined as a function to take, and that still is language- or library-dependent.)

(And if you refer to pure math, then add or + is only a function of more than two arguments if it associates, which is dependent on the argument type.)

no, by `add` i mean exactly the function `add`, not + operator. he cherry picked the example to show how operators are "better", he's wrong. in practice sum of a sequence is more important concept than it's special case - sum of two arguments.

What function 'add'? 'add' in some computer language? If so, which language? Or 'add' in mathematics? If so, what is the difference between 'add' and '+'?

`add` is just another manipulation on guido's part. `sum` is the name of the concept.

One more time: Are you talking about a specific feature in a language, or are you talking about mathematics?

a concept in programming

Then what is your basis for saying that the sum of a sequence is more important than the sum of two numbers? Given associativity, the sum of a sequence is the same as recursively taking the sum of two numbers. Going the other direction, if you have the sum of a sequence, then the sum of two numbers is obviously included in that. The two approaches therefore seem completely equivalent to me. So why say that one is the more important concept?

Because it’s more general

Reply on news.ycombinator.com