Comment by thinkingeric | Hacker News Reader

Comment by thinkingeric | Hacker News Reader

Parent Full thread

For experienced programmers, the clearest introduction to Common Lisp is the first few chapters of "Paradigms of Artificial Intelligence Programming: Case Studies in Common Lisp" by Peter Norvig. His writing style is exceptional. Not quite so clear, but also not too dense, is "ANSI Common Lisp" by Paul Graham. Peter Seibel's "Practical Common Lisp" is dense (words per page), but is good for a "now I know a little Lisp, what can I do with it" book to read second. Winston's "Lisp (3rd)" goes from an extremely basic intro to heavy-duty AI without building up to it. But you can get it cheap, so it is worth it for a beginning reference.

As a sidenote, when you first look into Lisp, you hear a lot of kvetching and mocking about parentheses. And indeed, there is a point in the learning curve where you get confused about the proper numbers of parentheses for certain kinds of expressions (so-called 'special forms'). And you see Lisp apologists countering that it's not the parentheses that matter; rather the indentation is what helps you understand the code.

In my experience, what happens is that as you become familiar with these 'special forms', you learn to recognize the visual patterns of indentation and parentheses that are particular to each of these expressions. And once you write a number of them yourself, grokking the code of others is no problem. And as in all languages, a decent editor and syntax coloring is helpful.

Thanks for your straight-up and instructive comment.

> And indeed, there is a point in the learning curve where you get confused about the proper numbers of parentheses for certain kinds of expressions (so-called 'special forms'). [...] In my experience, what happens is that as you become familiar with these 'special forms', you learn to recognize the visual patterns of indentation and parentheses that are particular to each of these expressions.

Yes. This seemingly mundane topic actually interests me a great deal.

One thing that I appreciate about Arc, despite all of the language's shortcomings today (few libraries, no module system, tiny community, scarce documentation, etc.), is that its designer has taken great care to minimize the number of parentheses. The core language almost as a rule doesn't employ parentheses unless absolutely necessary, and it's nice to have a guiding heuristic like this while you're learning because it allows you to internalize the special forms more quickly.

Rich Hickey (the creator of clojure) sais something about this too. Something like this:

"Only use parentheses when it is absolutely necessary witch makes it a little harder for macro writers but much easier for users."

If i work with CL i really hate that i have to write pairs in parens. In cond or let: CL: (let ((a 1) (b 2))) Clojure: (let [a 1 b 2])

In my code, where the binding forms would typically be longer than (a 1) or (b 2), they each go on their own line, and the editor will align them by their left parentheses. In those cases where the initialization form needs to be broken into another line, the editor will indent the continuation properly, and the 'terminating' parenthesis is actually a helpful visual cue that the form is done.

I haven't written any Clojure so I'm not sure how my brain would react to non-delimited forms (ie, the implicit pairs). I also don't know how Emacs handles the indentation for these, or whether in more complicated cases, my brain would have to work harder to group the binding forms. I read the Clojure specs on 'let' and it appears to be a somewhat different beast than the CL 'let'. In more complicated cases, it doesn't appear to be an apples-to-apples comparison in terms of parsing the 'shape' of the expressions.

> I'm not sure how my brain would react to non-delimited forms (ie, the implicit pairs).

You probably wouldn't like it. ;) Seriously though, I think what we're used to plays a tremendous role in our preference here.

> I also don't know how Emacs handles the indentation for these

For Arc, anyway, the indentation algorithm is constantly making mistakes. I always hesitate to auto-indent a region because I know I'll have to go through and manually fix things. But I'm not sure this is the language's fault - the Emacs mode probably just needs to be smarter.

Reply on news.ycombinator.com