31–40 of 173 posts
Obviously, the fact that he made my favorite programming language was no fluke.
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.
Earlier quoted context omitted.
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. Ed…
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.
This is true for a lot of "frameworks" and especially true for modern fontend web frameworks (which have a compile/build step).
Earlier quoted context omitted.
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.
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.
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?
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?
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.
How's that? There's no defined "left to right" for a dict.
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.
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.
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.
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…
This is unnecessary and a huge stretch given one blog post.
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.