61–70 of 173 posts
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.
> 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.
Earlier quoted context omitted.
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.
We do have f(x, y) in mathematics notation, as well as notations like { a, b, c }, ( 1, 2 ). The inventor of vector and matrix notation finally had the brilliant idea of dropping the silly commas [ i j k ]. Think of how ugly matrices would look with commas. Now in mathematics, there is no equivalent of a 200,000 line piece of software. The number of identifiers a mathematician works with in any given work is small, e…
Calling people’s use of LaTeX to type their homework “professional typesetting” seems like a stretch. Professional typesetting would be something like: send your hand-written manuscript to a full-time typesetter, and wait for them to do the work.
A better description would be “goes to the trouble of using math typesetting software designed by experts”. But is this really so strange? People use even more sophisticated software than that for making image collages of cats with mustaches, for modeling platonic solids, for adding their favorite song to a frivolous home movie, ....
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…
> `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).
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.
d = {d1, d2}
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.
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.
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.
this is equally untrue true for strings, of course. “foo”+”bar” != “bar” + “foo” there are valid non-commutative additions.
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…
+(x::Real, z::Complex) = Complex(x + real(z), imag(z))
+(z::Complex, x::Real) = Complex(x + real(z), imag(z))
And you can call it in both infix or prefix forms. Though Julia is a math focused language and the community tries to stay consistent with the correct notation. You can't add an element to a list using the "+" operator, but you can add each element of two lists if their dimensions match.
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.
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.
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.
So you trade simplicity in one problem (precedence) and gain complexity in another (variadic arguments and (lang-dependent) multiple variadic function implementations)