15 ms·

Why Operators Are Useful

178 points by s16h 8y ago

j88439h84 8y ago
Python already has an 'operator' for combining dicts. d = {d1, d2}
- ploxiln 8y ago
  just have to avoid HN italic syntax thing, but yes: d = {**d1, **d2}
  - j88439h84 8y ago
    Heh, thanks :)
- deleted 8y ago
  [deleted]
phoe-krk 8y ago
This is much less confusing than (2), and leads to the observation that the parentheses are redundant, so now we can write "x + y + z" This is a non-problem if you're using Lisp. (+ x y z) accepts an arbitary number of arguments and the operator precedence problem does not exist since there is no operator precedence.
- hjk05 8y ago
  Try writing out typical mathematical formula derivations using only s-expressions. I tried for a period and abandoned the persuit. It’s just not comparable to established mathematical notation.
  - michaelmrose 8y ago
    Two solutions. Threading macros wherein instead of nested parens like (x (y (z))) one writes ((->> z) y x) In clojure there is an interesting package https://github.com/rplevy/swiss-arrows https://github.com/rplevy/swiss-arrows which allows one to perform successive operations with explicit placement of the result of prior evaluation by placing a <> in the form ((->> (z <>)) (y <> 7) (x <>)) In practice it seems like there is often less need to do so as many similar functions or the same variety have the same ordering and other options like as-> exist too. There is also the idea of processing math expressions infix as expected when desired. https://github.com/rm-hull/infix https://github.com/rm-hull/infix ($= 3 + 5 * 8) ; => 43
  - ken 8y ago
    The Lisp community has literally tried exactly this, on and off, for the past half century -- and they always come back to s-expressions. Every new Lisp programmers says "I know, I'll make a macro to let me write infix math!", and then abandons it 2 months later. It's not like Lisp programmers aren't aware of how schoolchildren write (+ 2 2). I've written tons of code in both language families. In infix/prefix (i.e., Algol-family) languages, I frequently wish for a nice consistent prefix syntax. In prefix-only (i.e., Lisp-family) languages, I can't say I've ever wished for infix notation. I don't understand what the perceived issue is with infix notation, except for unfamiliarity -- and that passes soon enough.
- platz 8y ago
  So you trade simplicity in one problem (precedence) and gain complexity in another (variadic arguments and (lang-dependent) multiple variadic function implementations)
  - bjoli 8y ago
    You don't have to make your functions variadic, it is just handy when working with numbers.
- QuadrupleA 8y ago
  Lisp is pretty ugly :) (eql (* x (+ y z)) (+ (* x y) (* x z))) I wonder if its famed sense of enlightenment is partly just overcoming the mental hurdle of it's syntax. Edit: typo fix, had x/z mixed up
  - explainplease 8y ago
    You don't have to do it like that. You could do: (= (* x (+ y z)) (+ (* x z) (* y z))) Or: (= (* x (+ y z)) (+ (* x z) (* y z))) Or: (= (* x (+ y z)) (+ (* x z) (* y z))) Or: (= (+ (* x z) (* y z)) (* x (+ y z))) Or: (= (+ (* x z) (* y z)) (* (+ y z) x)) Or: (= (+ (* x z) (* y z)) (* (+ y z) x)) I think the last one makes the relationships quite clear. Writing legible equations is an art form, as is writing sexps. Edit: If you think lisp is ugly, compare with regexps. For bonus points, explore writing regexps with lisp, e.g. with Emacs's `rx` macro. I think you won't find a more easily maintainable way to write them.
    - chongli 8y ago
      Some would argue that the fact that you have all of those alternative forms is part of the problem. Lisp is one of the (if not the) most individualistic programming languages around. Lisp makes it easy for a programmer to create their very own impenetrable, arcane, domain specific languages. This causes large organizations to avoid it like the plague. Large teams don't want artists, they want replaceable parts.
      - dorfsmay 8y ago
        Are you talking about macro or formatting? If it's about formatting, given that this is what this thread is about, you can use code formatter for lisp languages exactly like for any other language, in fact they are even easier to write for lisp because of the consistency of S expressions. If you are talking about macro, then you're in the same boat as other languages that have macros, C, Rust, ect... And remember that the first rule of macros is to not use macros, except for when you absolutely have to, and in those cases it is the most elegant solution. If you have devs inventing DSLs for everything, then lisp isn't your problem.
- ghettoimp 8y ago
  Yup. In addition to ignoring the usual Lisp convention for associative operators, I think the article muddies the waters here by using words like "add" and "mul" in all of the non-infix examples, making them unnecessarily verbose. After using prefix notation for years, it seems very natural for pattern recognition and formula manipulation. Never having to think about precedence and associativity is really nice.
- mannykannot 8y ago
  If this is so obviously preferable, why have mathematicians so obdurately not adopted this style? Mathematical notation is not an archaic practice that is followed out of a respect for tradition, or a doctrine that has been developed from first principles, it is something that has evolved (and continues to do so) because it has been useful.
  - bobbylarrybobby 8y ago
    Well mathematics notation largely follows speech. People say “one plus two” — largely because speech doesn’t have closing parentheses, so we need to speak in a way that makes it clear when we’re done talking — so that’s how we write it. But for a computer, prefix notation is great because it’s unambiguous and clear even without knowledge of PEMDAS. Similar to how Americans write MM/DD/YYYY because that’s how we say dates, but we can still acknowledge that YYYY-MM-DD is the best format for computers.
    - improbable22 8y ago
      I wonder how much is the reverse: we now tend to say mathematical expressions as they are written, but before this was standardised, you would just explain the steps. Probably not "one plus two" -- I think + is essentially a variant of & which is a ligature for "et", and I guess most languages put "and" between the things being combined. But I'd be surprised if (x/y)^2 was said "x over y all squared" by many people before this notation. But the notation is clearly more designed for thinking on paper than for explaining down a phone line.
  - newen 8y ago
    Mathematics uses infix notation literally everywhere. Just because you prefer some notation doesn't mean people who have used infix notation since they were 5 years old will like it. Also, I avoid lisp mostly because S-expressions are almost unreadable to me.
    - dragonwriter 8y ago
      > Mathematics uses infix notation literally everywhere. Mathematics uses prefix, infix, suffix, circumfix, and some more complex notations; basically any pattern any computer language uses probably is inspired from math even if math doesn't use the notation for the same operation or operator symbol.
