I'm not too knowledgable about lisp, but what should I focus learning, Clojure or Steel Bank ? If I understand properly, SB Common lisp doesn't run on a VM ... ?
FYI, your question reads roughly like "I'm not too knowledgable about C, but which should I learn, Java or g++?"
There hasn't been a single language called "lisp" for at least 30 years. Lisp is now used to describe an entire family of language based upon syntax similarities.
Common Lisp is one language, Clojure is another. Steel Bank is an implementation of Common Lisp (like g++ is an implementation of C++). The two languages are about as similar as C++ and java, that is to say the syntax is quite similar, and they share some conceptual history, but to someone who knows either, the differences are greater than the similarities.
Now, to actually answer your question, I use common lisp (mostly SBCL, but also some other implementations) a lot and like it quite a bit. I can suggest http://gigamonkeys.com/book/ as a good start for learning it.
Also #lisp or #lispcafe on freenode are good places to ask questions.
The best choice depends on your reasons for learning Lisp. If it's to work through Structure and Interpretation of Computer Programs or just learning in general, then Racket is the way to go. Teaching Lisp is embedded in its culture.
On the other hand, if you are hard core all day with the JVM, then Clojure. But I would not recommend Clojure as a first Lisp. Its community is very much organized around being a better JVM language, somewhat around teaching people Clojure in that context, and not really around introducing people to Lisp. It's more about providing Lisp to the JVM programmer and JVM to the Common Lisp programmer.
As for learning Common Lisp, if you're plan is to work your way through Graham's On Lisp or Hoyte's Let Over Lambda then it makes sense.
Of course any of them make sense if it's for work.
I'd never suggest it as a good starting point for learning Lisp. Clojure's design inherits some implementation details from Java and the JVM. ClojureScript has amother layer of limitations based on ECMAscript's specification. They make sense If one understands Clojure as a response to the JVM and has a similar understanding of JavaScript's specification. Without that it's going to be hard to have an intuitive feel for the ways in which it's been ported. And given its lack of standalone documentation the a programmer is even more on their own.
Personally, I haven't found Clojure to be an improvement over Common Lisp. Java interop is not important to me, so the only benefit of using Clojure over Common Lisp is better-looking library websites.
Last I checked, clisp had the best math performance as far as the lisp numeric stack for open-source lisps (obviously something like maxima is different). The best numeric benchmarks for sbcl all seem to be FFI to gmp (which happens to be the library used by clisp).
CLISP doesn't use GMP; it has its own, very nice, bignum library. If you want to use GMP on SBCL, the SB-GMP contrib has been around for approximately one year; it'll hook transparently in SBCL's bignums, at runtime. However, I think the grandparent was referring to performance on typical numerical computing workloads: machine integer or floating point arithmetic, mixed with a fair amount of array indexing.
I guess the reason there is not too much new CLISP development going on is that it's really a mature product. The ANSI standard of Common Lisp was published in 1994 and there was no amendments or additions since then. CLISP has implemented it awhile ago. Also, CLISP is written in C and doesn't compile to machine code like, for example, SBCL, so no need for an extra work to target new platforms. Again, that's my guess.
I suspect it's more a lack of resources (time, energy, interest) than maturity. CLISP has bugs. Some bugs are fixed in version control. It would be nice to have a new release.
