I don’t know if it helps, but I used reverse Polish notation calculators before doing much lisp. To this day for little calculations I will either type an Elisp expression into my eMacs scratch buffer or if i am out and about will use my HP 15C app in my phone. Even if I am transcribing from an infix thing it is easier. The reverse means no paren, which is easier.
Indeed. But lisp is much more than prefix notation.
Different notations like revers polish notation also easier to parse. You can evaluate RPN only using stack.
Also, recently I learned about thread-last macro in emacs lisp. Using it you can evaluate forms from left to right, and using it you can write less parenthesis.
I used to feel the same way but lisp gets easier to read with practice, and unless you're writing code in notepad.exe or nano or something, your editor will show you the matching paren.
At the end of the 70's I bought a HP67 pocket calculator and discovered that adding 1 and 2 was done using the strange reverse Polish notation, "1 2 +". Much later I came across LISP and discovered prefixed parenthesized expressions, {+ 1 2}, i.e. the normal polish notation in parentheses. Then I discovered that an HTML expression like "<b><i><u>Hello World</u></i></b>", requiring that closing brackets be written in the reverse order, would be better written in a LISP style, {b {i {u Hello World}}}, without boring anymore with the order of closing brackets. Finally I found that if writing {u 1 2 3 4 5 6} displayed "1 2 3 4 5 6" in underline style, writing {* 1 2 3 4 5 6} displayed the product, "720", and writing {u {* 1 2 3 4 5 6}} displayed "720" in underline style.
Mixing pure text and code became obvious. This made me want to write a text editor with a programming language and its current state is in this wiki
- http://lambdaway.free.fr/lambdawalks
For me - I'm just an "amateur", it was that the Lisp "Enlightment", just to give me a way to implement from scratch a small engine to go down to the foundations of code, discover the lambda-calculus, and have a chance to understand and enjoy coding.
I write Lisp very quickly and I don't use paredit or parinfer. I depend on Emacs' automatic paren matching, auto-indent, indent-sexp, and forward/backward sexp functionality but that's it. I guess I'm just used to it.
At the end of the 70's I bought (very expensive) a HP67 and discovered the inverse Polish notation, "1 2 +". Much later I came across LISP and discovered prefixed parenthesized expressions, {+ 1 2}, i.e. direct polish notation with parentheses. Then I thought that an HTML expression like "< b>< i>< u>Hello World< /u>< /i>< /b>", written in the right way, would be better written in a LISPsish style, {b {i {u Hello World}}}, no more boring with the order of closing brackets. Finally I found that writing {b 1 2 3 4 5 6} displayed "1 2 3 4 5 6" in bold, writing {* 1 2 3 4 5 6} displayed the product, "720", and writing {b {* 1 2 3 4 5 6}} displayed "720" in bold. This made me want to write a language about these findings and its current state is here http://lambdaway.free.fr/lambdawalks/.
I said it in jest, sorry. I wrote a bit of PostScript because I absolutely had to and it was painful, even though I was thrilled to eventually push through.
But I'm very particular about syntax, so the reverse polish notation was enough to upset me. Needless to say, I appreciate Lisp for its power and conceptual simplicity but would never choose to use it.
The joke has been going on for quite some time now - Lisp and related languages use Polish Notation everywhere.
(The main benefit is that (R)PN is parenthesis-free, so it makes it easier for a calculator to process expressions with multiple operators. The use in programming languages is nonexistent but to make clear that +, *, .. are just like any other function call, where you would naturally use polish notation.)
I've been doing serious math with common lisp for 30 years. For me, the convenience of having automatic bignums and complex numbers, n-ary functions, and true rationals means I can think about math rather than about the limits of computers. The prefix notation became a non-issue in about a day.
In Haskell, I have the luxury of infix arithmetic, but I'll still happily write
sum [a,b,c,d,e]
when I have a lot of summands.
It's just neater, especially when you format as
sum [summand1
,summand2
,summand3]
This is more natural in Lisp. Because of this, I always go to Lisp for things like my weekly shopping budget. For bonus points, I can put my cursor at the end of a close bracket and get Emacs to evaluate the enclosed subexpression, which I do lots to figure out the value of individual terms.
Not quite. If you drop Lisp's variable-arity operators, that enables you to drop the parenthesis. If you drop the parenthesis, that gives you Polish notation.
The Lispers contend that the use of parens is merely a surface detail which the reader can get past with a bit of effort. This is clearly true for some people, but I don't believe it to be generally correct.
Much of what we do when reading (whether code or text) happens at a low level, way below conscious thought. This allows us to, for example, skim a list and spot the desired entry without having to think about each one. Formatting and punctuation provide guideposts that help in this process.
Similarly, the syntax of most programming languages contains a wealth of punctuation characters. A well-formatted and idiomatic program can be skimmed quickly, without the need for understanding each symbol.
Lisp, in contrast, removes all of these guideposts. So, in order to skim a Lisp program, the reader must understand at least the general nature each symbol s/he encounters. For example, a cond is a much different operator than an add.
So, although I like the benefits of Lisp, I dislike the syntax so much that I have avoided using it for decades. Fortunately, José Valim has created a language (Elixir) which provides Lisp's benefits but uses a syntax (mostly Ruby) which I find appealing.
I find it difficult to read if I just try and read it left to right, but if I simply go directly to the innermost operation its not really much more difficult for me. And I’m not a lisp user, either.
One trick that makes life easier for lisp is to use something like Karabiner Elements or xcape to turn taps on the shift keys into parentheses. Also, setting up nice keybindings to insert and manipulate parens. Between these two things, I’ve never found lisp any harder to enter than infix languages.
Polish notation enforces binary operators. LISP doesn't, so you have to have the parentheses. (+ a b c) is + a + b c or + + a b c in polish notation. These are the same, of course until thet are not, such as with floating point arithmetic or in case you trap on integer overflows.
I was never any good at math in the first place, order of operations always screwed me up, still does. Order of operations actually makes no sense at all (if you really think about it). So yeah, lisp is easier for me.
Parinfer is also really nice. It rearranges your parens automatically based off of your indentation. I still prefer something like Paredit, or Smartparens for the power user features, but Parinfer is really intuitive and just works without having to learn new editing commands or hotkeys. It's my go-to recommendation now for people coming to lisp for the first time because it makes working with lisp code very similar to working with an indentation-based syntax like Python.
reply