I think this is a feeble excuse. That is, it's an excuse generated by a lazy mind. The first time I saw Lisp, I was not "primed" to dislike it. It was early in my programming education. I was fresh, as they say. It looked no more cluttered than Pascal, the main language being taught at the time.

Can I write really ugly and hard to visually parse Lisp? Yes. Bad code can be written in any language.

Parenthesis fade into the background with experience (especially if your code is well-formatted), in the same way you start to group things by curly braces in C or Java over time.

No one looks at C code the first time and thinks it's clear to understand.

The point I was trying to make is that whitespace and parens are not equally good as delimiters.

Specifically, reading a newspaper that has parens instead of whitespace would be harder.

(Specifically,(reading(a(newspaper(that(has(parens(instead(of(whitespace (would(be(harder.)))))))))))))

In terms of actually being a problem, I'd say it depends on the code, for sure. I could create that same example in C, but end it with }}}}}}}}}}}}}}. However, in my admittedly limited experience with lisp, it seems more likely to be highly nested, tempting people to put more levels on a single line.

I also agree with you that C shouldn't be held up as the paragon of readability.

Python is pretty darn good though.

But you can format and indent your lisp code so the reader (people) doesn't have to rely on counting parentheses.

Example from taken from http://www.gigamonkeys.com/book/

  (defun test-+ ()
    (let ((*test-name* 'test-+)
          (another-var 'foo))
      (check 
        (= (+ 1 2) 3) 
        (= (+ 1 2 3) 5) 
        (= (+ -1 -3) -4))))

You should be able to read what this code does (check basically runs the statements and reports if they return true or false) without having to count a single parentheses.

I agree that lisp can be made readable. And C can be made unreadable.

OTOH lisp encourages deep nesting, which makes it harder to be readable. Here's a rougly equivalent program, if I read the lisp correctly.

  void test-+()
  {
     *test-name* = test-+;
     another-var = foo;
     assert( 1+2 == 3 );
     assert( 1+2+3 == 5 );
     assert( -1 + -3 == -4 );
  }

I'm not saying that this is any better than the lisp equivalent - the lisp function is certainly more elegant. But because C is procedural/stateful, it's more natural to have flatter programs.

And flat programs are easier to make legible, because you're less tempted to put multiple things on a single line to avoid going another level deeper in your indenation.

I agree that the C version is slightly more readable than the Lisp version, but this slight improvement comes to a big price which is the difficulty to programmatically parse and generate C code.

I think parens would be less of a problem if the indentation conventions were easier on the eyes. Sometimes you need a ruler to figure out those 1-space indentations.