- Rexxar 8y ago
  This is a non-problem in every language with variadic functions. "add(x, y, z)" looks good to me.
  - dnautics 8y ago
    You have to be careful though. In Julia, there is "fma(a,b,c)" which is not necessarily the same as "muladd(a,b,c)". What are the guarantees on add(a,b,c) versus a+b+c? If do add(1.0e30, 1.0, -1.0e30) is that the same (aka IEEE fp addition is noncommutative)
    - alboy 8y ago
      > If do add(1.0e30, 1.0, -1.0e30) is that the same (aka IEEE fp addition is noncommutative) You might be thinking of associativity. Both addition and multiplication are commutative up to NaN.
- mturmon 8y ago
  Your comment is begging the question. The reason that Lisp “+” can accept a list of arbitrary length, rather than a pair, is that the underlying addition operator is associative.
  - ehaliewicz2 8y ago
    Not true. Division isn't associative and you can do e.g. (/ 12 6 3)
    - mturmon 8y ago
      This is true - Lisp is making / left-associative. But this observation does not change my point: that the parent comment is saying "Lisp already has the ability to do + on lists", but the reason "+ on lists" makes sense is because Lisp is using the underlying associativity of mathematical +. And the latter associativity property, for abstract mathematical "+", is what the blog post is describing/exploring.
      - kazinator 8y ago
        The computing + is not associative for inexact types like floating-point. That's why it's important for the Lisp + to be consistently left-associative; the result could vary if that were left to the implementation to do however it wants. In addition/relation to floating-point, another way in which addition is not associative in computing is if there are type conversions. (+ 1 1 0.1) is not the same as (+ 1 (+ 1 0.1)). The former will do an integer addition to produce 2, and then that is coerced to 2.0 which is added to 0.1. The latter adds 1.0 to 0.1, and then adds that to 1.0: two floating-point additions. In languages that don't have bignums (which could include some Lisp dialects) whether overflows occur can depend on the order of operations, even when all operands are integers. The reason we can have a n-ary + is that three or more arguments can be decimated through a binary +. The concept of + is defined as a binary operation. Lisps have variadic functions that are blatantly non-associative, like, oh, list. (list 1 2 3) isn't (list 2 3 1).
Symmetry 8y ago
Operators can certainly be nice. And I do like allowing the programmer to create new ones too, though I'd tend to prefer the Haskell approach of creating new ones out of existing symbols like >< or such rather than the C++ approach of letting the programmer redefine an existing operator for a new use, << in the streams library being one of the worst common examples.
- duckerude 8y ago
  Python discourages using operators for things that don't have anything to do with their original use. If you try to be too clever with it, you run into issues. For instance, comparison operators are chained, so that `x > y > z` is equivalent to `x > y and y > z`, not `(x > y) > z`. The most radical use of operators in the standard library that I know of is in pathlib, where `Path('/usr') / 'lib' == Path('/usr/lib')`, and I think that got a lot of pushback. It's certainly an outlier. It fits well with Python's overall approach to readability. If the meaning of your operator isn't immediately apparent from its existing meanings, then it should probably just be a regular old named function or method instead. Python doesn't like DSLs very much. Programmer-defined operators are certainly useful, but Python went in the other direction, which has its own advantages. C++'s choice to have a fixed set of operators but overload them in a lot of arbitrary ways is probably the worst of both worlds.
  - zwkrt 8y ago
    You should look at the Construct library, which overloads the '/' operator as syntactic sugar to make s-expressions in it's DSL less paren-heavy. I'm not saying I agree, but it was wild when I first saw it. Struct( "foo" / byte, "bar" / Struct( "spam" / int16ul, "bacon" / int64sb, ), "viking" / int32sl, )
  - VWWHFSfQ 8y ago
    > Python discourages using operators for things that don't have anything to do with their original use. Python doesn't really discourage anything and especially not overloading operators in weird ways. You even pointed out the pathlib insanity in the stdlib. Python isn't the shiny bastion of consistency and obviousness that the zen claimed it was years ago
nikofeyn 8y ago
he doesn’t make any coherent argument as to why one is more clear or preferred than the other. he simply states it and moves on with this bias. for example, when he compares 2 to 2a, i feel he doesn’t really address anything and just states his preference as the more clear one. plus, he of course seems to know nothing about lisp (or just ignores it) where you might have: (+ a (+ b c)) = (+ (+ a b) c) = (+ a b c) all three are valid lisp syntax and represent associativity of addition well, including “dropping the parentheses”. the thing is, procedure notation as opposed to infix operators actually make it more explicit by what is meant by associativity. this is because it makes explicit about what comes first because of how procedures are evaluated. this is much more explicit than conventions of what parentheses mean in infix operator expressions. even his python procedure example in (2) demonstrates this property. the distributive law is: (* a (+ b c)) = (+ (* a b) (* a c)) that seems pretty clear to me. and with this, you can of course extend the language such that the +, , etc. procedures operate on new data types or heterogeneous data types like ( c v) where c is a constant and v is a vector and you get scalar multiplication. it is also funny to me that he considers readability over performance. well, i do too, but you can have both. see lisps, schemes, and sml dialects, all languages he seems to ignore the existence of. another thought is that i recall gerald sussman saying in a talk that mathematical notation is impressionistic, and in general, i think he is right. his point was that procedure notation is much more explicit. he also mentions that prefix notation is inconvient for small expressions versus infix notation but is much more preferred when you have very large expressions with many, many terms.
- redleggedfrog 8y ago
  Isn't "...once you've learned this simple notation, equations written using them are easier to manipulate than equations written using functional notation..." his argument why operators are more clear? I don't necessarily agree with that, but I haven't made a world class programming language, either. I just assume he knows something I don't.
  - nikofeyn 8y ago
    but programming isn’t about manipulating equations. if you want programs to manipulate equations, then again, the procedure notation, in particular lisp notation, wins out.
