Pedantic comment: it's not reverse, it's just Polish Notation.

http://en.wikipedia.org/wiki/Polish_notation

> I remember learning Lisp and all that reverse polish notation was very unorthodox to me.

I really, really want to answer this, but it's worthy of a chapter in a book. May I summarize instead?

1. Lisp syntax is tree syntax.

An expression such as this:

    (+3 (* 4 5))

Is a tree such as this:

       +
    3     *
        4   5

2. Lisp macros can treat raw Lisp expressions as trees, and transform them into other trees, as well as avoid typical function call evaluation.

3. Lisp has little to effectively no syntax. Since all forms (outside of special reader forms) are in simple lists/trees, you effectively know all there is to know about reading Lisp. (Although, you do need to understand the Triforce of Functions, Macros, and Special Forms, but they're worthy of their own chapters to explain. They're still lists, though.)

4. The nodes[1] of a Lisp tree are also their own data structure, known as Cons Cells[CC]. These allow for easy manipulation and construction of trees, as well as easy recursion by poping off the first part of a cons cell, processing/consuming it, then sending the rest of the list back into the function. Essentially stack-like processing of lists. So while recursive functions can be rather ugly in other languages, they're rather elegant in Lisp, and easy to work with.

Jeeze, I can probably keep going, and adding more and more points and elaborating on their purpose, but it'd be better to just study Lisp on your own instead. I only know cursory Common Lisp, so I can't recommend any books or sources, but I can instead recommend learning Clojure. "Programming Clojure" has been stated to be a good starting book, but I've mostly read "Clojure Programming" from O'Reilly and "The Joy of Clojure". These are also good books, but I'm not sure which is best for beginners.

[1]: Okay, to be more pedantically accurate, Lisp 'trees' are just cons cells linking to more cons cells. It's a bit unweildly to think of all Lisp expressions as cons cells rather than nested function calls or trees. [CC]: http://en.wikipedia.org/wiki/Cons

The fundamental syntax is also the same in Scheme which I've used quite a lot. The stumbling block for beginners is of course the prefix, parenthesized, "everything is a list" notation.

It does take patience to "get used to it". The effort of "getting over the hump" is amply rewarded--one way is the benefit of seeing how marvelously consistent and predictable the notation proves to be. IOW it's a great simplifier, allowing humans to mentally read, parse and understand Lisp code.

To me the great genius of Lisps is shown by the experience of looking at work I'd done months or years ago. Stuff I'd written before in C would often be obscure to me later, especially when I hadn't made enough comments to "explain" what the code was doing.

In contrast, it's much easier to understand my old Scheme programs, often just minutes of review will do it. Sure, I'm talented at making things convoluted, it's just harder for me to do that with Scheme, and no doubt that's true for Lisps in general.

I've looked at Clojure a bit, my impression is it's syntax is more complicated than Scheme. At least there are enough differences that it would take some effortful study to become fluent in Clojure. Not a criticism of the language, but suggests making the transition isn't trivial. Perhaps that applies in both directions.

It's worth adding in the domain of constructing web servers, the list notation of Lisp maps extraordinarily well, and easily, to the hierarchical markup of HTML. It's a feature I've exploited extensively, and I think it could provide better and simpler tools for web programming if employed more widely.

Let me throw this in as an additional reading - http://www.defmacro.org/ramblings/lisp.html - it goes over points 1 - 4 slowly, while building intuition about what's so special about this and code=data equivalence using nonlisper-friendly examples.

I learnt from the Seibel book:

http://www.gigamonkeys.com/book/

You can start writing simple programs in a weekend. The learning curve is quite gentle.

For me it took 2-3 years to feel proficient using CL. I still learn new thing every week (for the last five years or so) and I can safely say that I will be learing for at least five more years. CL is a big language.

Frankly, arithmetic expressions are really the only part that's unusual. There's not much difference between:

    println("some text")

and

    (println "some text")

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.

We do this in math too: ∑_{i=1,...,n} x_i is a lot more readable than x_1 + x_2 + x_3 + ... + x_n. (Underscore means "subscript" here.)

What was the hard part ? the prefixness ? the parens or the language basic building blocks (cons, map*, lambdas) ?

The prefix-notation is annoying when you're doing anything mathematical. It's sad that CL doesn't come with a infix reader by default, I'm sure there is one on quicklisp.

Yeah that's sad. We had to load it since 21 years...

https://www.cs.cmu.edu/afs/cs/project/ai-repository/ai/lang/...

What a step back from my Symbolics Lisp Machine, where the infix reader was included...