Hacker News Reader

Comment by Jtsummers | Hacker News Reader

> English Language is the best general purpose conveyance of arbitrary ideas, and it has syntax rules just like programming languages. It's "best" by the metric of being "easiest for humans to understand". That's what I mean by best, in this case.

Given that most people alive today don't understand English at all, I don't think this claim holds up very well.

> For example "(add, 1, 2)" is axiomatically the best way to express adding two numbers, in a way that scales to arbitrary numbers of operations. It's superior to "(1+2)" because the plus sign is a single character (cannot scale), and therefore there are a limited number of them, and using symbols means humans have to memorize them rather than simply reading their name.

I'd be willing to wager that "1+2" is understood by far more people across the globe than "(add, 1, 2)".

View on HN

* I use "English Language" as a synonym for "Human Language". However even if you want to be pedantic and interpret all my words in the literal sense, everything I said is still literally true.

* I never said LISP format was widely understood.

> I use "English Language" as a synonym for "Human Language".

That was unclear given you kept calling out English, and not natural or human language more broadly in the rest of your comment. But I'll go with it.

> all my words in the literal sense, everything I said is still literally true.

No, they aren't. You need to make a stronger case than "Because I declared it axiomatically true".

+ has become part of nearly every language already, what's the value of picking one word (add) from one language (English) to replace it? Or to be more generous to say that every language should substitute for + whatever their language's word is. Now they can't communicate without a translator. Or, they could just use + as has been done for centuries. Why make things harder on ourselves?

The point about `(+ 1 2)` v.s. `1+2` is about the fact that the LISP syntax generalizes to all computations, whereas mathematical expressions do not. The beauty of LISP is that one simple syntax solves everything about computation in the axiomatically simplest way possible.

> one simple syntax solves everything about computation in the axiomatically simplest way possible.

So what about RPN? What about Forth and Postscript? Just as simple... just as terse... just as efficient... just as general.

And, for me, just as unreadable.

I don't think RPN is as simple as parenthesis.

All RPN does is replace the easy to get right parenthesis with difficult to get right newline characters.

Reverse Polish notation is every bit as easy, simple and minimal as Lispian prefix notation. They are mirror images of one another... and for most ordinary people, both are equally difficult to read or to use.

And I include myself in this.

Remember that for a lot of ordinary people, school algebra is almost impossible to follow and is the reason they stop studying maths as soon as they can. And that is simple infix notation.

> RPN is every bit as easy [as LISP]

Riddle me this then: When editing code full of parentheticals, why do devs find it helpful that IDEs can find and highlight the matching opening/closing parenthesis automatically? I mean, based on your logic, parenthesis just don't make things any easier, right? I'll leave the topic of "indentation" completely off the table too, because a single riddle is enough.

I don't know what side you think I am arguing for here, but it's not the one you're guessing.

Yeah, I did't think you ever genuinely believed RPN is easier than LISP.

No, that is not true.

Me personally? I dislike them both. I find them both unreadable.

But both are compact and efficient... just really difficult.

You are trying to put words in my mouth that are not there. That is very rude. Do not do that, ever.

But also, as you have been throughout this thread, you are wrong.

The parenthesis in LISP make it dramatically easier to deal with than RPN; and I don't believe for a millisecond that you objectively disagree with that fact.

Lisp would be vastly less readable if the parentheses were removed, and arity had to be worked out according to the definitions of the functions and operators, understood to be working on an implicit operand stack.

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.

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) add defun)

  (((list pop) print) list while)

It helps me to read it in Japanese:

"A to B wo tasu, A to B no paramēta no aru, 'add' to iu kansuu wo 'defun' shite."

"lisuto wo 'pop' shite, sore wo insatsu shite, lisuto ga kara de nai aida ni"

Interesting things happen. When we think about how 'add' is called, we follow it from right to left, contrary to the direction of speech of the Japanese sentence. The function add is called, the (a b) parameters receive argument values and the (a b +) is evaluated.

However, the chained application expressed by nesting, which people complain about being backwards (so they need to invent piping/threading macros to go left to right) now reads left to right! We do have to evaluate the while condition first, but then the pop and print to left to right.

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?

Doing ASM ~ "RPN reasoning".

Reply on news.ycombinator.com