When I started learning CL from Practical Common Lisp, as is preached in the book, I started off with Allegro CL compiler. I stopped using it, since its commerical, yet free bit didn't impress me. It needed a connection to its remote server for some licensing stuffs.
I switched to 'clisp' and am using it. Now, I have been hearing about SBCL and planning to start using it as well.
So, the question is: How do the various ANSI CL implementations differ? Any practical experience of using one over the other ?
Thank you.
See Common Lisp Implementations: A Survey by Daniel Weinreb.
If you are on a machine that can run SBCL, you should use it. It's
the fastest free Lisp compiler (it can generate code that is as fast
as Haskell, OCaml, Java, C, and C++, which are all very very fast,
especially compared to Python and Ruby). It also is a fairly complete
implementation, and supports most of Swank's features (for SLIME), which is nice when you are developing.
As some of the other comments mention, you won't really notice any
differences when you are first starting out. All the free CL
implementations are "fast enough" and support all the features you'll need. But if you start writing
production software, you will appreciate SBCL's features. OTOH, there's really no reason not to switch now.
I have been looking at Win32 solutions to the same question. As far free Lisp implementations on Windows, I would strongly recommend Clozure CL (CCL). There are several reasons for this. The first is that Clozure supports 32- and 64-bit binaries. It's very fast, and somewhat compact. But most importantly, it's consistent and correct. I find it to be an extremely mature Lisp, after working with Lispworks (which I miss) for several years. CCL does a very nice job with native OS threads, sockets, and some other elements that are not part of the CL spec. Its implementation of CLOS seems to be extremely thorough. And it's GC and memory management are excellent. I compared CCL to SBCL on Win32, and while SBCL was a bit faster on several benchmarks, it cons'd up a lot more, and its image kept growing and growing, even after several forced GCs. Meanwhile, CCL was consistent, small, quick, and lovely to use. And if you want a platform that's consistent across Windows, Mac, and Linux, and has both 32- and 64-bit support, then look no further.
I did try CormanLisp on Win32, and there were many things about it I liked. But it does not run properly on 64-bit Windows platforms, and is limited to Win32. It's also not free, and somehow I had it crash on me when I'd throw some garbage code at it. I also was easily able to make SBCL crash. Not so with CCL. Rock-solid. Really, those guys did an amazing job, and ultimately will help keep Lisp alive.
As for SLIME, I didn't try to get SLIME working with SBCL, but I did get it working nicely with CCL. No matter what your fancy is, I advise that people write code to be easily portable. Aim for Windows, Mac, and Linux, and aim for 64-bit. If you consider these, then CCL is your best choice overall.
A last attempt at an answer to this is to consider what is wrong with the others. Here's what I've come to find:
CLISP is nice, but is far slower, relative to SBCL or CCL. I see little upside
SBCL seems poor on Win32. Image size can get big.
CormanLisp is good on Win32, but not portable, and does not support Windows x64.
It also seems that Roger Corman is not actively developing CormanLisp, which is
a shame, but it's the reality.
Clojure (with a "j") is not Common Lisp. As nice as it may be, I think that
if you already know CL, then it's not worth the overhead of learning Clojure's
many differences. I'm sure some may pick them up fast, but I surely did not.
(If Java-compatible code is what you're after, then look at ABCL).
dave
There are portions of ANSI CL that leave certain details up to the implementations to determine; you will find that for those parts of the standard, each implementation will have its own quirks.
Also, look for things that are important to the runtime but not defined in the language: things like threading and multiprocessing and garbage collection will vary substantially in performance and reliability.
I have found SBCL to be the easiest implementation to work with in Linux; it has good support for threading in Linux. I can't say much about the garbage collector, because it hasn't mattered to me much yet.
On Windows, your best bet will probably be Allegro or LispWorks, although I've had some success with clisp on Windows. The Windows port of SBCL is progressing, but I haven't used it much, so I can't really comment.
Generally speaking, an understanding of these kinds of things that are difficult to acquire through research or analysis; it comes through experience. Just pick a decent implementation that you're comfortable with, and get to work. You'll figure out the tricky stuff as you go.
I don't know enough to give you a detailed answer, but I noticed that SBCL was considerably faster then Clisp when I was working with CL for my AI class. Unless you have a compelling reason not to, I'd suggest going with SBCL.
I've heard that Clisp is easier to install and is more portable than SBCL (which has lots of processor-specific optimizations), but if you're using Linux they're both easy enough to fetch from the package manager.
I found the error messages in clisp to be more friendly and help me find the problem faster.
It seems that SBCL's REPL is not friendly compared with clisp ? E.G. I can use TAB key to auto-complete input in clisp.
so clisp is a better for lisp newbie.
I've had pretty good luck with installing clisp using cygwin if you're under windows.
Depends on your OS of choice
Windows - use ecl or abcl
Linux - use sbcl or ecl or abcl or cmucl
Mac - ccl or ecl or sbcl
Other - abcl or ecl or sbcl
EDIT:
Sbcl on windows lacks threading and is, in general not that stable, and none of core maintainers use windows.
ecl is much better choice for cross platform lisps, its feature set is equaly stable on all major platforms.
EDIT 2011-10:
Sbcl windows now has threading support. It is not yet fully merged in mainiline, but there is a fork which is pretty stable which have threading and other Windows specific goodies.
Related
I am somewhat familiar with Scheme. I am reading OnLisp, and would love to do a real world project in it. Most likely web development. I would love to know what kind of setup people use to develop websites in lisp. I have a couple of macs at home and I have figured I would use clozure cl. I am wary of a few things though. I have read on the internets that cl doesn't have reliable threading facility nor good networking. Is this true? What was your experience?
PS:Don't tell me about clojure :). Lisp is a itch I need to scratch.
Currently I'm using Restas a framework based on Hunchentoot and inspired by the route system of Rails. I also use Postmodern to interact with a PostgreSQL database and I generate HTML with cl-markup though I'm thinking about switching to cl-who which looks more customizable.
When I've started I've also considered using Parenscript to generate the JavaScript but now I'm just happy with Mootools and plain JavaScript.
Everything runs on SBCL and is available with Quicklisp.
Not sure why it wouldn't have "good networking"; you can't rely on threads if you want to write a portable Common Lisp application since certain implementations don't support them (AFAIK, just clisp, though you can compile it with experimental thread support). If you plan on picking an implementation and sticking with it, you won't have that problem.
The "standard" CL web stack is Hunchentoot/cl-who/clsql, though you can find tutorials that run on Araneida or Portable AllegroServe.
The setup I use is Debian/SBCL running quicklisp and the above systems along with MySQL (though I'm seriously considering jumping over to Postgres) for the database and nginx to run in front of Hunchentoot serving any static content.
mck- has been maintaining the heroku common lisp webapp.
https://github.com/mck-/heroku-cl-example/tree/
The problem with Common Lisp's "networking" is, we don't have sockets in CL standard, so each implementation has it's own socket API. We have some attempts to give a common interface though, like usocket. You can find a list of networking related packages here.
If you need a web framework, look into Caveman. I haven't used it yet but it looks like the most complete CL web framework I've ever seen.
There is Gambit Scheme, MIT Scheme, PLT Scheme, Chicken Scheme, Bigloo, Larceny, ...; then there are all the lisps.
Yet, there's not (to my knowledge) a single popular scheme/lisp on LLVM, even though LLVM provides lots of nice things like:
easier to generate code than x86
easy to make C FFI calls
...
So why is it that there isn't a good scheme/lisp on LLVM?
LLVM provides a lot, but it's still only a small part of the runtime a functional language needs. And C FFI calls are uncomplicated because LLVM leaves memory management to be handled by someone else. Interacting the Garbage Collector is what makes FFI calls difficult in languages such as Scheme.
You might be interested in HLVM, but it's still more than experimental at this point.
For CL: Clasp is a Common Lisp implementation on LLVM, and mocl implements a subset of Common Lisp on LLVM.
For Scheme: there's a self-hosting Scheme->LLVM demo and a prototype LLVM backend for Bigloo Scheme.
For Clojure: there's Rhine, which is a Clojure-inspired lisp.
There's a very small and apparently unoptimised Scheme compiler here:
http://www.ida.liu.se/~tobnu/scheme2llvm/
Taking your question literally,
Writing compilers is hard.
A poor implementation like the one linked above can block new implementations. People going to the LLVM page see that there's a Scheme already, and don't bother writing one.
There's a limited number of people who write and use Scheme (I'm one, not a hater, btw).
There are lots of existing Scheme intepreters and compilers and there's not a screaming need to have a new one.
There's not an immediate, clear benefit to writing a new interpreter using LLVM. Would it be faster, easier, more flexible, better in some way than the other dozens of Scheme implementations?
The LLVM project went with another language (C) to demo their technology, and haven't seen a need to implement a lot of others.
I think that it could be a lot of fun for someone to build an LLVM-based Scheme compiler. The Scheme compilers in SICP and PAIP are both good examples.
Maybe I'm completely misunderstanding the question or context, but I believe that you could use ECL, which is a Common Lisp that compiles down to C, and use the Clang compiler to target LLVM (instead of GCC).
I'm not sure what (if any) benefit this would give you, but it would give you a Lisp running on LLVM =].
One thing to keep in mind is that many of these implementations have C FFIs and native-code compilers that significantly predate LLVM.
CL-LLVM provides Common Lisp bindings for LLVM. It takes the FFI approach, rather than attempting to output LLVM assembly or bitcode directly.
This library is available via Quicklisp.
mocl is a compiler for a relatively static subset of Common Lisp. It compiles via LLVM/Clang.
there's not (to my knowledge) a single
popular scheme/lisp on LLVM
Currently, llvm-gcc is the nearest thing to a popular implementation of any language on LLVM. In particular, there are no mature LLVM-based language implementations with garbage collection yet. I am sure LLVM will be used as the foundation for lots of exciting next-generation language implementations but that will take a lot of time and effort and it is early days for LLVM in this context.
My own HLVM project is one of the only LLVM-based implementations with garbage collection and its GC is multicore-capable but loosely bound: I used a shadow stack for an "uncooperative environment" rather than hacking the C++ code in LLVM to integrate real stack walking.
There is a Scheme2LLVM, apparently based on SICP:
The code is quite similar to the code in the book SICP (Structure and Interpretation of Computer Programs), chapter five, with the difference that it implements the extra functionality that SICP assumes that the explicit control evaluator (virtual machine) already have. Much functionality of the compiler is implemented in a subset of scheme, llvm-defines, which are compiled to llvm functions.
I don't know if it's "good".
GHC is experimenting with a scheme backend and getting really exciting preliminary results over their native code compiler. Granted, that's haskell. But they've recently pushed new changes into LLVM making tail calls easier IIRC. This could be good for some scheme implementation.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
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?
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:
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, R5RS, 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 (now Racket) platform includes a fairly decent interpreter and compiler, is good for scripting, and also has some visual tools that make it excellent for learning.
Common Lisp. Probably the most portable and comprehensive variant, 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.
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.
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.
2018 Update
It's been almost a decade since I wrote this post and the Lisp family of languages now appears to be gaining significant traction in the general programmer consciousness. Much of this appears to be related to Clojure which has not only become a properly separate dialect of Lisp in its own right, introducing many of its own good ideas, but also now has a near-identical version targeting JavaScript and has inspired many other Lisps targeting other platforms. For example, Hy targets the CPython AST and bytecode, aiming first for interoperability with Python, but using Clojure ideas "when in doubt." (Though from the latest commits, the latter may be changing a bit.)
The big change this brings in your decision-making process is that you should also be looking at whatever Lisps or Lisp-like languages are available for and interoperate with languages or platforms you already use, be it Perl, Ruby, Erlang, Go or even C++ on microcontrollers.
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.
I can recommend Common Lisp on SBCL. This combination is fast, powerful, mature and well-documented.
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.
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.
I prefer CL, since I like object-oriented programming, and CLOS is the nicest object system around.
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.
LFE (Lisp Flavored Erlang) would be nice. You can have the lisp syntax on top of the Erlang VM.
Was a kind of "loaded" question to begin with but OP probably didn't know about it. Generally, Common and Scheme lispers are like PC and Apple computer "people", they don't mix. Which one is best is probably not as relevant as which one "works" for you. Really, there is not that much difference. Likely a preference for one over the other maybe influenced by which one you learn first. (To me, an empty list should be "nothing", known in CL as NIL, and that makes me a Common Lisper.) I like the integration of SBCL with Slime using EMACS, but SBCL is not for everyone. For one thing, SBCL is very strict. If you just want to "have fun" the GNU clisp is easy and available for virtually every platform.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I develop in Lisp and in Scheme, but I was reading about Clojure and then I want to know, in which cases is better to use it than using Lisp or Scheme? Thanks
This question is impossible to answer. You should use Clojure nearly 100% of the time over CL and Scheme, is what I would say. But that doesn't mean you should listen to me. Others can make a good argument that the opposite is the case.
For me, the syntax and function names in Clojure aesthetically pleasing. Certain Java libraries are invaluable for what I do for data munging and web programming and GUI stuff. Functional programming is challenging and enjoyable. Clojure's flaws are unimportant and outweighed by its benefits in my eyes. Certain intolerable flaws in other Lisps are "fixed" in Clojure, because it's new and it can ignore backwards compatibility. It has a novel and arguably powerful approach to concurrency. The Clojure community is vibrant and welcoming and awesome. All of this says as much about me and what I value as it does about Clojure or other Lisps.
There are libraries for CL and Scheme that don't exist in Clojure or Java. There are people who dislike how Clojure uses too much syntax like [] and {} and want to use parens everywhere. If you want CLOS-style OOP or lots of mutable data structures, another Lisp is arguably better. The JVM is heavyweight, maybe too heavyweight and too much baggage for some people. A lot of Java leaks into Clojure (by design) and this offends some people's sensibilities. The STM and immutable data structures have overheads that make certain things (e.g. number crunching) slower or less elegant. Clojure is new and still rough in certain areas, still rapidly changing and evolving in others. Clojure has yet to pass the test of time, whereas other Lisps already have. Clojure is not a "standard" and some people find a language defined by an implementation to be unappealing. And so on. None of these things matter to me, but they may to you.
This is almost entirely subjective. Which language you should use depends on what you already know, what you are willing to learn, what libraries you want to use, what editors and tools you're comfortable with, what language flaws you're willing to live with and work around and what flaws you can't tolerate, and what helps you get your work done faster, more cheaply, more enjoyably, or achieve whatever your goals are.
Basically, whatever makes you feel warm and fuzzy. Learn them all and then make an informed choice based on your own tastes, and use whichever one you like the best. They're all good.
"Clojure runs on the JVM" means you get the whole cornucopia of Java libraries available. You can make pretty GUIs in Swing, use Apache's Web client or server code, connect a ready-built Sudoku solver... whatever you like.
Another big plus of Clojure is its very polished concurrency support, with about 3 different flavors. If you have a compute-intensive, parallelizable task, Clojure can make it easy. Well, easier.
Update: Another argument. Clojure is pretty strongly functional, so it's a plus if you want to force yourself to think and write functionally.
Clojure should be used when
you need to work with existing java code.
you work with people who are allergic to lisp ("boss, i would like to use a java concurrency library called clojue vs. I would like to re-write this in scheme" [1]
you will be programming for a multi-processor system.
Scheme would be better when:
you need to prove your code is correct. Clojures (call out to java) hinders but does not prevent this.
you are working with people who are allergic to java.
you are developing for a platform with no (new enough) JVM
[1] yes this is a bad bad bad reason. such is the world we live in...
When? As much as possible.
Why? Immutable Data Structures - they really are that good. There are plenty of other reasons too.
ABCL (Armed Bear Common Lisp) and a several of Scheme implementations (KAWA, SISC, ...) are also running on the JVM.
Generally Common Lisp is available in different 'flavors' - ABCL is one of them. Other compile to C, to native code, have extensive development environments or specialized extensions like logic languages or databases.
Clojure OTOH is a new Lisp dialect with emphasis on lazy functional programming and concurrent programming. Its author (Rich Hickey) is a very experienced software developer (he has also written Java and .net interfaces for Common Lisp) and did an excellent job with Clojure. Even though there is some hype around the language, it is worth checking out - it is definitely one of the better Lisp dialects developed in recent years (compared to say Newlisp or Arc).
There are lot's of reasons, some mentioned above. My take is:
The pre-existing libraries. This is such a benefit. I just can't praise this feature enough.
The language is more adapted to the
hardware currently available
(multi-core) and the development
paradigms in use today. It is so much easier to reason about concurrency. The functional aspects are nicer too. You can do functional programming in Lisp, obviously, but it is very easy to break the paradigm unknowingly, unwittingly, and unintentionally.
Cross platform. I run identical
programs on Linux, Windows, and the
Mac. There are lot's of native Lisps
that run across platforms, but
support for all features on all
platforms is a bit spotty and you
constantly have to be on the alert
for things that are missing on one
platform or the other. Likewise,the
libraries you need are not always
consistently supported across
platforms. ABCL and some of the
JVM Scheme implementations have this
consistent support as well, but I
still prefer Clojure because of
point 2.
The nature of the language
community. Let's face it, a lot of
the time the Common Lisp community
is just nasty to deal with. That is
not the case with Clojure at all.
It's easy to get useful help without
the condescension and meanness that
often comes with an answer from the
Common Lisp community. As I have
learned for myself several times,
there is no question so stupid that
you won't get a polite and helpful
reply from the Clojure community.
If I had to find one thing to complain about, it would be IDE support. Maybe it's a question of learning new habits, but it is still easier for me to handle the mechanics of Java development than Clojure. I have tried, and use, Clojure Box, enclojure on NetBeas, La Clojure on Intellij IDEA, and Counterclockwise on Eclipse. They all work fine if you are working primarily from the REPL, but for compilation and execution of class files, they all still feel a bit clumsy.
A subset of Clojure can also compile to javascript
Clojure runs on the JVM (and on the CLR), so there is that.
Clojure's design is concerned with accommodating several styles of concurrent programming safely, deliberately making it difficult to mistakenly write the dangerous, rickety, and often broken concurrency-tolerant code in other languages. If your problem domain involves concurrent programming, Clojure's array of integrated tools for managing concurrency may be a better fit than the implementation-specific or lowest-common-denominator libraries available in other Lisps and Schemes.
One of the greatest things about Clojure is the plethora of libraries you can use with it. You have the power of Java with the expressiveness of Lisp, and that is a badass combination. Clojure is more suited for real world development, because it was made for real world development. With Clojure, you have awesome libraries, awesome modern features, and an amazing community of helpful, like-minded people.
I would have to say that Clojure is a better language, all the way around. That is a highly argumentative statement to make, so I will point out here that this is just my honest opinion.
Clojure rocks.
I'm always trying to learn new languages, so I'm interested in learning Clojure. But, aren't SBCL and some other Common Lisp implementations much, much faster than Clojure? Wouldn't you need considerably more than 4 processors (and a reasonably parallelizable task) to make up for the performance difference between a Clojure app and even a single-threaded SBCL version of the same app?
As a general rule of thumb, I tend to favor Clojure over other languages in cases where either of these fit the bill:
(1). The domain model tends to look very recursive and/or graph-like.
(2). There's an opportunity to leverage a multi-core JVM environment (e.g., Elastic Beanstalk)
(3). There's a fuzzy barrier between data and code (think RPN calculator where nodes can be operators or numbers)
These might sound a bit contrived, but a lot of my work involves dealing with graphs and trees of information, whether it's looking at social networks, some kind of constrained-based optimization, or semantic relationship building. I find that my other favorite language, Ruby, cannot give me the mix of expressiveness and raw computing power compared to Clojure, particularly when it comes to quantitative, recursive, concurrent-type problem solving.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I'm working on a toolkit (sort of a live-CD Lisp-in-a-Box) for people new to Common Lisp, and I want to make sure it is broadly satisfying. What is attractive to you about Lisp? What do/did/would you need to get you started and keep you interested?
What I have so far: SBCL 10.22, Emacs 22.3, SLIME, and LTK bundled together and configured on a Linux live-CD that boots entirely to RAM.
I've now released the result of this; it is available at the Thnake website.
I would include at least cl-ppcre, clx, Hunchentoot, and Weblocks.
I guess that you would have to negotiate with the respective authors, but including "On Lisp", "Practical Common Lisp", and "Successful Lisp" would be a great asset for the CD.
What would be really nice is to use stumpwm as the window manager on your live CD.
Emacs almost prevented me from learning Common Lisp. It took a lot of effort to slog through it. Emacs and SLIME are too much for a beginner and will never be broadly satisfying to beginners. If I want to learn a new programming language, I want everything else to stay out of my way while I learn it. The task of learning Lisp is hard enough without added technicalities and complications of setting up an environment. Isolate the variable.
Set up SBCL with rlwrap or an equivalent. rlwrap supports very basic paren matching and history searching and can even do tab-completion. Not as fancy as SLIME but a beginner doesn't need SLIME. A beginner needs to be able to run hello-world without spending an hour fighting Emacs. Provide Emacs/SLIME as an option but don't require it.
My suggestion is to include an HTTP server like Hunchentoot and a popular web framework. I suspect that most people that want to learn Lisp these days do so because of reading Paul Graham, and wanting to mimic his success at building Viaweb, so being able to easily create and modify powerful web applications would be a strong selling point for your live CD.
Include Emacs, of course, but you might want to have something gentler.
The Lisp environment I found easiest to slip into was Macintosh Common Lisp, with the FRED editor (Fred Resembles Emacs Deliberately). Digitool didn't successfully make it into the current era of Macs, but they open-sourced a lot of their stuff as they folded. Try www.clozure.com or search for "openmcl" on Google.
There was a project to get the Fred environment running on Openmcl, but I don't know the status offhand (I haven't done anything with Lisp in a long time, and haven't been paying attention on the mailing lists).
So, my recommendations:
Ask Paul Graham if you can include "On Lisp". Since he's giving away a download for free, the odds are good that he'll give permission. (His other excellent Lisp book, "ANSI Common Lisp", is apparently still selling, so it's unlikely he'll give you permission there.)
At least check out the MCL stuff to see if there's anything you can find to make it easier. Emacs is a great Lisp environment, but it's a bit intimidating for the beginner.
I haven't looked at the SBCL documentation lately. Is it fairly readable and beginner-friendly? Perhaps somebody could write up some quick instructions on how to get going and how to debug. Emphasize mouse use at first, even if using Emacs.
What would really get me interested in Common Lisp is a modern set of libraries at the level of .net or Java, as well as some really good documentation that isn't gnarly.
In terms of software, a nice gui editor along the lines of notepad++ or jEdit would be good. Emacs/vi & text-based editors always seems quaint and antiquated for serious development.
Reading Paul Graham makes me want to learn Common Lisp. But if I actually sit down to try learning it, the urge subsides.
Everything in clbuild (http://common-lisp.net/project/clbuild) should be a good candidate to be included. Incidentally, all packages in your list except Emacs are also managed by clbuild. I think it'd be good if the collection of projects in clbuild could gather some momentum towards standard-common-lisp-library-hood.
This does:
http://www.joelonsoftware.com/articles/ThePerilsofJavaSchools.html
Of course I'd also like to learn more Python 3.0, erlang, and F#. I believe that functional languages (not to say that Python is a functional language) provide just a different perspective. The more perspective you have the better solutions you can architect. It is all about using the right tools for the job too, but if you don't at least have familiarity with something you might never think to solve a problem with a particular tool. I guess it goes back to the old saying that to a carpenter everything looks like a nail. I do not want to be hammering C# into everything when there are better solutions available. Also, times change and fads do with them.
Emacs does have a bit of a learning curve, but it is great for serious development -- no pesky mouse-driven gui bling in the way of the (text-based) code.
Out-of-the-box CUA-mode is enabled these days (so C-x, C-c, C-v works "standard"), and there is a menu with file-operations like save, etc, so it shouldn't that hard of a slog, if it's all pre-packaged. But pre-configuring the .emacs file to ensure that CUA mode is enabled, SLIME doesn't have to be configured by the user etc. is a must -- plus perhpas more documentation within for the user for .emacs configs - links to EmacsWiki, etc. (hrm, if this is on a CD, it's unlikely that the user would be configuring it themselves, isn't it....)
I have some interest in learning Lisp, but I don't 'like' most of the resources available. How about extending this project to the creation of some sort of a "community" responsible for providing tutorials or something, in order to make Common Lisp more popular and easier to learn? Bad/weird/useless idea?
I think the idea of including tutorials is an excellent one.
In addition to the ones already stated, there is both the easiest book for newbies on lisp (A Gentle Introduction to Symbolic Computation) and several excellent websites hiding out there on the web that people should know about. Here they are:
A Gentle Introdiction to Symbolic Computation
Learning Lisp
Casting Spels
Learning Lisp Fast
As far as I undertand you are doing Thnake.
Thank you for greate live distro!
I tried it couple of days before and found it rather impressive and interesting.
There are couple of things it obviously lacks, such as LTK since you have already included Common Lisp and Tcl/Tk. And since there is gtk, you can include bindings and documentation for CL and Python.
Also there is a need in Lisp Hyperspec, and preconfiguaration of Slime to use it. (Same for documentation for Python and Tcl) May be it would be better to add emacs-w3m for fast and convenient documentation browsing.
There's always Practical Common Lisp, a book on Common Lisp which is readable in its entirety online. There's also a packaging of Emacs with a CL implementation meant for using along with the book.
You should definitely add Vim too, configured with the RainbowParenthsis plugin.
rlwrap for SBCL is a good idea, and so is (require :sb-aclrepl).
Weblocks should come with cl-prevalence and maybe Elephant/BDB, too.