81–90 of 173 posts
Earlier quoted context omitted.
What? Have you never had two dicts and wanted vals from one dict override the other?
If a+b != b+a that breaks the commutativity property of addition.
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.
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.
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.
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.
Further there is no reason to suppose that any group of humans act optimally in this area when they clearly act on the whole so illogically and sub optimally in every other area of human endeavor.
It asks respondents to prove the much more complex question of why different groups may prefer a particular notation instead of taking the much more simple and direct route of explaining why the poster prefers a particular notation.
In short its not a missile its chaff.
Python already has an 'operator' for combining dicts. d = { d1, d2}
Earlier quoted context omitted.
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.
The sensible thing is to throw on conflicting keys.
1) I either want them to be overridden or not. The current .update can do both, you just put the dict you don't want to override as its argument
2) finding common keys is a different problem, which can be solved in a different way
So no, throwing an exception is just completely useless and won't make any of the common cases easier
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.
Earlier quoted context omitted.
this is equally untrue true for strings, of course. “foo”+”bar” != “bar” + “foo” there are valid non-commutative additions.
and is also a good reason to use a different operator for it too such as & or. and even space in some languages.
f”{'foo'}{'bar'}”