tags:

views:

932

answers:

7

I know there are a few different dialects of Lisp. Having decided that learning Lisp would be a new intellectual experience, I would like to know which Lisp dialect to learn, and why.

Is there one which is more popular than the others? Is any one of them more "complete", as in, better documented and supported? What are the pros and cons of this dialect?

Thanks for any input!

+8  A: 

I would say Scheme, solely because of the Little Schemer, which is one of the most mind-blowingly fun yet extremely hard books I've ever tried to read.

sheepsimulator
Don't forget SICP! http://mitpress.mit.edu/sicp/. This is a classic read.
MadKeithV
There were two or three editions of _The Little Lisper_ before _The Little Schemer_ came out as a translation of those.
Curt Sampson
+5  A: 

I prefer CL, since I like object-oriented programming, and CLOS is the nicest object system around.

jrockway
Speaking of CL, I would recommend either ClozureCL or SBCL. Both are open source, well-documented, mature, multi-platform, and provide crucial non-standard functionality like multithreading.
Daniel Dickison
+3  A: 

I learned Scheme in school. It was a great learning experience and I will never forget the fundamentals of functional programming. It probably doesn't matter which version of LISP you pick up, as long as you understand the core of its usefulness - stateless lambda calculus.

Here's an interesting article on Why MIT switched from Scheme to Python in its introductory programming course.

jinsungy
nice article!
Beau Martínez
+1 for the article :-)
David Johnstone
+4  A: 

Also Clojure is a gaining a lot of mindshare these days, and for good reason. Great data structures, profoundly good concurrency support (puts Scheme and CL to shame in this regard), and a great community. It's also relatively simple, CL is as at least as complicated as C++.

This isn't to say I don't enjoy CL or Scheme. I learned Scheme with SICP. And CL brought me to Clojure. It all depends on your goals I suppose. If you want to learn a Lisp that is immensely practical go for Clojure. Otherwise CL or Scheme are both great.

dnolen
This seems to imply that neither CL or Scheme are "immensely practical", while they are quite practical in fact.Especially the CL standard was *born* out of practical considerations.
skypher
The programming language landscape has changed since 1994, I don't know how the CL standard is going to change/evolve to accommodate what has been learned since that time. The world is lurching forward and as far as I can tell CL is standing still. I like CL, Clojure has some way to go to approach its power, but I don't see how CL is going to evolve- if you're going to use a standardized languages an evolutionary path must be apparent. Without it, a language is very likely _not_ a practical choice.
dnolen
CL has evolved and is evolving through a lot of very useful libraries. The base language was already more powerful in 1994 than all "modern" languages today.
Svante
+4  A: 

I can recommend Common Lisp on SBCL. This combination is fast, powerful, mature and well-documented.

skypher
+2  A: 

I would say all of them, at least at first. Eventually you will probably develop a preference for Scheme or Common Lisp, but they both have enough differences that it's best to get a handle on everything that's out there.

Scheme has continuations for example, and it's good to learn about those in Scheme, even though they can be implemented in Common Lisp.

Learning the difference between lexical and dynamic scope is important, and if you learn both Common Lisp and elisp you'll come across the implications of both.

justinhj
+7  A: 

You want to look for a balance between simplicity and cleanliness, attractive features, and a platform that will allow you to write interesting and useful software (to yourself) as well as serve as a learning tool. (This last will keep you going and learning for a lot longer.) Here are some possibilities:

  1. Scheme. Probably the cleanest of all dialects. This is no doubt why The Little Schemer was translated from LISP into Scheme. The fifth Scheme standard specification, R5R2, is a wonderful education in and of itself; it may be the nicest language and library specification I've ever read, as well as the shortest that's reasonably comprehensive. The PLT Scheme platform includes a fairly decent interpreter and compiler, is good for scripting, and also has some visual tools that make it excellent for learning.

  2. Common Lisp. Probably the most portable and comprehensive varient, this is most likely what you want if you want to be writing things such as commercial software. The standard defines extensive libraries, and many more are available beyond that, it has CLOS, which will probably teach you more about OO than any OO language could, and some of the compilers are very good. Disadvantages include some warts that Scheme doesn't have (such as having a separate namespace for variables that refer to functions), not being as clean and simple (as is the case with anything that has had to have the extensions and make the compromises necessary for large applications in the real world), not having hygienic macros, and emphasizing recursion much less than Scheme.

  3. Clojure. This runs on the JVM, which may give it a leg up right there for Java developers. It's got a few warts (e.g., you must explicitly ask for tail call optimization, though this may change one day if TCO is added to the JVM). The macros, while not hygienic, do have some features to help you avoid variable capture, so you can capture variables if you really want to, while running less risk of accidentally doing so than in CL. You've got easy access to all the Java libraries; that's probably a good thing for "real world" code, and fairly pointless in terms of learning. It's got a set of libraries for persistent data structures and support for STM, which make it very interesting from a concurrent point of view; this makes it probably your best bet if you're interested in learning more about new methods of dealing with concurrent and parallel programming. It appears as if Clojure is as usable for large, production applications as Java, in the sense that it's going to have the ability to do the "ugly stuff" you do in production apps that you'd rather not do and don't do when you're learning.

  4. Emacs Lisp. In terms of a LISP, this is not one of the better examples out there. One of its biggest faults is dynamic scoping, but there are many others. However, if you're an Emacs user, this may be the most powerful tool you can learn to improve your use of the editor. How much you'd really learn from learning Emacs Lisp, beyond how to extend Emacs, is for me an open question however; I don't know how often interesting techniques such as high-order functions are really used in Emacs Lisp.

Curt Sampson
Having separate namespaces is not a wart, it is just a different design decision. Keep in mind that there are already several other namespaces also in Scheme, so the debate is rather Lisp-5 against Lisp-6. Apart from the convenience that I can call a list "list" and a car "car" in CL, its macro system is just so much more practical and useful, because the compiler doesn't confuse things so easily.
Svante
Clojure doesn't have tail call optimization, and it can't, because the JVM bytecode doesn't support it. All it has is a "recur" special form that self-recurses the current function.
Svante
Svante: thanks for your TCO comment; I've added a note to the post that the need to use 'recur' may go away if the JVM adds TCO support.
Curt Sampson
Svante: what other namespaces for variables does Scheme have?
Curt Sampson
Curt: I'd argue that Clojure is the most portable since it runs on the Java VM.
justinhj
I don't know about that; if you exclude small and embedded devices (such as telephones and smart cards) where you're not going to be running an unmodified desktop/server program anyway, elisp certainly runs on many more CPUs and platforms than the JVM.
Curt Sampson
I would think that "emphasizing recursion much less" is an advantage to Common Lisp, not a disadvantage.
Sean McMillan