On Lisp's Readability and Parenthesis Stacking

The problem is not the ()))))), it's the 200 lines function which does 20 different things all at once. Split that into smart and readable function.. You identified a problem (Hard to get where that println goes), however, you came with the wrong solution.

But I need to say that you are right about the fact that many lisp code are really ugly.. Maybe it's because when programmers are coding in lisp they considere themselves hackers and don't think about coding cleanly.

"With great powers come great responsibility." Since Lisp is the most powerful language, people should learn to separate abstraction into separate function. I mean, it's not because you have lambda and you don't have to name function that you absolutely need to do it.

Often, for small function, lisp coder tends to put that in a lambda and inline it directly in the bigger function.. which in my opinion is not the way to go.

A friend of mine once told me he really liked lambda because he had difficulties to find good game for function and variable.. by stacking all lambda together, it was way faster and easier for him. The problem with that, of course, is when other programmers will actually try to read that code and understand what it does.

Flame me if you want but when I need to work on someone else project written in lisp code, I always know it will be a pain to understand it. However, when I need to read java or C++ code, even thought the syntax is uglier and more verbose, I know I will have no problem reading it.

So here's a small trick for you hackers:

- Don't be afraid to separate your code into many functions, even if you are using lisp.

- Don't be afraid to use (let) syntax to give a name to portion of codes.. it might be harder to write (finding good variable name is sometime really hard and takes more time), however, it will make the code so much readable.

"If you feel that parenthesis stacking actually improves the readability of your code, by all means, feel free to do so! However, "everyone else is doing it" is not a good reason to sacrifice the readability of your code."

I think it is a good reason. The community benefits when everyone uses a consistent style. Readability isn't just about being able to read your own code, it's about helping other people read your code.

The accepted style of the community will make sense up to a point; no one wants to make things really hard on themselves, and people gravitate toward things that are comfortable. But it'll also be partly arbitrary and probably not optimal in every way. Part of learning a programming language is learning the idioms and dialects of other programmers.

Using a style no one else in the community uses is like making up your own words in spoken language. People will be able to understand you given some effort, but are they going to bother? If they do bother, they're probably going to be annoyed. Even if your new words are "better".

If you're the only one reading your code, knock yourself out. Otherwise you should probably suck it up and adapt, in my opinion.

"No other language that I'm aware of stacks scope delimiters or has a community where the standard indentation width is two spaces wide, and where sometimes even a single space is considered acceptable."

Idiomatic Ruby uses two space indentation. Maybe because Ruby is often so deeply nested, like Lisp.

Meh. Took me all of two seconds to figure out what scope that line was in. Then when I read on and was told its hard, I double-checked by counting parentheses only to find out I was right the first time. I honestly don't know what hes talking about.

As for "line count" not being important, I personally like fitting as much code into one screen as I can (especially since I often code on my netbook). Short functions are important, but even then, nice and compact code is still very important to me. Especially since I'll split code onto their own lines once the line gets more than about 70 or so characters long.

I dunno. Even if line count was unimportant to me, I don't see what the problem is, since I found it easy to spot the nesting.

Anyway, that code is much too complicated. Hes using Clojure (ie, a Lisp), he should make use of the available abstractions to simplify the code. This will, in turn, make it easier still to figure out nesting of arbitrary lines of code.

"Now try the question again, in what function or macro is the highlighted line located in? Was it easier to answer this time?"

No, not really, no. I didn't find it any easier either way.

I also don't buy this fellow's argument that lisp is the only language in which people rely on the editor to help them figure the the scope of expressions. I know that I use the editor when coding in C like languages as well. So I don't think that this argument for trailing parenthesis bears any weight.

The only argument that does make sense to me is that inserting a new expression at the end of a form can be annoying with editors that expect to operate on lines.

Personally, I find "parenthesis stacking" to look nicer, and it certainly has the advantage of being standardized and widely accepted in the Lisp community. One of the advantages of Lisp's syntax is that indentation and formating is so well standardized you can rely on an editor to do it right every time.

I've long ignored the Lisp formatting debates because I seem to provide, for myself at least, the only counter-example that many authors are convinced doesn't exist. That is, the traditional Lisp parentheses "hell" is very much readable to me, thank you. More so than the C-indented style.

