>>16
I supposed the forced indentation of the code is the next best option. M-expressions, at least as I understand them, would be nearly as bad as or worse than sexps. Mexps seem to just drop the outer layer of parens (more accurately they move the function name outside those parens) and add commas as list delimiters. So they actually mean more typing, and no fewer parens ( [] are actually used instead).
As a matter of fact, ))))) is not a problem limited to Lisp and discussions of drone music. Even in C, I've made it to )));. Add a bit of arithmetic inside that, and you could easily hit Lispy tangles of parens. It just happens more often in Lisp because a functional style is preferred rather than ignored.
If I were moving to improve the situation, my first step would be to add [], {}, and <> to the list of acceptable brace characters. <> are already used in CL to denote unprintable representations, but that's not an issue in theory. The Lisp reader would check to make sure that each brace style was matched by the proper closing brace, so "(})" would yield an error (close "}" found with no matching open "{"), but "({})" would be fine. I think this would make it much easier to scan Lisp code quickly. A programmer could start a defun with "(" and know that they have to hit ")" at the end.
The next step might be to use a thread over system (iexp based) to write the code. This is a pretty popular approach, but it has failed to catch on thus far. It could be a tad ambiguous, I think.
It's a bit of a moot point though. Oh, where will we programmers ever find someone to make sure our text editors do brace matching? I guess if you're writing your code in Notepad or ed you may be in for a headache, but no moreso than keeping your indentation in order.