> I don’t see how either of those exhibits demonstrate your point.

Natural language is easy to do for a human and a hard computing problem.

Polish notation is extremely simple to implement, but relatively "hard" for a human, even knowing the rules and how to read it. See: `+ * - 15 6 / 20 4 ^ 2 3 - + 7 8 * 3 2`

▲ chrismorgan 3 days ago | parent | next [-]

> Natural language is easy to do for a human and a hard computing problem.

You ever see someone learning a new language? They struggle hard on more complex sentences.

It’s easy for us because we’ve practised it so much.

> + * - 15 6 / 20 4 ^ 2 3 - + 7 8 * 3 2

To begin with, you’re missing an operator. I’ll assume another leading +.

  + + * - 15 6 / 20 4 ^ 2 3 - + 7 8 * 3 2

Now, if you use infix, you have to have at least some of the parentheses, in this case actually only one pair, given rules of operator precedence, associativity and commutativity:

  (15 - 6) * 20 / 4 + 2 ^ 3 + 7 + 8 - 3 * 2

But you may well just parenthesise everything, it makes solving easier:

  ((((15 - 6) * (20 / 4)) + (2 ^ 3)) + ((7 + 8) - (3 * 2)))

And you know how you go about solving it? Calculating chunks from the inside out, and replacing them with their values:

  (((    9    *     5   ) +    8   ) + (  15    -    6   ))
  ((         45           +    8   ) +          9         )
  (                      53          +          9         )
                                    62

Coming back to Polish notation—you know what? It’s exactly the same:

  (+ (+ (* (- 15 6) (/ 20 4)) (^ 2 3)) (- (+ 7 8) (* 3 2)))
  (+ (+ (* 9 5) 8) (- 15 6))
  (+ (+ 45 8) 9)
  (+ 53 9)
  62

For arithmetic at least, it’s not hard. You’re just not accustomed to it.

	▲	Arainach 3 days ago \| parent [-]
		This is a really weird hill to die on. HP tried hard to make RPN a thing and even among engineers eventually lost out to notation that is easier to work with. People read in one direction - in English left to right. They read faster and comprehend better when they can move in that direction without constantly jumping back and forth. > (15 - 6) * 20 / 4 + 2 ^ 3 + 7 + 8 - 3 * 2 (15-6)20/4 can be read as one block left to right 2^3 can be read as one block left to right. Jump back to the operator (count: 1) 7 + 8 continue left to right 32 is a block, jump back to operator (count: 2) So that reads left to right as speakers of most western languages do with only two context shifts. Now let's try RPN: > + + * - 15 6 / 20 4 ^ 2 3 - + 7 8 * 3 2 ignore, ignore, ignore, ignore. 15, 6, context shift (1) ignore? 20, context shift (2) 4, context shift (3) ignore? 2 (wait, am I supposed to use that caret? I'm already confused and I've used RPN calculators before. Counting this as a context shift (4)) 3, context shift (5) two more operators and I don't really understand why any more basically, RPN makes you context shift every single time you enter a number. It is utter chaos to understand of jumping back and forth and trying to remember what came before and happens next. Even if you're used to it it's dramatically worse for humans, and no one cares how much software it takes to parse. Incidentally from my experience with RPN calculators I'd have expected 15 6 - 20 * 4 / 2 3 ^ + 7 + 8 + 3 2 * - Though it's not really better since instead of context shifting after every number you have to context shift after ever operator to try to remember what's on the stack

▲ fluidcruft 3 days ago | parent | prev [-]

Polish notation looks like a nightmare for expressing something like a partial differential equation. Even combining fractions looks like it's going to be a nightmare.