I've grown to dislike operator overloading quite a bit, and thus developed a general skepticism with regard to operators in general, and I think this article ac

I've grown to dislike operator overloading quite a bit, and thus developed a general skepticism with regard to operators in general, and I think this article actually reveals why partially. First off, I'm surprised this article doesn't touch at all on the fact that operators are usually the only "blessed" functions in languages to be able to be written in infix form, as I think that's actually where many of the "benefits" being described here come from. For example, I believe the first example about how operators highlight the lack of ambiguity in the expression "x + y + z" has little to do with operators and more to do with prefix vs. infix notation. Notice that this is not apparent if we use operators but also require prefix notation instead: "+ + x y z" vs "+ x + y z". Here too you may never realize how the binding order doesn't matter, because binding order is non-existent and unnecessary. The fact that in most languages non-operator function calls must be in prefix form shows the true concern here. If you for example imagine working in Haskell, where you can apply the opposite experiment, non-operator functions in infix form, this discovery could also arguably have been highlighted: "x `add` y `add` z". All this to say, I do not see this particular point as a great defense of operators. But the real problem in my mind comes from the eventual overloaded meaning. This is actually displayed in this very blog post. Near the end, the author mentions how * is not always commutative, but in math, + is. And yet, in the simplest non-math example use of operators, string concatenation, we already find that + is not commutative. So what we're really doing is creating very terse function names that "often" imply a set of rules, but also often don't. In other words, in one specific domain they have a specific meaning, but when put into a general purpose programming language, they actually are just... "un-user-friendly one letter names". And this gets to the heart of the issue. I agree that operators probably trigger a different part of the brain, but I think they do so simply because we use a reserved part of the character set to express them that we don't use for anything else. So they stand out. If "+" was replaced with "a", I don't think that "b a b" would really be that visually more helpful than "a(b,b)" -- so its not the magic "operator-ness" of the function, its not even the infixness, its the fact that we're basically putting a weird character in there, the same as how a smiley face emoji would stick out, or perhaps how "bolding" text would stand out (if that were possible in your programming language). The problem is that these magic special limited-set characters are very attractive, and once you have a concept you firmly understand, you want to map them onto the closest version of the standard math forms. Case in point, string concatenation. But these new applications very rarely map exactly, and soon we end up with incredibly terse names that trick you into thinking they behave like something familiar. Most people would agree that "add" isn't the best name for a string concatenation function, and would hold a lot of weird meaning baggage, but the abstractness of the "+" operator (and the fact that we read it allowed as "plus") fools us into using it.