John writes:
Here's a question: is it possible to implement this with a Python module, or is that absolutely not a thing that can be done?
Yes, it can, or at least you could use MacroPy (not sure if that's pure Python, if it is then you could implement in a module using the same techniques).
This is what temp variables like ____, ________, ___________, ___, and _____ are for! Although I prefer giving them less opaque names. :-)
Helps, but does spread the information out.
That's not a problem for reading the expressions themselves -- spreading out the information into meaningful (and thus nameable) chunks is the point of the exercise. *Unless* you've got a pure functional language. In that case you could be 436k away from the beginning of the expression (that's the largest Java class I ever encountered in the wild, and boy, was it wild). I'd be more sympathetic if the issue was spreading out a suite of statements, but even then, not very. I've never encountered code that can't be understood if written in 24x80 chunks of Python, including the relevant def lines and a couple of comments. If efficiency is required (and achievable in pure Python!), inlining those functions isn't hard, although it can be tedious. Very rarely is *naming* those functions difficult. YMMV, of course, but that WFM. (Note, I don't object to the proposal, I'm purely talking about what WFM. I might object to you using it if we were working on the same project, though. Depends on circumstances. :-)
It also requires finding useful names, and there aren't always meaningful names for intermediate steps.
Then those are the "wrong" intermediate steps. If you *really* need to break there, then a meaningless name such as "__" is fine. One practical problem with RPN is that one way to break up and "mark" subexpressions *without* temporary variables is to use (physical) newlines and indentation. With infix notation (minuend # note: parentheses are idiomatic Python line - subtrahend # continuation + multiplicand * multiplier) reads well and parses easily in-brain. But in RPN you have an uncomfortable choice: put the operators at line endings (where you will *not* normally be scanning in Python because syntactic keywords generally come at the beginning of the line) or put them at the beginning of the line (requiring scanning up the page to find the operands and probably giving your brain a bit of WTF). Even a programming language with Arabic or Hebrew keywords wouldn't work well with RPN as far as I can imagine. Yes, you'd be scanning down the right margin for syntax, but the RPN operators would end up at the left margin! Or maybe in the middle of the line, depending on how you interpret "BIDI" (any comments from those fluent in a BIDI language?) Could be "just my [lack of] imagination", of course.
Interesting that people find it write-only. I find it easier to modify a complicated equation in RPN than algebraic because it's easier to find precisely the part of the calculation I need and insert the extra code.
As an applied mathematical economist, I work with obnoxiously complicated equations a lot, but always factor out subexpressions and give them names (to which the policy wonks frequently apply motivated reasoning and conclude I proved exactly what they needed, c'est la vie :-). I am not struck by reasons to dive into a complex expression and modify it. I discover reasons to modify some relevant subexpression instead. That's the way I *think* about such interative refinement processes as well as how I *implement* them (ie, typically notated as functions). Maybe that's why I work that way with Python programs, too. I don't know about your field, but in mine it's *very* unusual to encounter expressions that aren't repeated in other contexts, and therefore idiomatic ~= meaningful. Usually that subexpression is there because it implements a domain concept. If I don't have a good existing name, a neologism will do, and because the expression is an idiom, that neologism has meaning to others in my field -- from the subexpression.
I'd honestly been considering if we should have taught RPN first to give students a way to parse complicated algebraic equations by rewriting them in a less-opaque form, but quickly realized you never encounter anything more complicated than multiplying two polynomials in an educational setting.
Complicated expressions are just complicated. I don't think it really matters which way you teach. Either way you can't avoid the complexity, and either way you have to parenthesize, either with actual parentheses in the expression itself, or with increasingly long underlines. :-) (I'm laughing at myself, because I think it's true but I'm not 100% sure.) Steve