Take the 2-minute tour ×

I have been reading a bit about Common Lisp and I am considering trying to learn it (I only know very basic concepts) or even using it for some project.

Question: how stable is Common Lisp as a language? What I mean is, regardless of new libraries, are new language features (involving new syntax and semantics) being added to the language? In other words, if I learn Common Lisp now, would I be able to use the same language in 10 years from now, or read code that was written 10, 20 years ago (apart, of course, from having to get familiar with different libraries and API's)?

share|improve this question
Funny question for Lisp, the programmable programming language. –  Ubiquité Jul 29 '12 at 13:13
@Ubiquité: Well, there is something to this question. I am a bit frustrated with other languages because a new revision with completely new features comes out every 5 years. It seems that these languages never reach maturity, they are like moving targets and I have to learn them again and again. I know very little about Common Lisp, but if the programming language can be extended within itself (language extensions are actually libraries) then I guess that the core language is quite mature and stable. So again, has the syntax and semantics of Common Lisp changed much over the decades? –  Giorgio Jul 29 '12 at 13:24
Regarding the vote to close: what is being asked is whether Common Lisp is standardized and stable so that programs written today use the same syntax and semantics as programs that were written 20 years ago. More precisely: can a Common Lisp compiler used today compile Common Lisp code written 20 years ago "as it is" / without modifications? Similarly, can I reasonably expect programs I write in Common Lisp today to compile without modifications to the source code in 10 or 20 years from now? –  Giorgio Aug 2 '12 at 8:13

2 Answers 2

up vote 8 down vote accepted

There is the ANSI Common Lisp standard and the Common Lisp Hyperspec. It's generally reasonable to assume that standardised languages will stay relatively stable and that most new language additions will be consistent with the standard / not break existing code.

Of course, one of the powers of Lisp is that you can extend the language almost arbitrarily, so there's quite a possibility that some new libraries or DSLs will look completely different from any other previous Lisp code. That's just a danger of the meta-programming territory. But the core language itself is likely to stay pretty stable.

If you are interested in Lisps in general as opposed to Common Lisp specifically, I'd also recommend you check out Clojure (a modern, pragmatic, functional Lisp) and Scheme (a very clean, elegant Lisp ideal for learning).

share|improve this answer
"there's quite a possibility that some new libraries or DSLs will look completely different from any other previous Lisp code": in the context of this question I do not consider adding a new library as an extension to the language, i.e. the syntax and semantics of the language stays the same, I just have a new API that I can use. Compared to this, e.g., the proposed lambdas in Java are a new language feature with additional syntax and semantics: this is radically different from adding / creating a new Java API. –  Giorgio Jul 29 '12 at 15:03
I have been playing with Scheme (MIT-Scheme) as well. I am trying to port a small project I have implemented in C and in Java into both Common Lisp and Scheme. I find this a good way to learn: to use a language to solve a concrete problem. I get more and more the impression that Lisp is based on a few concepts and that the rest of the language and libraries are built on top of this small and rather stable core. I like the idea a lot, it makes me want to invest more time on it. –  Giorgio Jul 29 '12 at 15:14
I believe "modern" is exactly what original poster wants to avoid (Clojure has a couple of changes compared to classical Lisp) and while Scheme is self-consistent and cleaner, it also did change a bit (e.g. r5rs replacing CL-style macros with the hygienic ones) in the past and seems to have far fewer libraries. And it's libraries that make a good language these days. –  Jan Hudec Jul 30 '12 at 8:10
@Jan Hudec: I know that there are different dialects of Lisp. My question refers explicitly to Common Lisp. I am considering it as a possible "career language", i.e. as a language I would try to learn in depth so that I can use it over several years and several projects. –  Giorgio Jul 30 '12 at 16:17
@Giorgio - good for you, and Lisp is certainly a very fine choice. However stability of language would be way down my list of decision criteria. Library ecosystem, strength of community, openness, level of innovation and pragmatic effectiveness in real projects would seem much more important to me. YMMV. –  mikera Jul 30 '12 at 16:36

The first edition of the book Common Lisp The Language, written by the lispers at CMU (Carnegie-Mellon University)[1] and published in 1984, served as a basis for ANSI Common Lisp the standard. The second edition (published in 1990) reflected the current state of the standardisation process that was still ongoing.

In 1994, the ANSI Common Lisp standard was finally published. It differed in certain ways from the dialects described by the two editions of Common Lisp The Language but acknowledged the practical importance of both editions by suggesting that the keywords :cltl1 and :cltl2 be included in the *features* list, allowing for conditionals to be added to code that must interoperate between ANSI Common Lisp and these other two dialects.

CLTL1 (as it is known) is ancient history today and most, if not all, implementations have settled on something somewhere in between ANSI and CLTL2. However, the ANSI standard suffered from a bigger problem that had nothing to do with the language per se; it failed to address one or two important practical aspects of everyday programming and discrepancies arose in the way implementations addressed these practical needs. As a result of this (not the minor language differences between ANSI and CLTL2) lispers talk toady about portable versus non-portable code.

So, to summarise, the core language (the fixed set of 24 special forms[2] which every implementation must include if it wants to call itself Common Lisp) is absolutely rock solid and cast in stone, but practical shortcomings in the ANSI standard have lead to discrepancies in the way implementations make up for them.

[1] SBCL builds on the original CMU code base, hence the name Steel Bank Common Lisp. (Carnegie was a steel magnate and Mellon was a Wall Street financier).

[2] Common Lisp special forms

share|improve this answer
I visited this question again after a few months. Thanks again for your informative answer (I have upvoted it and IMO it would deserve more upvotes). I get the impression that the differences in implementations only start to matter when you are and experienced lisper. It will take me a while to get to that level though. :-) –  Giorgio Mar 15 '13 at 8:21
I have recently installed 5 open source Common Lisp implementations (ABCL, CCL, CLISP, CMUCL, SBCL) and, with each of them, I have installed quicklisp and used it to install slime. I was impressed that all 5 implementations ran out of the box and worked smoothly with quicklisp and slime. I am a newbie with Common Lisp but these experiments make me want to learn more. –  Giorgio Apr 21 '13 at 17:48

Your Answer


