FYI, SBCL is a high-performance open source compiling implementation of Common Lisp. All SBCL code is either released into the public domain or available with the FreeBSD license. Rumor has it that the next release of SBCL will support calling SBCL from Java on Android.
Some people care about performance, and ABCL is nowhere near SBCL in this regard.
I also don't know if ABCL's compiler is offline (generating class files from CL code) or on-demand (likely using OW2 ASM). While it is no longer impossible to do, it remains tricky to generate Dalvik bytecode at runtime, and the performance hit is significant (look at Clojure on Android).
From what I've gathered, it's run in production, just not the production environments this community usually hears about. There is pretty much no web ecosystem in Common Lisp, which is what I'm trying to fix, but in other domains it fits just fine.
I noticed that ARM binaries aren't yet provided. Does this just mean they haven't gotten around to it yet or that ARM isn't suitable for production at this time?
I'd really like to experiment with SBCL on the beaglebone. :)
ARM systems are so diverse that, unless you define a specific operating system, ABI plus floating point calling convention, and CPU type (see http://blog.alexrp.com/2014/02/18/android-hard-float-support... for a tangentially related example I found in a quick search), a binary either doesn't do you any good, or doesn't take advantage of the SIMD CPU features of your platform.
There is currently only working support for VFP hardware floating point in SBCL so the build options are reduced a bit. I think the only choice to make for a binary release would be whether to build against Debian, Ubuntu or something else.
I can't answer authoritatively, but I do know they're not really good at updating the downloads page for anything other than AMD64 Linux and the source tarball (and of course the Git repo). Usually I just build from source.
The catch, of course, is that building from source requires a pre-existing SBCL to bootstrap.
My guess is the only way to get it running on ARM right now is to get it for a non-ARM platform they have for download, bootstrap to 1.2.0, and then cross compile to ARM.
One of SBCL's claims to fame is that it doesn't necessarily require a previous copy of itself to bootstrap; it can in theory use CLISP or Clozure CL. (In practice it isn't always tested and working, and I don't know if it would work on ARM if you tried it today.)
Regarding building from source requires a pre-existing SBCL to bootstrap, it is actually true that building from source requires a pre-existing Lisp to bootstrap.
Yay, good news. By the time Apple uses ARM instead of Wintel CPUs for OS X, I hope that SBCL will be ready for ARM in at least the same quality it now has for x86_64.
BTW, are there any comparisons between SBCL's “Python” compiler and an LLVM backend (mocl seems to have one)?
I haven't seen any published mocl performance data. One significant difference between the two is that SBCL's compiler is online (available at all times) whereas mocl's is only available on the development machine. So mocl is an implementation of Common Lisp the language, but not a complete Common Lisp environment.
I browsed through Common Lisp GitHub repos, but it didn't really answer my question. Are there any known, much used applications, frameworks, libraries, whatsoever? Something to see the structure of big projects? Something that possibly shows there are also bigger companies interested into LISP?
Sure, check out pgloader (this guy re-wrote a Python program into Common Lisp and wrote about the experience), the European Lisp Symposium ( http://www.european-lisp-symposium.org/content-programme-ful... ), it's used by Google (ITA, air fairing system), it was used by Naughty Dog for their PS1 and PS2 games (they still use Lisp for scripting), it's been used by NASA, DART ( https://en.wikipedia.org/wiki/Dynamic_Analysis_and_Replannin... ), Cyc, there's a European company I can't remember the name of that uses Common Lisp for its train scheduling system. There's this new Swedish music company that uses Common Lisp for their software.
If you want to see much used applications in the Common Lisp community then check out all of Edi Weitz' software http://weitz.de/
Most Common Lisp that you use is in stuff you don't see, there're no Ruby hipsters here.
EDIT: Oh, or why not something like StumpWm? Really, thre's a lot of cool Common Lisp software out there.
I mean "interesting" in the sense that those were areas of active research and development. I think the equivalent today would be things like control software for self-driving cars and drones, the software that does StreetView, etc.
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.
