Is it? It's easier to code an evaluator, but I'm not convinced it's necessarily more intuitive. In practice, only addition/subtraction and multiplication/division are ambiguous. I'll also play devil's advocate and admit order of precedence is somewhat arbitrary, and precedence of bitwise and and equality is wrong in most languages. Not sure why I'd want this: (flags & (4 == 4)), but that's what flags & 4 == 4 does.
One difference is you see all intermediate results. That's huge for avoiding mistakes. In-fix, if you type (5+5)*(9+9), you only see the end result. Post-fix 5 5 + 9 9 + *, you see 10 and 18 along the way.
Another is the stack lets you easily reuse subresults. If you've computed the total energy and want to use it three places, you pick it off of the stack. All your work is there. It's very common that this happens.
It's an incredible productivity boost once you get used to it.
It gets even better when you tag numbers with the correct units. The calculator does type checking and automatic unit conversions. So if you key in the wrong operations, you'll either get an error somewhere along the way (from eg. trying to add something in m/s to something in m/2^2) or you'll notice the units at the end of the calculation don't match what you're supposed to end up with.
For general purpose programming, I want to write expressions in algebraic format but for interacting with a calculator RPN is easier. It removes a whole layer of abstraction wondering what the machine is doing.
I would imagine if I were young today and started with a modern multi line calculator with textbook display then that is what I would be comfortable with but for folks born before 1980 or so the algebraic calculators of our time were error prone.
I have an HP 27S that is algebraic and breaks the mold of being error prone because it shows the whole expression up until the point where a part can be evaluated. Then it evaluates the inner part while still showing the rest of the expression.
> Not sure why I'd want this: (flags & (4 == 4)), but that's what flags & 4 == 4 does.
Originally there was no && operator. You had to use & for Boolean conjunction too. The precedence makes sense under that condition. (And later couldn't be changed without breaking existing code.)
Is it? It's easier to code an evaluator, but I'm not convinced it's necessarily more intuitive. In practice, only addition/subtraction and multiplication/division are ambiguous. I'll also play devil's advocate and admit order of precedence is somewhat arbitrary, and precedence of bitwise and and equality is wrong in most languages. Not sure why I'd want this: (flags & (4 == 4)), but that's what flags & 4 == 4 does.