I highly recommend 'paredit' mode for any Lispers having trouble getting used to the parens.<p>It takes a few days for the shortcuts (<a href="http://www.emacswiki.org/emacs/PareditCheatsheet" rel="nofollow">http://www.emacswiki.org/emacs/PareditCheatsheet</a>) to become second nature, but then you never really thinkabout the parentheses again.
If you use Vim and have "showmatch" enabled, then when you move your cursor onto a left or right parenthesis, it shows that character with a charcoal background, and the matching parenthesis with a teal background. Your mind immediately perceives the extent of the expression. Then if you press "%", your cursor moves to the matching parenthesis. You can toggle back and forth by pressing "%" repeatedly. This also works for braces and square brackets. Also you can delete, change, and yank whole expressions with the usual idioms "d%", "c%", and "y%".<p>I'm not arguing Vim over Emacs here, I just wanted to point out that Vim has excellent support for parenthesized expressions.<p>Interestingly, when I write procedural code such as C or Perl, I put a single brace on each line. For example:<p><pre><code> if (condition)
{
...
}
</code></pre>
That makes it easier for me to move whole blocks around.<p>However, when I write functional code such as Lisp or Fexl, I tend not to do that. For example:<p><pre><code> # Collect any matching entries at the front of the list.
\collect = (\match\list list end \head\tail
match head (item head (collect match tail)) end)
</code></pre>
I think that's because I tend to keep all my Fexl expressions very short, building them up step by step.<p>Also, Fexl uses ";" as a "right-pivot" operator. For example:<p><pre><code> \collect = (\match\list list end \head\tail
match head (item head; collect match tail) end)
</code></pre>
So in many cases I can avoid multiple right parentheses. The Clojure example in the article would become:<p><pre><code> \myfn-a = (\a\b zero? b a;
recur (afn (bfn (...)) a) (dec b))</code></pre>
I tend to put them on new lines in a handful of cases. Defstructs are one, because then I can easily add a new field at the end by just inserting a new line and writing on it.
I write a fair amount of Scheme code. I don't like the one closing paren per line thing for a reason similar to why python and haskell choose indentation for grouping (try adding braces to them). Code written like that looks bigger than it really is and is quite tiring on my eyes.
I'm not sure if that long thread included my two favorite reasons before it turned flame-y:<p>1. Lisp has a lot more parens than C or Java has curly brackets. The cost to vertical space is exaggerated. Otherwise you end up closing in a new line sometimes and not others, which quickly becomes distracting.<p>2. Somebody once said (anybody have the quote?) that C and java code looks blocky, while lisp code looks more fluid, like clay being moulded. That aesthetic speaks to me.
Indentation communicates most of what parenthesis do and therefore are mostly redundant as far as the (human) reader is concerned. Having them all bunched up at the end of the line is the most efficient way to (not have to) handle them. We can't get rid of them of course because although they aren't providing much benefit to the reader they are essential to the compiler/interpreter.