I use C-M-b and -f to jump around the parentheses but I would do the same with properly indented C code as well. I don't always "see" whether this right paren aligns with the left paren that has 16 or 20 spaces of indentation.

Secondly, the author dismissed the argument of lots of indentation and lone right parens making the code longer, but it's a valid point. I can see the Lisp function in one screenful while the C version would flow outside. And for me, that's even worse.

Third, code always needs mental parsing in your head. Code isn't meant to be merely read, it's meant to be inspected and studied. It's an interactive process and it's not cheating to use an interactive editor to help you with that.

Interestingly enough, his "parenthesis-stacked" C code looks just like Python, which I find a pleasure to read.

There's one difference, though: conventional Python is indented four, not two, spaces. In fact, the main aspect of his "normal" C code that makes it more readable (to me, at least) is his use of four spaces for indentation.

Personally I think the biggest barrier to Lisp readability is too little indentation (two spaces is typical). Looking at his reformatted Lisp, the way I identified the nesting level of his highlighted line was not by looking at trailing parens but by looking at the indentation, which was much wider (and therefore clearer) than standard Lisp.

It seems to me like the second example's readability stems almost entirely from the indent increase. I don't see how the stacking helps or doesn't help at all. I just saw the addition linebreaks as noise that ruins the flow of the code.

Even with the current example, I immediately said, "Inside the let." The only uncertainty for a half-second in my head was with the with-open, but that's only because 2-space tabs are pretty tight and long functions like that make reading the drop harder.

The Clojure example he gives of a closing paren stack that looks like ]))))])))) highlights the downside of the Clojure sugar for vectors. It's a lot easier to just keep pounding out parens at the end of an expression until they match up than it is to carefully alternate ] and ). This outweighs whatever gains were made by the vector literals IMO.

I think I would have preferred some standard reader macros instead for collection literals.

Poor Python programmers...they can't trail their delimiters, because they don't have any!

I did find it vaguely easier on the second one but (aside from already knowing) I'd chalk it up to two reasons:

1) 4 space indents instead of 2 making it more visually obvious.

2) I wasn't told "pop quiz" and so I didn't assume it was some sort of trick and so I trust the the indentation.

> Now try the question again, in what function or macro is the highlighted line located in? Was it easier to answer this time?

No? In either case, if it were me I'd highlight the previous close-paren (whether it's on its own line or not) to see what form it associates with. I'd do the same thing with a close-brace in C++ or an end token in Ruby. Long code blocks are a problem of every language, not just Lisp.

First, if you're writing code in an editor, there's no problem with using that editor help you write the code. Complaining about having to use an editor to use paren-matching is like complaining about screws because they don't work so great without a screwdriver. You have tools, you can use them, you don't get man-points for scratching your code into a stone slab with a chisel.

That rant aside...

Trailing parens (and trailing braces in brace-y languages) do increase local readability, but they do so at a global readibility cost. They eat lines of code, which makes it difficult to see an entire code fragment at a time. Like all trade-offs, there are reasons why you should and shouldn't, and situations where you should and shouldn't. And the important thing is, the cost of trailing parens is higher in a Lisp than it is in your average brace-delimited language. This doesn't mean that it's always the right decision in C or the wrong one in Lisp, but on average C is more likely to get a net benefit than Lisp.

Lisp simply nests more than C-style languages. This means that you pay the line-costs more often and your code density goes down a lot faster. There are a couple of reasons that Lisp nests deeper, some of them from the language itself, some cultural. From the language side, C only uses braces for control structures, and those don't return values. In Lisp, both functions and control structures use parentheses, and control structures return values so they often get used as arguments to functions, increasing the nest depth. From the cultural side, C-ish languages use variable assignment and sequencing of operations as its fundamental operations and braced control structures are less frequent, while Lisp passes values as arguments to functions as its fundamental operation. Lisp tends to use additional parentheses in places where a brace language would use a semicolon instead of a brace.[1]