wiremine 8y ago
> Of course, it's definitely possible to overdo this -- then you get Perl. 100% agree. I actually really like Perl, but in practice this makes Perl programs more difficult to maintain than they should be. Also: seems like this XKCD is appropriate here: https://xkcd.com/224/ https://xkcd.com/224/
- raiph 8y ago
  Forgive me as I use similarly extreme language. I 100% disagree. Imo Guido's throwaway comment uses the same rhetorical form as hate speech. Your use of "100% agree" and "I actually really like Perl" are mutually contradictory. Now let me unpack that. I'm curious to see if you reply and whether we arrive at middle ground. ================================================= > in practice [Perl's use of operators] makes Perl programs more difficult to maintain than they should be This is an old saw but do you agree that it is a misstatement of what's actually going on: * Some Perl programmers, especially experienced ones, have made and continue to make Perl programs, including large ones, EASIER to maintain than they could be and would be if written by a similarly strong programmer using the deliberately dumbed down language Python. * Some Perl programmers, especially beginners, have made and/or continue to make Perl programs, mostly small ones, more difficult to maintain than they should be and would be if written by a similarly weak programmer using a deliberately dumbed down language like Python. Perhaps your response to that is something like "Oh sure, I just meant most programs I see because they're mostly small and written by inexperienced programmers." If not, how modern are the Perl programs of which you speak? Much has changed since 2000 and especially in the 2010s: Perl 5 has stabilized around a wise view of the language, interpreter, and how to be respectful of each others' failings; Perl 6 has radically dialed back the complicated built in availability of terribly cryptic symbol aliases as part of a complete rethink of what it means to be a Perl language. ================================================ As for the "hate speech" aspect: >> Of course, it's definitely possible to overdo this -- then you get Perl. > That's the Guido we know and love. The above was the entirety of by far the highest voted comment in the python reddit post about this article. I posted the following in sardonic response, which also got upvoted: Guido: > Once you've internalized the simple properties which operators tend to have, using + for string or list concatenation becomes more readable than a pure OO notation, and (2) and (3) above explain (in part) why that is. Larry: > But it contradicts property (1). That's (in part) why I did not use + for string and list concatenation in Perls. Then again I used it for adding floats, even though that contradicts property (1) too. And changed my mind about what symbol to use between Perl 5 and Perl 6. Heck, who cares about consistency? Guido: > I care. I consistently hate on Perl and Python users consistently love me doing so. I generally find Guido's and the Python community's intolerant attitude consistent with the above and with this exchange about the same article on twitter: > Random nit: you've got a "font-size: 85%" in the CSS for your posts. Mind removing that, so those of us with our default font-size set deliberately don't have to squint? Guido: > I'm sorry, I have no interest in CSS hacking. The template is what it is. Deal with it. Guido's riposte also got lots of hearts (presumably to soothe or applaud their beloved ex-BDFL). I note the follow up got nothing from Guido: > It's a single-line deletion, and would improve the accessibility of your blog, but sure ok. There's zero chance Larry would have thought and spoken as Guido did and he absolutely would have made that single line deletion out of respect for the person whose eyesight wasn't as good as others'. The same attitude applies to improving the language and culture. ================================================== How familiar are you with current Perl activity? I see a new Perl emerging, one that will unfold throughout the 2020s. I see a well entrenched self-reinforcing tolerant attitude in Perl culture, even of those who like to use too many operators for my liking.
0815test 8y ago
The mnemonic value of "operators" as reminders of properties such as associativity or commutativity interestingly extends to diagrammatic reasoning. A diagram is really just a generalized expression, and this becomes quite useful when one has to deal with more than one "type" or "domain" of operation, but in a consistent way that preserves the compositionality-like properties OP talks about. A recent book exploring this topic is "Seven Sketches in Compositionality; An Invitation to Applied Category Theory" https://arxiv.org/abs/1803.05316 https://arxiv.org/abs/1803.05316 . (Despite the obvious reference to CT in the title, the work is quite accessible and the math involved is not much more complicated than that found in the linked blogpost. Importantly, and perhaps unlike some people in other programming-language communities, the author does not assume any pre-existing knowledge; the work is rather about using concrete, real-world examples to gently guide the reader's intuition.)
mpweiher 8y ago
Smalltalk also doesn't have this problem. Since all message-sends are essentially infix, operators (binary message sends) are simply special keyword messages. 1 add: 2. 1 + 2. This is helpful when you have "operators" that aren't quite as obvious, for example raising to a power. 2 raisedTo:3. Since there are no operators, there is no operator precedence. However, there is precedence between different message types: unary binds tightest, then binary, keyword last. Otherwise evaluation is uniformly left to right. While this is a question on Smalltalk job interviews ( What is 2 + 3 * 5. ?), that's only useful for filtering out people who simply have never seen Smalltalk before (in case they claim knowledge). It doesn't seem to be an issue in practice, because the evaluation rules are otherwise so simple and uniform. The other surprising effect is that binary message sends don't seem to have the same tendency to be confusing that operator overloading does. I don't really understand this effect, because the mechanism has effectively the same power.
makecheck 8y ago
A “dict” operator would be vague because there is more than one way to combine dictionaries. Why should I have to guess whether duplicate keys are being skipped or replaced by a symbol, when two different well-named functions will always make it clear?
- sametmax 8y ago
  Same with lists and strings, and it doesn't bother anybody: even for dict, it's just a matter or reading from the left to the right.
  - makecheck 8y ago
    Of course it’s not the same. There is one sensible result expected when adding two lists or strings together (since they’re linear, it would not make sense to encourage inefficient search/replace operations with an operator; and also, the containers do not require unique keys, you can simply extend them). A dict must deal with conflicting keys, and arguably each situation requires different treatment of those keys.
    - pacala 8y ago
      The sensible thing is to throw on conflicting keys.
      - deleted 8y ago
        [deleted]
      - JoelMcCracken 8y ago
        What? Have you never had two dicts and wanted vals from one dict override the other?
        vivekseth 8y ago
        If a+b != b+a that breaks the commutativity property of addition.
rossdavidh 8y ago
Wow, he's still got it. I read the whole thing, without realizing it was Guido Rossum, thinking "hey, that's a really good point". Then got to the end and realized it was the inventor of the Python language. So, I wasn't impressed as I was reading it because of who it was, I was impressed because he was making a really good point. Obviously, the fact that he made my favorite programming language was no fluke.
- maskedinvader 8y ago
  Ramblings through technology, politics, culture and philosophy by the creator of the Python programming language. This was literally the first thing I read when I hit the link. Don't mean to sound rude but how did you miss that ? Does it render differently on web? I saw this on the mobile version of the site on my Android.
  - ChrisSD 8y ago
    For me that was covered up by some popover I didn't read. Besides the tagline of a blog is the sort of thing I for one gloss over. I've had decades of training how to skip straight to the content.
    - maskedinvader 8y ago
      That's what I thought, usually even I am trained to skip those few lines under titles (like opinion articles have a blurb about the author )
    - rossdavidh 8y ago
      Yeah, that's me exactly.
  - ruanmed 8y ago
    I don't know why, but I did the same thing. I read the post content first, then after finished I went backup and saw the blog title and subtitle. Or I could say my brain was only conscious to reading the blog title and subtitle afterwards.
karmakaze 8y ago
The dict example given is exactly why operators wouldn't be useful to me. Presumably d1 + d2 != d2 + d1 for some d1, d2. If you're going to use the + operator then it should behave like it does in other contexts.
- hprotagonist 8y ago
  this is equally untrue true for strings, of course. “foo”+”bar” != “bar” + “foo” there are valid non-commutative additions.
  - karmakaze 8y ago
    and is also a good reason to use a different operator for it too such as & or. and even space in some languages.
    - hprotagonist 8y ago
      in the specific case of strings, my preferred way to spell that in python is f”{'foo'}{'bar'}”
  - edflsafoiewq 8y ago
    An interesting example is C's pointer-integer addition. p + n == n + p, true, but this is a purely syntactic fact. The actual semantic question of commutativity, whether switching the order of the arguments leaves the value unchanged, cannot even be asked of pointer-integer addition since the arguments, having differing types, cannot be switched.
    - hcs 8y ago
      Indeed in C even array[index] is equivalent to index[array], just in case you want to be confusing.
platz 8y ago
> formulas written using operators are more easily processed visually has something to do with it: they engage the brain's visual processing machinery, which operates largely subconsciously, and tells the conscious part what it sees (e.g. "chair" rather than "pieces of wood joined together"). This is why I prefer ML-style syntax over Algol-style syntax. ML-style syntax (with sugar for pattern matching) engages my visual process machinery better, such that I can scan over function definitions more at a glance, than the "literary" style of Algol syntax
rzwitserloot 8y ago
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 << somestring` and the like). Also, the language complexity is considerable, given that you need to solve the `5 + Complex(2, 3)` problem. 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.
- Sharlin 8y ago
  > 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. Or the way C++ handles this: being able to define operators as free functions (though you could alternatively define an implicit conversion).
etaioinshrdlu 8y ago
See also: Notation as a tool of thought, the paper introducing APL: http://www.eecg.toronto.edu/~jzhu/csc326/readings/iverson.pdf http://www.eecg.toronto.edu/~jzhu/csc326/readings/iverson.pd...
tolmasky 8y ago
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.
FPGAhacker 8y ago
Seems like it's more an argument and prefix notation vs infix. z = Add(x,y) is just a form of prefix notation in my opinion. I would say that z = x + y feels better because that's how we are taught in school. But in English at least, it's reasonable to say the following: Z is X plus Y. To get Z, Add X and Y. --- It's also an argument about inconsistent syntax. For example there is not a big gap in lisp for (+ a b) and (add a b). It's a bigger difference in python. --- I find infix for math easier to read because it's how I learned it. But I also use lisp, and appreciate being able to say (+ x y) and (+ x y z a b c) where plus might be more accurately read as sum. That and in college I used an RPN calculator, and going from postfix to prefix isn't as odd as infix to prefix.
- hanniabu 8y ago
  It'd come down to context for me. If it's 2 or maybe 3 items then I'd prefer x + y, but if it's any more than that I'd definitely use Add().
tracker1 8y ago
I have to admit... I half expected an article on why Phone Operators are useful, say as opposed to annoying IVR systems.
enriquto 8y ago
I'm amazed (and horrified) how come such an intelligent mathematician and designer of a beautiful programming language made such an obvious fuckup of using a commutative operator for string concatenation. Really, I hate python just for this single idiotic notation. I mean, it's right there in front of your eyes. He talks about the convenience of using a visually commutative operator like "+" for commutative operations, and then a few lines later he says that it is a convenient notation for string concatenation. What. The. Fuck.
- _cs2017_ 8y ago
  I understand the confusion it may cause to a new Python developer who comes from the mathematical background. Does it cause any problems beyond that? For example, does it interfere with some elegant patterns, or result in some bug prone code, etc? FWIW, the single main annoyance I've had with python was its treatment of strings as iterables of single character strings. While not wrong in any obvious theoretical sense, it conflicts with the mental model of many developers (both new and experienced) and has probably caused more bugs than any other feature of Python (and even more ugly type checks to avoid such bugs). When people realized it was a problem and discussed removing this feature, Guido said he had tried but (a) it was too much work and (b) he felt the benefits are too great to give up (https://mail.python.org/pipermail/python-3000/2006-April/000824.html https://mail.python.org/pipermail/python-3000/2006-April/000...).
  - zdkl 8y ago
    > strings as iterables of single character While it makes sense to think of them as sequences, this has bitten me more than I care to admit. OT: Is there a name for things we love to complain about, but wouldn't change?
  - falcor84 8y ago
    Yeah, it was a great mind-blown moment for me when I discovered that accessing the first character is idempotent in Python: s[0] == s[0][0][0][0]
  - enriquto 8y ago
nicoburns 8y ago
JavaScript deals with this well. The equivalent of the proposed d3 = d1 + d2 is let d3 = {...d1, ...d2}; In fact, it seems like you can already do this in python: d3 = {**d1, **d2} This seems to have most of the benefits of being a dedicated syntax (rather than just a function call), without the downsides of breaking the commutativity of the + operator.
- emmelaich 8y ago
  Requires Python3
  - nicoburns 8y ago
    Surely any new syntax (like +) would also require python3, so that's a bit of a moot point...
    - emmelaich 8y ago
      Yeah, but I didn't know it was new syntax. And presumably some others didn't either.
- js2 8y ago
  From https://www.python.org/dev/peps/pep-0584/#current-alternatives https://www.python.org/dev/peps/pep-0584/#current-alternativ... > To create a new dict containing the merged items of two (or more) dicts, one can currently write: {**d1, **d2} > but this is neither obvious nor easily discoverable. It is only guaranteed to work if the keys are all strings. If the keys are not strings, it currently works in CPython, but it may not work with other implementations, or future versions of CPython. > It is also limited to returning a built-in dict, not a subclass, unless re-written as MyDict(d1, d2), in which case non-string keys will raise TypeError.
Sniffnoy 8y ago
Non-mobile link: https://neopythonic.blogspot.com/2019/03/why-operators-are-useful.html https://neopythonic.blogspot.com/2019/03/why-operators-are-u...

178 points by s16h 8y ago

j88439h84 8y ago

Python already has an 'operator' for combining dicts. d = {d1, d2}

ploxiln 8y ago
just have to avoid HN italic syntax thing, but yes: d = {**d1, **d2}
- j88439h84 8y ago
  Heh, thanks :)
deleted 8y ago
[deleted]

phoe-krk 8y ago

This is much less confusing than (2), and leads to the observation that the parentheses are redundant, so now we can write "x + y + z" This is a non-problem if you're using Lisp. (+ x y z) accepts an arbitary number of arguments and the operator precedence problem does not exist since there is no operator precedence.

hjk05 8y ago
Try writing out typical mathematical formula derivations using only s-expressions. I tried for a period and abandoned the persuit. It’s just not comparable to established mathematical notation.
- michaelmrose 8y ago
  Two solutions. Threading macros wherein instead of nested parens like (x (y (z))) one writes ((->> z) y x) In clojure there is an interesting package https://github.com/rplevy/swiss-arrows https://github.com/rplevy/swiss-arrows which allows one to perform successive operations with explicit placement of the result of prior evaluation by placing a <> in the form ((->> (z <>)) (y <> 7) (x <>)) In practice it seems like there is often less need to do so as many similar functions or the same variety have the same ordering and other options like as-> exist too. There is also the idea of processing math expressions infix as expected when desired. https://github.com/rm-hull/infix https://github.com/rm-hull/infix ($= 3 + 5 * 8) ; => 43
- ken 8y ago
  The Lisp community has literally tried exactly this, on and off, for the past half century -- and they always come back to s-expressions. Every new Lisp programmers says "I know, I'll make a macro to let me write infix math!", and then abandons it 2 months later. It's not like Lisp programmers aren't aware of how schoolchildren write (+ 2 2). I've written tons of code in both language families. In infix/prefix (i.e., Algol-family) languages, I frequently wish for a nice consistent prefix syntax. In prefix-only (i.e., Lisp-family) languages, I can't say I've ever wished for infix notation. I don't understand what the perceived issue is with infix notation, except for unfamiliarity -- and that passes soon enough.
platz 8y ago
So you trade simplicity in one problem (precedence) and gain complexity in another (variadic arguments and (lang-dependent) multiple variadic function implementations)
- bjoli 8y ago
  You don't have to make your functions variadic, it is just handy when working with numbers.
QuadrupleA 8y ago
Lisp is pretty ugly :) (eql (* x (+ y z)) (+ (* x y) (* x z))) I wonder if its famed sense of enlightenment is partly just overcoming the mental hurdle of it's syntax. Edit: typo fix, had x/z mixed up
- explainplease 8y ago
  You don't have to do it like that. You could do: (= (* x (+ y z)) (+ (* x z) (* y z))) Or: (= (* x (+ y z)) (+ (* x z) (* y z))) Or: (= (* x (+ y z)) (+ (* x z) (* y z))) Or: (= (+ (* x z) (* y z)) (* x (+ y z))) Or: (= (+ (* x z) (* y z)) (* (+ y z) x)) Or: (= (+ (* x z) (* y z)) (* (+ y z) x)) I think the last one makes the relationships quite clear. Writing legible equations is an art form, as is writing sexps. Edit: If you think lisp is ugly, compare with regexps. For bonus points, explore writing regexps with lisp, e.g. with Emacs's `rx` macro. I think you won't find a more easily maintainable way to write them.
  - chongli 8y ago
    Some would argue that the fact that you have all of those alternative forms is part of the problem. Lisp is one of the (if not the) most individualistic programming languages around. Lisp makes it easy for a programmer to create their very own impenetrable, arcane, domain specific languages. This causes large organizations to avoid it like the plague. Large teams don't want artists, they want replaceable parts.
    - dorfsmay 8y ago
      Are you talking about macro or formatting? If it's about formatting, given that this is what this thread is about, you can use code formatter for lisp languages exactly like for any other language, in fact they are even easier to write for lisp because of the consistency of S expressions. If you are talking about macro, then you're in the same boat as other languages that have macros, C, Rust, ect... And remember that the first rule of macros is to not use macros, except for when you absolutely have to, and in those cases it is the most elegant solution. If you have devs inventing DSLs for everything, then lisp isn't your problem.
ghettoimp 8y ago
Yup. In addition to ignoring the usual Lisp convention for associative operators, I think the article muddies the waters here by using words like "add" and "mul" in all of the non-infix examples, making them unnecessarily verbose. After using prefix notation for years, it seems very natural for pattern recognition and formula manipulation. Never having to think about precedence and associativity is really nice.
mannykannot 8y ago
If this is so obviously preferable, why have mathematicians so obdurately not adopted this style? Mathematical notation is not an archaic practice that is followed out of a respect for tradition, or a doctrine that has been developed from first principles, it is something that has evolved (and continues to do so) because it has been useful.
- bobbylarrybobby 8y ago
  Well mathematics notation largely follows speech. People say “one plus two” — largely because speech doesn’t have closing parentheses, so we need to speak in a way that makes it clear when we’re done talking — so that’s how we write it. But for a computer, prefix notation is great because it’s unambiguous and clear even without knowledge of PEMDAS. Similar to how Americans write MM/DD/YYYY because that’s how we say dates, but we can still acknowledge that YYYY-MM-DD is the best format for computers.
  - improbable22 8y ago
    I wonder how much is the reverse: we now tend to say mathematical expressions as they are written, but before this was standardised, you would just explain the steps. Probably not "one plus two" -- I think + is essentially a variant of & which is a ligature for "et", and I guess most languages put "and" between the things being combined. But I'd be surprised if (x/y)^2 was said "x over y all squared" by many people before this notation. But the notation is clearly more designed for thinking on paper than for explaining down a phone line.
- newen 8y ago
  Mathematics uses infix notation literally everywhere. Just because you prefer some notation doesn't mean people who have used infix notation since they were 5 years old will like it. Also, I avoid lisp mostly because S-expressions are almost unreadable to me.
  - dragonwriter 8y ago
    > Mathematics uses infix notation literally everywhere. Mathematics uses prefix, infix, suffix, circumfix, and some more complex notations; basically any pattern any computer language uses probably is inspired from math even if math doesn't use the notation for the same operation or operator symbol.
Rexxar 8y ago
This is a non-problem in every language with variadic functions. "add(x, y, z)" looks good to me.
- dnautics 8y ago
  You have to be careful though. In Julia, there is "fma(a,b,c)" which is not necessarily the same as "muladd(a,b,c)". What are the guarantees on add(a,b,c) versus a+b+c? If do add(1.0e30, 1.0, -1.0e30) is that the same (aka IEEE fp addition is noncommutative)
  - alboy 8y ago
    > If do add(1.0e30, 1.0, -1.0e30) is that the same (aka IEEE fp addition is noncommutative) You might be thinking of associativity. Both addition and multiplication are commutative up to NaN.
mturmon 8y ago
Your comment is begging the question. The reason that Lisp “+” can accept a list of arbitrary length, rather than a pair, is that the underlying addition operator is associative.
- ehaliewicz2 8y ago
  Not true. Division isn't associative and you can do e.g. (/ 12 6 3)
  - mturmon 8y ago
    This is true - Lisp is making / left-associative. But this observation does not change my point: that the parent comment is saying "Lisp already has the ability to do + on lists", but the reason "+ on lists" makes sense is because Lisp is using the underlying associativity of mathematical +. And the latter associativity property, for abstract mathematical "+", is what the blog post is describing/exploring.
    - kazinator 8y ago
      The computing + is not associative for inexact types like floating-point. That's why it's important for the Lisp + to be consistently left-associative; the result could vary if that were left to the implementation to do however it wants. In addition/relation to floating-point, another way in which addition is not associative in computing is if there are type conversions. (+ 1 1 0.1) is not the same as (+ 1 (+ 1 0.1)). The former will do an integer addition to produce 2, and then that is coerced to 2.0 which is added to 0.1. The latter adds 1.0 to 0.1, and then adds that to 1.0: two floating-point additions. In languages that don't have bignums (which could include some Lisp dialects) whether overflows occur can depend on the order of operations, even when all operands are integers. The reason we can have a n-ary + is that three or more arguments can be decimated through a binary +. The concept of + is defined as a binary operation. Lisps have variadic functions that are blatantly non-associative, like, oh, list. (list 1 2 3) isn't (list 2 3 1).

Symmetry 8y ago

Operators can certainly be nice. And I do like allowing the programmer to create new ones too, though I'd tend to prefer the Haskell approach of creating new ones out of existing symbols like >< or such rather than the C++ approach of letting the programmer redefine an existing operator for a new use, << in the streams library being one of the worst common examples.

duckerude 8y ago
Python discourages using operators for things that don't have anything to do with their original use. If you try to be too clever with it, you run into issues. For instance, comparison operators are chained, so that `x > y > z` is equivalent to `x > y and y > z`, not `(x > y) > z`. The most radical use of operators in the standard library that I know of is in pathlib, where `Path('/usr') / 'lib' == Path('/usr/lib')`, and I think that got a lot of pushback. It's certainly an outlier. It fits well with Python's overall approach to readability. If the meaning of your operator isn't immediately apparent from its existing meanings, then it should probably just be a regular old named function or method instead. Python doesn't like DSLs very much. Programmer-defined operators are certainly useful, but Python went in the other direction, which has its own advantages. C++'s choice to have a fixed set of operators but overload them in a lot of arbitrary ways is probably the worst of both worlds.
- zwkrt 8y ago
  You should look at the Construct library, which overloads the '/' operator as syntactic sugar to make s-expressions in it's DSL less paren-heavy. I'm not saying I agree, but it was wild when I first saw it. Struct( "foo" / byte, "bar" / Struct( "spam" / int16ul, "bacon" / int64sb, ), "viking" / int32sl, )
- VWWHFSfQ 8y ago
  > Python discourages using operators for things that don't have anything to do with their original use. Python doesn't really discourage anything and especially not overloading operators in weird ways. You even pointed out the pathlib insanity in the stdlib. Python isn't the shiny bastion of consistency and obviousness that the zen claimed it was years ago

nikofeyn 8y ago

he doesn’t make any coherent argument as to why one is more clear or preferred than the other. he simply states it and moves on with this bias. for example, when he compares 2 to 2a, i feel he doesn’t really address anything and just states his preference as the more clear one. plus, he of course seems to know nothing about lisp (or just ignores it) where you might have: (+ a (+ b c)) = (+ (+ a b) c) = (+ a b c) all three are valid lisp syntax and represent associativity of addition well, including “dropping the parentheses”. the thing is, procedure notation as opposed to infix operators actually make it more explicit by what is meant by associativity. this is because it makes explicit about what comes first because of how procedures are evaluated. this is much more explicit than conventions of what parentheses mean in infix operator expressions. even his python procedure example in (2) demonstrates this property. the distributive law is: (* a (+ b c)) = (+ (* a b) (* a c)) that seems pretty clear to me. and with this, you can of course extend the language such that the +, , etc. procedures operate on new data types or heterogeneous data types like ( c v) where c is a constant and v is a vector and you get scalar multiplication. it is also funny to me that he considers readability over performance. well, i do too, but you can have both. see lisps, schemes, and sml dialects, all languages he seems to ignore the existence of. another thought is that i recall gerald sussman saying in a talk that mathematical notation is impressionistic, and in general, i think he is right. his point was that procedure notation is much more explicit. he also mentions that prefix notation is inconvient for small expressions versus infix notation but is much more preferred when you have very large expressions with many, many terms.

redleggedfrog 8y ago
Isn't "...once you've learned this simple notation, equations written using them are easier to manipulate than equations written using functional notation..." his argument why operators are more clear? I don't necessarily agree with that, but I haven't made a world class programming language, either. I just assume he knows something I don't.
- nikofeyn 8y ago
  but programming isn’t about manipulating equations. if you want programs to manipulate equations, then again, the procedure notation, in particular lisp notation, wins out.

wiremine 8y ago

> Of course, it's definitely possible to overdo this -- then you get Perl. 100% agree. I actually really like Perl, but in practice this makes Perl programs more difficult to maintain than they should be. Also: seems like this XKCD is appropriate here: https://xkcd.com/224/ https://xkcd.com/224/

raiph 8y ago
Forgive me as I use similarly extreme language. I 100% disagree. Imo Guido's throwaway comment uses the same rhetorical form as hate speech. Your use of "100% agree" and "I actually really like Perl" are mutually contradictory. Now let me unpack that. I'm curious to see if you reply and whether we arrive at middle ground. ================================================= > in practice [Perl's use of operators] makes Perl programs more difficult to maintain than they should be This is an old saw but do you agree that it is a misstatement of what's actually going on: * Some Perl programmers, especially experienced ones, have made and continue to make Perl programs, including large ones, EASIER to maintain than they could be and would be if written by a similarly strong programmer using the deliberately dumbed down language Python. * Some Perl programmers, especially beginners, have made and/or continue to make Perl programs, mostly small ones, more difficult to maintain than they should be and would be if written by a similarly weak programmer using a deliberately dumbed down language like Python. Perhaps your response to that is something like "Oh sure, I just meant most programs I see because they're mostly small and written by inexperienced programmers." If not, how modern are the Perl programs of which you speak? Much has changed since 2000 and especially in the 2010s: Perl 5 has stabilized around a wise view of the language, interpreter, and how to be respectful of each others' failings; Perl 6 has radically dialed back the complicated built in availability of terribly cryptic symbol aliases as part of a complete rethink of what it means to be a Perl language. ================================================ As for the "hate speech" aspect: >> Of course, it's definitely possible to overdo this -- then you get Perl. > That's the Guido we know and love. The above was the entirety of by far the highest voted comment in the python reddit post about this article. I posted the following in sardonic response, which also got upvoted: Guido: > Once you've internalized the simple properties which operators tend to have, using + for string or list concatenation becomes more readable than a pure OO notation, and (2) and (3) above explain (in part) why that is. Larry: > But it contradicts property (1). That's (in part) why I did not use + for string and list concatenation in Perls. Then again I used it for adding floats, even though that contradicts property (1) too. And changed my mind about what symbol to use between Perl 5 and Perl 6. Heck, who cares about consistency? Guido: > I care. I consistently hate on Perl and Python users consistently love me doing so. I generally find Guido's and the Python community's intolerant attitude consistent with the above and with this exchange about the same article on twitter: > Random nit: you've got a "font-size: 85%" in the CSS for your posts. Mind removing that, so those of us with our default font-size set deliberately don't have to squint? Guido: > I'm sorry, I have no interest in CSS hacking. The template is what it is. Deal with it. Guido's riposte also got lots of hearts (presumably to soothe or applaud their beloved ex-BDFL). I note the follow up got nothing from Guido: > It's a single-line deletion, and would improve the accessibility of your blog, but sure ok. There's zero chance Larry would have thought and spoken as Guido did and he absolutely would have made that single line deletion out of respect for the person whose eyesight wasn't as good as others'. The same attitude applies to improving the language and culture. ================================================== How familiar are you with current Perl activity? I see a new Perl emerging, one that will unfold throughout the 2020s. I see a well entrenched self-reinforcing tolerant attitude in Perl culture, even of those who like to use too many operators for my liking.

0815test 8y ago

The mnemonic value of "operators" as reminders of properties such as associativity or commutativity interestingly extends to diagrammatic reasoning. A diagram is really just a generalized expression, and this becomes quite useful when one has to deal with more than one "type" or "domain" of operation, but in a consistent way that preserves the compositionality-like properties OP talks about. A recent book exploring this topic is "Seven Sketches in Compositionality; An Invitation to Applied Category Theory" https://arxiv.org/abs/1803.05316 https://arxiv.org/abs/1803.05316 . (Despite the obvious reference to CT in the title, the work is quite accessible and the math involved is not much more complicated than that found in the linked blogpost. Importantly, and perhaps unlike some people in other programming-language communities, the author does not assume any pre-existing knowledge; the work is rather about using concrete, real-world examples to gently guide the reader's intuition.)

mpweiher 8y ago

Smalltalk also doesn't have this problem. Since all message-sends are essentially infix, operators (binary message sends) are simply special keyword messages. 1 add: 2. 1 + 2. This is helpful when you have "operators" that aren't quite as obvious, for example raising to a power. 2 raisedTo:3. Since there are no operators, there is no operator precedence. However, there is precedence between different message types: unary binds tightest, then binary, keyword last. Otherwise evaluation is uniformly left to right. While this is a question on Smalltalk job interviews ( What is 2 + 3 * 5. ?), that's only useful for filtering out people who simply have never seen Smalltalk before (in case they claim knowledge). It doesn't seem to be an issue in practice, because the evaluation rules are otherwise so simple and uniform. The other surprising effect is that binary message sends don't seem to have the same tendency to be confusing that operator overloading does. I don't really understand this effect, because the mechanism has effectively the same power.

makecheck 8y ago

A “dict” operator would be vague because there is more than one way to combine dictionaries. Why should I have to guess whether duplicate keys are being skipped or replaced by a symbol, when two different well-named functions will always make it clear?

sametmax 8y ago
Same with lists and strings, and it doesn't bother anybody: even for dict, it's just a matter or reading from the left to the right.
- makecheck 8y ago
  Of course it’s not the same. There is one sensible result expected when adding two lists or strings together (since they’re linear, it would not make sense to encourage inefficient search/replace operations with an operator; and also, the containers do not require unique keys, you can simply extend them). A dict must deal with conflicting keys, and arguably each situation requires different treatment of those keys.
  - pacala 8y ago
    The sensible thing is to throw on conflicting keys.
    - deleted 8y ago
      [deleted]
    - JoelMcCracken 8y ago
      What? Have you never had two dicts and wanted vals from one dict override the other?
      - vivekseth 8y ago
        If a+b != b+a that breaks the commutativity property of addition.

rossdavidh 8y ago

Wow, he's still got it. I read the whole thing, without realizing it was Guido Rossum, thinking "hey, that's a really good point". Then got to the end and realized it was the inventor of the Python language. So, I wasn't impressed as I was reading it because of who it was, I was impressed because he was making a really good point. Obviously, the fact that he made my favorite programming language was no fluke.

maskedinvader 8y ago
Ramblings through technology, politics, culture and philosophy by the creator of the Python programming language. This was literally the first thing I read when I hit the link. Don't mean to sound rude but how did you miss that ? Does it render differently on web? I saw this on the mobile version of the site on my Android.
- ChrisSD 8y ago
  For me that was covered up by some popover I didn't read. Besides the tagline of a blog is the sort of thing I for one gloss over. I've had decades of training how to skip straight to the content.
  - maskedinvader 8y ago
    That's what I thought, usually even I am trained to skip those few lines under titles (like opinion articles have a blurb about the author )
  - rossdavidh 8y ago
    Yeah, that's me exactly.
- ruanmed 8y ago
  I don't know why, but I did the same thing. I read the post content first, then after finished I went backup and saw the blog title and subtitle. Or I could say my brain was only conscious to reading the blog title and subtitle afterwards.

karmakaze 8y ago

The dict example given is exactly why operators wouldn't be useful to me. Presumably d1 + d2 != d2 + d1 for some d1, d2. If you're going to use the + operator then it should behave like it does in other contexts.

hprotagonist 8y ago
this is equally untrue true for strings, of course. “foo”+”bar” != “bar” + “foo” there are valid non-commutative additions.
- karmakaze 8y ago
  and is also a good reason to use a different operator for it too such as & or. and even space in some languages.
  - hprotagonist 8y ago
    in the specific case of strings, my preferred way to spell that in python is f”{'foo'}{'bar'}”
- edflsafoiewq 8y ago
  An interesting example is C's pointer-integer addition. p + n == n + p, true, but this is a purely syntactic fact. The actual semantic question of commutativity, whether switching the order of the arguments leaves the value unchanged, cannot even be asked of pointer-integer addition since the arguments, having differing types, cannot be switched.
  - hcs 8y ago
    Indeed in C even array[index] is equivalent to index[array], just in case you want to be confusing.

platz 8y ago

> formulas written using operators are more easily processed visually has something to do with it: they engage the brain's visual processing machinery, which operates largely subconsciously, and tells the conscious part what it sees (e.g. "chair" rather than "pieces of wood joined together"). This is why I prefer ML-style syntax over Algol-style syntax. ML-style syntax (with sugar for pattern matching) engages my visual process machinery better, such that I can scan over function definitions more at a glance, than the "literary" style of Algol syntax

rzwitserloot 8y ago

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 << somestring` and the like). Also, the language complexity is considerable, given that you need to solve the `5 + Complex(2, 3)` problem. 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.

