7

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)?

Improve this question
3
  • 2
    Funny question for Lisp, the programmable programming language.
    – BenjaminB
    Jul 29, 2012 at 13:13
  • 3
    @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, 2012 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, 2012 at 8:13

2 Answers 2

Reset to default
8

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).

Improve this answer
9
  • "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, 2012 at 15:03
  • 2
    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, 2012 at 15:14
  • 2
    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, 2012 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, 2012 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, 2012 at 16:36
7

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

Improve this answer
4
  • 2
    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, 2013 at 8:21
  • 1
    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, 2013 at 17:48
  • @Giorgio The differences in implimentations matter if you need to use sockets, threads, unicode, or any non-basic use of the filesystem. Things that weren't standardized at all, probably because they didn't matter that much in 1994, but are used in most non-trivial applications. Compatibility libraries insulate you from most of the compatibility issues, but not all.
    – Thayne
    Sep 30, 2015 at 1:25
  • @Thayne: Thanks for the information. I can live with that: I do not expect I will be switching implementation all the time (using SBCL at the moment). Unfortunately, since at work I use other languages, I haven't been able to work on any complex project in CL yet (only small tools a few hundred lines in size), so I did not encounter many non-standard features yet. Probably the way in which they handle command-line arguments was the only one.
    – Giorgio
    Sep 30, 2015 at 15:20

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.