

Starting with Lisp: A collection of beginner pointers - dragonquest
http://www.dreamincode.net/forums/blog/48/entry-3070-starting-with-lisp/

======
thinkingeric
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.

~~~
evanrmurphy
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.

~~~
nickik
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])

~~~
thinkingeric
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.

~~~
evanrmurphy
> _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.

------
motxilo
I would add that reading SICP or HtDP is not enough, you need to work through
the exercises to sink in the important programming principles they try to
teach you. Also, I miss the Schemer/Lisper series by Friedman et al. in that
list.

Just out of curiosity, regarding claims like "Common Lisp has a fairly sized
community which is widely regarded as a tough bunch" or "The Scheme community
is really one of the most tolerant communities of them all", are those based
on personal experience? How did you come up with such conclusions? I'm really
interested :)

~~~
dragonquest
I would say this is from personal experience based on lurking on CLL and a
couple of dumb questions I asked on #lisp once. I don't really mind the CL
community, its just that the help starts once you've one (atleast, even the
introductory one's) or a major chunk of one book down cold. After that they're
really eager to show you the path.

Compare this with many other language communities, people regularly ask
questions regarding where are the installer's kept which is answered with
great politeness by some good netizen. The contrast only occurs that the
benchmark of the CL community starts at a higher bar. Recently though, as I
wrote in the blog post, even the big-name lisper's seem to guide newbie's to
LispBox's URL or suggesting the command line to install SBCL on Ubuntu which
certainly is making CL communities a fairly friendly place to be.

The #scheme guys are just amazing. So are the individual mailing lists of the
implementation Racket. Somebody on #scheme actually held my hand
(metaphorically) to clear my confusion as to which function is the "main"
function where execution starts. I used code a little in C/C++/Java and was
expecting a function named "main" even though I was testing individual
functions from the DrScheme IDE's split window REPL.

~~~
motxilo
I find rather amusing that lispers and schemers differ that much when it comes
to lend a hand to people, especially when Scheme is a dialect of Lisp. Do
lispers regard the poor schemers in an envious way just because tail-call
optimization is part of the Scheme standard? :)

No, seriously. Nowadays, it seems like people sometimes forget what they
struggled with when they were learning the ropes of some technology.

------
shawndumas
How 'bout Land of Lisp? [1]

\----

[1]: <http://landoflisp.com/>

~~~
dragonquest
I wanted to include it but I have not read it :) It seems really interesting
but is not available in my local bookstores and my current set of books (the
one's I mentioned) keep me humming along.

However judging from other people's reactions, I'd say it should a top notch
work.

------
peteysd
Just got through reading the first suggested item in the Background section:
<http://www.defmacro.org/ramblings/lisp.html>

I recommend this to anyone interested in learning about the appeal of Lisp.
It's well-written, and lays a nice foundation for those trying to figure out
what all the buzz surrounding Lisp is about. I'm sold.

------
Xurinos
A few more tips I found helpful as a beginner:

* Most lisps can compile a binary, even the free ones.

* sbcl seems to have a ton of popularity and support.

* Want to mix Lisp directly into your C code? Try ECL. Most important: it works, and should not take you long to connect it to your program.

* clisp has a nice readline-like commandline; you can get something like it in sbcl with the linedit module

* ASDF isn't horrible, but quicklisp makes packages much easier to get

* cliki.net - browse packages, ideas, etc

* CFFI package lets you use any external library with your Lisp program. Lisp has its own version of C header files that you can build via CFFI.

* Edit lisp in any editor. Emacs is neat. Vim works, too. Both have some extra support tools for Lisp. Emacs is more supported. Worry about learning Lisp first.

* At minimum, your editor should help you figure out what ()s match (or provide them for you). Otherwise, you will spend time counting and being annoyed with ()s rather than loving them.

* Before you write your fourth Lisp program, read some typical Lisp code. Just get a feel for it. Look at how it is indented and arranged. Go back to writing code.

------
shanked
I'm just beginning my road down the path of learning Lisp. My plan for
learning is:

1\. Read the Practical Common Lisp chapters which introduce Lisp features.

2\. Write a web application using Common Lisp (Hunchentoot/Postmodern). After
all, the only way to learn a language is to use a language.

3\. Re-read Practical Common Lisp and/or other Lisp books.

I realize that I won't remember 90% of the material read in Practical Common
Lisp in Step 1. However, I'm hoping that I can get an overview of the features
available in the language to help design a better web application. Knowing
some names of features like CLOS, cons cells, plists, alists (and others that
I haven't gotten to yet) will just make it easier for me to search for help
when I run into problems.

If anyone has any references to good materials for the following:

\- Learning Common Lisp

\- Creating CL applications using Hunchentoot and/or Postmodern

\- Quality Common Lisp API specs

\- Any other tips for an aspiring Lisper

I'd be grateful for any additional information that might help me along the
way.

~~~
blue1
I am not sure that writing a web app is the best way to learn common lisp; it
introduces a lot of extra complexity (libraries, web server, etc) in a
language that is itself quite complex. You'd better start from a simple CLI
application as your first project.

Books: there is also Graham's "ANSI Common Lisp", which has a different
approach from PCL; I found it clearer as first text (but PCL is a necessary
reading anyway, for various reasons). But it's a matter of cognitive styles,
start from the one that you prefer.

Absolutely download the Common Lisp Hyperspec and familiarize with it. Is the
main everyday referemce tool of any CLisper.

Environment: Emacs + SLIME is the most popular option. Commercial lisps (and
their free evaluation versions) also have good IDEs.

Have fun!

~~~
shanked
Well, I had an idea for a web application that I'd otherwise create in Python.
I figured I'd use Lisp to get some experience using it (also, my AI class next
semester uses Lisp).

While it will probably cause some additional hurdles of complexity (such as
figuring how how to use ASDF and manage packages), I find it is hard to
motivate myself without a shiny carrot in front of me. The web application is
something that I would use and want to build, whereas writing a simple and
purely educational program doesn't provide the same kind of motivation.

~~~
blue1
If you can handle, go for it! But if after a while you'll think that lisp is
not so different from the other languages after all, it's probably because you
tried to learn too many things at once. In that case, persist. :-)