Sharlin 8y ago
> 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. Or the way C++ handles this: being able to define operators as free functions (though you could alternatively define an implicit conversion).

etaioinshrdlu 8y ago

See also: Notation as a tool of thought, the paper introducing APL: http://www.eecg.toronto.edu/~jzhu/csc326/readings/iverson.pdf http://www.eecg.toronto.edu/~jzhu/csc326/readings/iverson.pd...

tolmasky 8y ago

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.

FPGAhacker 8y ago

Seems like it's more an argument and prefix notation vs infix. z = Add(x,y) is just a form of prefix notation in my opinion. I would say that z = x + y feels better because that's how we are taught in school. But in English at least, it's reasonable to say the following: Z is X plus Y. To get Z, Add X and Y. --- It's also an argument about inconsistent syntax. For example there is not a big gap in lisp for (+ a b) and (add a b). It's a bigger difference in python. --- I find infix for math easier to read because it's how I learned it. But I also use lisp, and appreciate being able to say (+ x y) and (+ x y z a b c) where plus might be more accurately read as sum. That and in college I used an RPN calculator, and going from postfix to prefix isn't as odd as infix to prefix.

hanniabu 8y ago
It'd come down to context for me. If it's 2 or maybe 3 items then I'd prefer x + y, but if it's any more than that I'd definitely use Add().

