4 ms·

That's a very complicated question. Common Lisp has many implementations, with different strengths and weaknesses. For example SBCL and CCL are good general pur

That's a very complicated question. Common Lisp has many implementations, with different strengths and weaknesses. For example SBCL and CCL are good general purpose implementations. They're fairly performant, especially SBCL, properly optimized code can compete for C-like performance. ABCL gives you Java integration, not as nice as clojures for example, but perfectly usable IMO. ECL has a fairly small footprint and is good for embedding, it can also compile down to C I think. Clasp is a newcomer to the Common lisp world, it compiles to LLVM and provides C++ integration. It's creator uses it for chemistry and nanotech simulations, so he has many C++ libraries he wants to use with Lisp, so he wrote an implementation. There are also commercial offerings(LispWorks, Allegro CL) that come with additional support and their own graphical IDEs. When I switched from Clojure to Common lisp a few years ago, mostly I really like using multi-paradigm languages. Clojure code wants to be functional. Common lisp code has no such preference, and with the excellent OOP support it's a pleasure to use. Basically it's generic function based, rather than class based, which means that your methods are owned by your generic functions, rather than your classes. This gives you much more flexibility and power than "standard" OOP. I can write software in the style that best supports the problem I'm trying to solve. Other great features include the condition system, basically exceptions on steroids. Very few languages have something similar. Another one of my favorite features is that the standard has been stable for decades. The core language hasn't changed since 1994, so the ecosystem continues to evolve constantly, but the core stays stable and it isn't unheard of for code written in the 80's to run with little or no modifications. I like the idea that my code might have that kind of longevity. I could go on, but you get the general idea of having an extremely mature and stable language with many implementations that all try to solve different problems, with sufficient portability that fragmentation doesn't tend to happen(like in the scheme world for example). And personal taste of course, It's just a pleasure to use for some reason. I don't know why, but I'm just having way too much fun playing with it and trying to explain it to others.

haspok 10y ago
Thank you for the detailed answer, I think you could expand on it and include it in your book as an introductory chapter, or even as a blurb (especially the second paragraph).
mikelevins 10y ago
Speaking as a longtime (nearly 30 years) Common Lisp programmer, I agree with what you've said here, but I would add one thing more. Common Lisp is one of a small number of languages that represent an approach to programming that is so out of fashion nowadays that it seems to be in danger of becoming extinct. The approach is one that treats programming as an exercise in interactively shaping a living thing in real time, rather than building an artifact from a blueprint. Programming-as-construction is the mainstream; Common Lisp and a small handful of other languages represent a different approach that we might characterize as programming-as-teaching. Common Lisp and some older Lisps, along with Smalltalk and FORTH, treat programming as an ongoing interaction in which your main program is already running before you ever write any code. It's running, but it doesn't yet know how to be your application. You have to teach it. This you do incrementally, one small change at a time, gradually guiding and shaping the running program until, eventually, it becomes your application. It continues to run throughout the entire process; it just changes its behavior as you teach it new capabilities. Common Lisp (and a few other languages) are designed with this approach to programming squarely in mind. Consider, for example, the standard Common Lisp functions CHANGE-CLASS and UPDATE-INSTANCE-FOR-REDEFINED-CLASS. In most languages these functions make very little sense. Once you understand how Common Lisp is designed to be used, it's obvious that they are necessary. They're necessary because obviously you're going to redefine classes as you progress, and obviously you don't want your running application to fail simply because you've redefined its types out from under it. So the language is designed to support that way of working. It provides facilities for gracefully handling the situation that arises when you redefine types out from under your code, and it gives you ways to ensure that the program keeps running as you make those changes. This way of working is now sufficiently out of fashion that even new Lisps don't necessarily support it. Clojure isn't great in this area. Neither are some Schemes. Common Lisp and Smalltalk are the strongest remaining bastions of programming-as-teaching, as far as I can see. Almost everywhere else in programming today, tools and languages uncritically assume the programming-as-construction model. Maybe that's okay. There's certainly good work being done in that mode. Programming-as-teaching is my native idiom, though. I'd guess that I'm somewhere around ten times more productive when working that way. That doesn't mean it's a better way, of course; it just means it's better for me. Nevertheless, I can't help but mourn when I think that maybe programming-as-teaching is disappearing from the world.

haspok 10y ago

Thank you for the detailed answer, I think you could expand on it and include it in your book as an introductory chapter, or even as a blurb (especially the second paragraph).

mikelevins 10y ago

Speaking as a longtime (nearly 30 years) Common Lisp programmer, I agree with what you've said here, but I would add one thing more. Common Lisp is one of a small number of languages that represent an approach to programming that is so out of fashion nowadays that it seems to be in danger of becoming extinct. The approach is one that treats programming as an exercise in interactively shaping a living thing in real time, rather than building an artifact from a blueprint. Programming-as-construction is the mainstream; Common Lisp and a small handful of other languages represent a different approach that we might characterize as programming-as-teaching. Common Lisp and some older Lisps, along with Smalltalk and FORTH, treat programming as an ongoing interaction in which your main program is already running before you ever write any code. It's running, but it doesn't yet know how to be your application. You have to teach it. This you do incrementally, one small change at a time, gradually guiding and shaping the running program until, eventually, it becomes your application. It continues to run throughout the entire process; it just changes its behavior as you teach it new capabilities. Common Lisp (and a few other languages) are designed with this approach to programming squarely in mind. Consider, for example, the standard Common Lisp functions CHANGE-CLASS and UPDATE-INSTANCE-FOR-REDEFINED-CLASS. In most languages these functions make very little sense. Once you understand how Common Lisp is designed to be used, it's obvious that they are necessary. They're necessary because obviously you're going to redefine classes as you progress, and obviously you don't want your running application to fail simply because you've redefined its types out from under it. So the language is designed to support that way of working. It provides facilities for gracefully handling the situation that arises when you redefine types out from under your code, and it gives you ways to ensure that the program keeps running as you make those changes. This way of working is now sufficiently out of fashion that even new Lisps don't necessarily support it. Clojure isn't great in this area. Neither are some Schemes. Common Lisp and Smalltalk are the strongest remaining bastions of programming-as-teaching, as far as I can see. Almost everywhere else in programming today, tools and languages uncritically assume the programming-as-construction model. Maybe that's okay. There's certainly good work being done in that mode. Programming-as-teaching is my native idiom, though. I'd guess that I'm somewhere around ten times more productive when working that way. That doesn't mean it's a better way, of course; it just means it's better for me. Nevertheless, I can't help but mourn when I think that maybe programming-as-teaching is disappearing from the world.