On Nov 6, 2019, at 01:46, martin_05--- via Python-ideas <python-ideas@python.org> wrote: > > > Still, the idea of two assignment operators just didn't sit well with me. > That's when I realized I had seen this kind of a problem nearly thirty years > ago, with the introduction of "J". I won't get into the details unless > someone is interested, I'll just say that J turned APL into ASCII soup. It > was and is ugly and it completely misses the point of the very reason APL has > specialized notation; the very thing Iverson highlighted in his paper [0].
J didn’t invent having multiple related operators, J was trying to fix the problems that were created by APL having multiple related operators. You may not like its solution, but then you have to come up with a different solution that at least tries to solve them. Chris already raised the typeability problem. And let’s pretend for the sake of argument that the display problem has been solved. The remaining problem is that APL had way too many different operators. Too many operators to fit into ASCII almost inherently means too many to fit into a programmer’s head (and especially a programmer who also works in other languages and comes back to APL every so often). J attempted to solve this by making much heavier and more systematic use of operator modifiers. I don’t think it was all that successful in making the language easy to keep in your head, but it was enough to inspire other languages. We have the elementwise prefix in math languages, Haskell’s banks of operators organized as if they had modifiers even though they don’t—and, best of all, the discovery that thanks to types, in many cases you don’t actually need more operators. In Python, and in C++, I can just add two arrays with plain old +, and this is almost never confusing in practice. As it turns out, you never miss having three or four complete sets of operators; at most you miss matrix multiplication (and maybe exponentiation) and a distinction between cross and dot for vectors, so we only needed to add 0 to 2 operators rather than tripling the number of operators or adding a way to modify or combine operators. And I don’t think it’s a coincidence that most array-heavy programming these days is not done in either APL or J, or even modern languages like Julia that try to incorporate their best features, but in Python and C++ (and shader languages based on C++) that completely avoided the problem rather than creating it and then trying to solve it. And that’s why := is not a crisis for Python. Python doesn’t have way too many operators, and isn’t in danger of getting anywhere near there. Python adds one or two new operators per decade, and that only if you cheat by including things like if-else and := as operators when they actually aren’t while ignoring the removal of `. And most of the operators are words rather than symbols (if-else rather than ?:, yield and await which I’m sure APL would have found symbolic ways to spell, etc.). If we keep going at the current pace, by the end of the century, we’ll have used up either $ or ` and added one more digraph and three more keywords… which is fine. While we’re at it, when you replace both = and := with an arrow, what do you do with += and the other augmented assignments? I can’t think of a single-character symbol that visually represents that meaning. If you leave it as + followed by an arrow, or try to come up with some new digraph, now we have the worst of both worlds, Unicode soup: operators that are digraphs and not visually meaningful while also not being typeable. _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/HX7ORVM4XC74ASOZ7NP3BAP6OVD43HIA/ Code of Conduct: http://python.org/psf/codeofconduct/