tracker1 8y ago

I have to admit... I half expected an article on why Phone Operators are useful, say as opposed to annoying IVR systems.

enriquto 8y ago

I'm amazed (and horrified) how come such an intelligent mathematician and designer of a beautiful programming language made such an obvious fuckup of using a commutative operator for string concatenation. Really, I hate python just for this single idiotic notation. I mean, it's right there in front of your eyes. He talks about the convenience of using a visually commutative operator like "+" for commutative operations, and then a few lines later he says that it is a convenient notation for string concatenation. What. The. Fuck.

_cs2017_ 8y ago
I understand the confusion it may cause to a new Python developer who comes from the mathematical background. Does it cause any problems beyond that? For example, does it interfere with some elegant patterns, or result in some bug prone code, etc? FWIW, the single main annoyance I've had with python was its treatment of strings as iterables of single character strings. While not wrong in any obvious theoretical sense, it conflicts with the mental model of many developers (both new and experienced) and has probably caused more bugs than any other feature of Python (and even more ugly type checks to avoid such bugs). When people realized it was a problem and discussed removing this feature, Guido said he had tried but (a) it was too much work and (b) he felt the benefits are too great to give up (https://mail.python.org/pipermail/python-3000/2006-April/000824.html https://mail.python.org/pipermail/python-3000/2006-April/000...).
- zdkl 8y ago
  > strings as iterables of single character While it makes sense to think of them as sequences, this has bitten me more than I care to admit. OT: Is there a name for things we love to complain about, but wouldn't change?
