Lisp's parenthetical syntax is not, and never has been, its problem. You say "parenthesis" as a cute excuse to avoid doing any meaningful defense of your rejection of lisp.

I've wondered for years why people latch onto the parenthesis thing. When I learned lisp for a class, I never gave it a second's thought. To me it feels like people are looking for a handy reason to put Lisp down, perhaps either because they don't understand it or because they do understand it and they are jealous of some of the features of Lisp.

Personally I prefer both Forth's RPN and C/C++ (Algol?) style notation to Lisp's s-expressions.

However, I do like the overall elegance that this brings to the code, where code and data are the same. Which is why I also like Postscript -- it does the same thing but in an RPN style (a function is actually an executable array).

Also, there is great support from lisp-friendly editors to handle parentheses management (e.g. paredit for emacs http://emacswiki.org/emacs/ParEdit).

If the latter, pg makes a good argument in section 4.8 of On Lisp:

"So yes, reading a bottom-up program requires one to understand all the new operators defined by the author. But this will nearly always be less work than having to understand all the code that would have been required without them.

If people complain that using utilities makes your code hard to read, they probably don’t realize what the code would look like if you hadn’t used them. Bottom-up programming makes what would otherwise be a large program look like a small, simple one. This can give the impression that the program doesn't do much, and should therefore be easy to read. When inexperienced readers look closer and find that this isn’t so, they react with dismay."

You know, I don't think this is true at all. Concision can make things harder to read, because you have to understand everything you read from scratch. A language where some common patterns come with a bit of boilerplate allow you to orient yourself via that boilerplate. The visual representation of a common pattern provided by the sugary syntax of some languages is, in one sense a waste of space and typing, but it can make code easier to read than a more concise language would be.

Compare a language which forces you to write this

    ll = []
    for x in xx:
      if bar(x):
        ll.append(x)

Contrast the above with

    ll = [x for x in xx if bar(x)]

    filter bar xx

I find Ruby way much more natural.

xx.select { |x| bar(x) }

Even Clojure is better

(filter (fn[x](bar x)) xx)

or

(filter #(bar %) xx)

That said, in Python, you have to take what you can get, though. And generally I expect more people are familiar with Python than Haskell. Probably I should've used Ruby. Oh well.

  filter foo xx

    filter foo xx

Pseudocode is better expressed in Python than Lisp, therefore much better in the academic world.

My point stands: READABILITY.