Yeah, RPN is essentially what you'd get as output if you compiled LISP using a compiler. Claiming RPN is as easy to deal with as LISP would be utterly absurd, and no one genuinely believes that.
Well, RPN with parentheses, as a layer of syntax, would be easy to deal with. That's what Lisp backwards would be.
((a b +) (a b) defun)
(((list pop) print) list while)Yeah, the Japanese incorrectly put verbs at the end of the sentence! Just like Yoda does. Asian he must be. Incorrect they all are.
But seriously, yeah computers are naturally 'Stack Machines' [almost] always, where they need the arguments pushed onto a stack before the 'verb' is executed.
Even if we don't think about stacks, but just the raw data dependency: before we can perform an operation, we need to determine its operands.
So if we translate that sequence to language, stating the operands before the operation does follow the non-negotiable evaluation data flow.
That's why we have interpreters and compilers: So we can make code easier to read. FORTRAN was originally invented as a way to let humans think in terms of parenthetical groupings for math and functions, specifically to _avoid_ reasoning in an RPN way.
What programming systems used RPN prior to 1957?
Think about it: the entire class of error of mismatched stack height doesn't exist in Lisps.
There could be an operand stack, if the Lisp is translated to a stack-based byte code; but it's managed so the programmer isn't concerned about it.