I have to say, the trailing-parens didn't really help me read the example that much. Having extra parentheses didn't help me figure out what line indented with what. In fact, it made it harder because there were more lines in the way. I suppose people who favor brace-y languages count braces rather than matching indentation, but like I said before, Lisp nests more so that's a lot of counting. Again, this doesn't mean that stacking parens is always right in Lisp, or even that it's right in this code sample, since I'm not the one writing or reading it. It means that, once again, these religious wars are silly and you should pick what works best, and my $/50 is that trailing is more expensive in Lisp so it doesn't increase readability as often. FWIW, people who claim Lisp code is naturally more dense could argue that Lisp can more easily pay those extra lines.

[1] Example idiomatic C-ish language (JavaScript perhaps):

  a = foo(x, y);
  b = bar(x, y);
  return qux(a, b);

vs idiomatic equivalent lisp, which prefers to nest deeper rather than assign intermediate values:

  (qux
    (foo x y)
    (bar x y))

You know, I kinda like that Lisp-style C++ formatting...

The real reason that parenthesis-stacking is the norm is twofold:

a) Trailing parentheses just look ugly. I can't really explain why - perhaps it's merely a cultural thing, come about only because lispers are so used to looking at stacked-parenthesis code.

b) Lisp code tends to get very nested. In C or Java code, you rarely get more than 3 trailing braces in a row. In Lisp, if you trail parentheses, you regularly end up with 5 or more lines of nothing but trailing parentheses. This contributes to the ugly factor and makes for a lot of "wasted" whitespace. It's also one of the reasons 2-space indentation is the norm for lisp instead of 4-space.

Honestly, I don't think trailing parentheses makes lisp code particularly easier to read. I agree with noahlt that it's mostly the 2-space versus 4-space indentation issue.

The main advantage of parenthesis stacking is that it signals that the form you're using might be too nested. Granted, a lot of leading white space does this too. YMMV.

I would say the real solution, the one which increases readability the most, is to remove the need for many parentheses at all by using optional significant whitespace – see http://www.dwheeler.com/readable/ for an example of such a syntax. (Of course, if you don't export your code to normal, over-parenthesized Lisp before giving it to others, they will have trouble running it.)

Readability is more about consistency than some style war. If you read more code that looks like X, then code that looks like Y will look "weird" and "unreadable". The exact opposite holds for those who read more Y.

Try reading a Japanese manga translated into English. You start from the back of the book and read the right page first. Or try learning a language with "verb at end" kind of structure if English is your native tongue.

With lisp, the parentheses help create uniform parseable structure for both code and data, so I appreciate the compromise of a repeatable indentation scheme for code (using an editor) that lets you totally ignore the parens when reading.

With lisp, I do find syntax formatting such as bold keywords very effective even in the absence of color. So yeah, it is easy to create readable lisp in print as well. In fact, with bold keywords and gray parens, lisp code looks gorgeous and eminently readable.

http://xkcd.com/297/

Oh hey everyone look! Another childish post about syntax! Let's all argue about nothing!

I found both of the C code examples equally readable, but personally use neither one when I code in C. I don't (usually) stack closing braces in C mostly so that I don't accidentally kill a line with a closing brace on it. That sort of thing can theoretically happen in Lisp, but is usually easier to spot and easier to fix.

I do, however, in C put the opening brace on the same line as the definition, generally to make grep more productive. I've found it nice to be able to grep for { (or even "){" and get some useful information.

Well, if this guy is going trailing parens, I'm going to start, too. I thought someone old beardy lisp guy would jump out and shoot me if I did, but he seems to be doing fine.

I write my LISP the way I write my JavaScript: I use one space for indentation, I break up my lines a lot, I nest deeply, and I tend to have a line break after the open and before the close, if the nesting is more than a layer or two deep and two broad. I'd prefer to use a tab for indentation, but I often find myself typing my code into an "eval box" (a textarea on a web page tied to a button that calls eval on the contents of the box).

A bit out of topic, but does anyone here write (serious) scheme/lisp code with vim ? Just a curious question ...

Most programmers prefer to use spaces instead of tabs because of some rant written ages ago by a Lisp programmer.

Spaces are better only for Lisp. Tabs are better for C++.

At least for parenthesis the custom is different.