11 ms·

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 w

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.

edu 19y ago
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/ 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.
- tfinniga 19y ago
  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.
  - edu 19y ago
    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.

edu 19y ago

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/ 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.

tfinniga 19y ago
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.
- edu 19y ago
  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.