- falcor84 8y ago
  Yeah, it was a great mind-blown moment for me when I discovered that accessing the first character is idempotent in Python: s[0] == s[0][0][0][0]
- enriquto 8y ago

nicoburns 8y ago

JavaScript deals with this well. The equivalent of the proposed d3 = d1 + d2 is let d3 = {...d1, ...d2}; In fact, it seems like you can already do this in python: d3 = {**d1, **d2} This seems to have most of the benefits of being a dedicated syntax (rather than just a function call), without the downsides of breaking the commutativity of the + operator.

emmelaich 8y ago
Requires Python3
- nicoburns 8y ago
  Surely any new syntax (like +) would also require python3, so that's a bit of a moot point...
  - emmelaich 8y ago
    Yeah, but I didn't know it was new syntax. And presumably some others didn't either.
js2 8y ago
From https://www.python.org/dev/peps/pep-0584/#current-alternatives https://www.python.org/dev/peps/pep-0584/#current-alternativ... > To create a new dict containing the merged items of two (or more) dicts, one can currently write: {**d1, **d2} > but this is neither obvious nor easily discoverable. It is only guaranteed to work if the keys are all strings. If the keys are not strings, it currently works in CPython, but it may not work with other implementations, or future versions of CPython. > It is also limited to returning a built-in dict, not a subclass, unless re-written as MyDict(d1, d2), in which case non-string keys will raise TypeError.

Sniffnoy 8y ago

Non-mobile link: https://neopythonic.blogspot.com/2019/03/why-operators-are-useful.html https://neopythonic.blogspot.com/2019/03/why-operators-are-u...