----
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.
Only if in see-full-expression-before-action mode. Otherwise you would see 10 after the first ), and see 18 after the second ).
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.
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.)
Even with its lowly Saturn CPU and perceptually slower, it was trouncing the TIs at basically every task, especially when you customised it.
I learned RPN and RPL alright, but also got to dive into System RPL: the low level, faster, much more rich RPL, but where every argument was basically unchecked as it was more like HP-provided ASM routines in disguise.
And then learned to bit-bang stuff on the screen in assembly with all the timing tricks to produce 4 grayscale instead of just black/white. Great for coding small games.
Got the the third party CAS algebra extension card that also replaced the original UI for the same thing, only faster and better, and with a much more potent symbolic solver, whose UI was absolutely glorious to write, select, navigate, and perform advanced stuff.
Also got a maxed out storage expansion for the second slot. Such storage was not solid state so it required a continuously operating CR2032 battery to persist over time.
Unfortunately, as robust as it was, some time after engineering school it took a hard fall too much and was irreparably broken.
Later got my hand on a HP49G+, ARM powered but surprisingly the default was to run an emulation of the Saturn CPU, and CAS was bundled. You could still code for the ARM one though. By that time I lost interest so it currently sits in a drawer. Also preferred the 48 boxy design, especially the mushy keys of the new one were way worse.
Sadly my collection of HP and other RPN calculators (there are a few) was stolen two years ago.
If you're using "algebraic", you sometimes have to put a "(" into your expression a long way ahead of when you need it. Think of how many times you have to go and fix up your left parens when writing C code conditionals. On a calculator, if you screw up, go back to start. Also, old calculators had parentheses limits.
"Modern" algebraic calculators mitigate this somewhat because they can enter the expression in text form on a dot matrix LCD so you can go back and add/delete parentheses as required.
An explicit stack means that I can start and stop subexpression calculations at various points and cache the results. It also means that I can rearrange precedence at my convenience--of course, the flip side is that precedence is my problem instead of the calculator's.
RPN has no use for brackets, because there is never any ambiguity.