Lisp is a family of programming languages with a long, rich and oftentimes confusing tradition. Unware of it at the time, in 1960 John McCarthy published a paper that over the next 64 years would spawn a thousand dialects and a number of very good ideas.
The fragmentation of the Lisp family from an outside perspective can seem really confusing to newcomers, like a software Tower of Babel. In fact the variety of Lisp is in my opinion one of it's best qualities. It almost guarantees that as long as you can overcome the (relatively) small barriers of the paren-heavy syntax and prefix notation that there will be a dialect and community that closely mirrors your philosophy on software development.
The purpose of this post isn't to convince the reader of how great Lisp is; rather, I assume the reader is already somewhat interested and is now trying to figure out which of these dialects is the best fit for them. It also isn't about "which Lisp is the best" type questions, but instead it's just my subjective view of the more prominent Lisp dialects. The most prominent dialects being Scheme, Common Lisp, Racket, Clojure and Emacs Lisp.
Tl;dr:
If the reader isn't already convinced but is still curious, I would recommend reading the following articles:
I mentioned earlier that Lisp's variety is one of it's best qualities, and I stand by that. A side effect of this however is that inter-dialect tribalism is unfortunately common. It's a weird reality that the smallest of differences seem to incite the most vitriol, whether it's with programming language dialects or Northern Conservative Baptism. As an example, of the four mentioned dialects I'll be talking about I've heard three of them being argued as not-actually-lisps. Can you guess which ones?
Not to leave on a sour note, Lisp also attracts some of the most thoughtful and intelligent people whose willingness to openly share their knowledge has changed me for the better.
A quick aside. It can be hard to understand the design decisions made by Lisps without knowing at least a bit about their evolutionary history. Why do humans get goosebumps? Why is Emacs Lisp dynamically scoped? The best way of getting a sense of how Lisp has evolved is to reference the numerous papers written at various times.
This isn't at all necessary to picking up a Lisp by the way, I just think it's neat.
Scheme is a minimalist Lisp created at MIT in the 70's by Guy L. Steele Jr. and Gerald Jay Sussman. It began as a series of papers, then eventually a report, and subsequently evolved as revisions to the report were made.
The minimalism of Scheme makes it well suited both as a teaching language and an embedded extension language in other programs. Scheme's minimalism also makes it attractive to Lisp implementers, and as a result there is a rich ecosystem of Scheme compilers and interpreters.
I've quite the soft spot for Scheme - it was the first Lisp I learned via SICP, and the programs I've written and read tend to have an elegance that's hard to find elsewhere. There are few programming languages I would describe as beautiful but Scheme is definitely in that list (pun intended).
Scheme's notable for a few different reasons:
Despite the simplicity of Scheme itself, everything else around it can seem complicated and daunting at a first glance. The next few paragraphs are what I would consider essential context.
The 'Revisedⁿ Report on the Algorithmic Language Scheme', (typically abbreviated RⁿRS) is the de-facto Scheme language specification. As of now there is 1 original report and 7 revision documents. I suppose technically 8 revisions given the most recent revision has been split in two. The most commonly talked about standards are also the most recent: R5RS (1998), R6RS (2007), R7RS-small (2013) and R7RS-large (ongoing). As mentioned previously R7RS is divided into two parts: "...a small language primarily for embedding, education, and research; and a large language to address the practical needs of mainstream software development."
Now this is where things start to get a little hairy. R6RS was (or is) very controversial in the Scheme community for various reasons that I wont get into here, but to quote Gwen Weinholt's summary from their post on the topic:
R6RS is more demanding on implementers but easier on users. Conversely, R7RS is easier on implementers but more demanding on users.
This unsurprisingly resulted in more implementations supporting R7RS than R6RS.
Another important thing to understand about Scheme are "SRFIs" (Scheme Requests for Implementations). Due to Scheme's inherent minimalism and many implementations, coordinating library proposals became essential for writing portable code. There are a bunch of SRFIs and each Schemer will typically have a set of them they commonly use.
So between RnRS's, SRFIs and a smorgasbord of implementations we find ourselves in a weird position.
Due to this complexity and the challenges the R7RS-large working group have faced when reaching agreement, it's not unusual to see expressed the feeling that Scheme as a standard is dying. I'm not sure I fully believe this myself but only time will tell.
If you're new to Scheme don't let this discourage you for a second. The trick is to not think about it too much; it's perfectly fine to pick an implementation and just start having fun hacking.
One last thing - Scheme's minimalism makes it great for embedding as an extension language in other programs. See Chibi-Scheme for an example of this.
The writings and videos below are either explicitly about Scheme or incidentally use Scheme as a teaching tool.
Classics:
There are a lot of high quality Scheme learning resources online, many of them free too.
Misc:
Scheme has a relatively small but dedicated community. If you're coming from a more popular language like JavaScript it might surprise you that discussions usually happen over days instead of minutes. This is perfectly normal.
If Scheme is often seen as minimal and academic, Common Lisp in contrast could be considered robust and industrial. Their histories play a significant role in this perception and the history of Common Lisp is quite an interesting one - the curious reader can find out more about it here. Summarising the best I can, in the early 80's Lisp was highly fragmented. ARPA weren't that interested in funding multiple projects with incompatible Lisp implementations, so they brought the kingdoms together and from this meeting grew the idea of a common Lisp to rule them all. To this day if someone directly refers to "Lisp" but not in the broad language-family sense, they're probably talking about Common Lisp.
Common Lisp (CL) was ANSI standardised in 1994 and since then has remained remarkably stable. If I needed to write a piece of software I knew wouldn't give me hassle in 30 years I'd choose Common Lisp. This level of stability is almost unthinkable to a great deal of software developers.
Something to note: just because CL is stable doesn't mean it's stagnant. There has been a great deal of effort spent on improving the many Common Lisp implementations, improving the library ecosystem, improving the tooling etc. If you're coming from a larger and faster moving ecosystem don't be surprised when you see libraries that were last updated 10 years ago. They're not dead, they're just sleeping - if you wake them up they'll work just as well as the day they were written.
I mentioned previously that Common Lisp has many implementations, but the most prominent of them is probably Steel Bank Common Lisp (SBCL). SBCL is great, and here's why:
I'm not here to evangalise SBCL but it really is an awesome tool.
Something worth mentioning is programming style. Lisps in general are often described as being "functional" languages and this (especially historically) is a huge misconception. Common Lisp is incredibly unopinionated and leaves it entirely up to the programmer to choose how they want to use it. Want to write heavily procedural code? Great! More of a functional programmer? That's awesome too. Huge OOP fan? The Common Lisp Object System (CLOS) is one of the most sophisticated and robust out there.
Despite not considering myself a Common Lisper, it's a fact that some of the most eye-opening books written about Lisp use Common Lisp as their mode of teaching.
Common Lisp has a pretty small yet dedicated community. From what I've seen from an outside perspective, there's quite a few regional Common Lisp groups dotted around the world. A first step would be to see if there's any in your area.
Clojure is the most recent of the language discussed so far, and since its appearance in 2007 has spawned a sort of mini-renaissance of renewed Lisp interest. It's also the Lisp I'm most fond of for my own personal projects.
Here's some points that set Clojure apart:
Something else that sets Clojure apart is that its creator, Rich Hickey, is still heavily involved in the language and its community. This is in contrast to other Lisps which tend to be much more committee and community driven. In the Clojure community you'll see frequent reference to Rich's talks of which there's a good few. They're all worth watching in my opinion.
Oh, and there's also ClojureScript. It's Clojure that compiles to JavaScript - I haven't used it much but if that interests you, go for it.
Clojure has quite a lot written about it. I'd typically just recommend looking around until you find a resource that matches your tastes.
In my opinion, there's not a whole lot of really interesting Clojure talks other than the handful from Rich.
I'd wager a guess that Clojure is the most popular of the Lisps out there, making it fairly easy to get into the community.
Racket is an interesting one. It's a dialect of Scheme that began in the mid-90s and developed by PLT Inc (which was founded by Matthias Felleisen). Its main goals were as a tool for teaching and as a playground for programming language research and development - to these ends it's by all means a great language. It's often said that Racket has one of the most powerful macro systems amongst the Lisps, and as proof more than a few postgrads have earned their PhDs using it.
Up until very recently, Racket was a significant part of Northeastern University's "Fundamentals of Computer Science" cirriculum. This is now apparently being phased out in favour of another course that primarily used Python, to mixed reception. I don't personally have an opinion, but it is interesting to note that this is effectively the same thing that happened to MIT's introductory 6.001 course. I've another blog post brewing about Universities becoming trade schools, but that's for a different day.
There's a very surprising amount of Racket talks - probably because it's a playground for programming language experimentation and people are excited to share what they've did. It's not something I've really dived into, so here's a few starting recommendations.
Emacs is probably the most unusual platform/Lisp that I'll be talking about. Emacs is technically a family of text editors with the most popular being GNU Emacs. There are other prominent variants/forks that I wont get in to, so going forward if I refer to "Emacs" I really mean "GNU Emacs".
Emacs was started in 1984 by Richard Stallman who was looking to create a free software alternative to the proprietary Gosling Emacs. What sets Emacs apart from other editors is how extremely exstensible it is - writing plugins and changing the editor's behaviour is trivially easy using the built in Emacs Lisp programming language. The price you pay for this power is the steep learning curve, one which I've never really been able to scale. Emacs isn't for everyone.
If you know nothing of Emacs it probably sounds fairly uninteresting so far. It's an editor with a scripting language, so what? With how extensible Emacs is, calling it just a text editor is doing it a disservice. Over the years it's been extended to the point where you can:
It's not unusual for someone fully engrossed in Emacs to rarely leave it. Some of the tools written for Emacs are considered so high quality that you'll struggle to find something as good outside of Emacs. To name a few:
Emacs is unsurprisingly popular in the Lisp community. As a result it's not unusual for it to have some of the highest quality tooling for programming Lisps. In my opinion this is a bit of a double edged sword in that tooling for editing Lisp outside of Emacs has been somewhat neglected, and the one-two punch of being expected to learn Emacs on top of learning a Lisp can filter people out.
I've not really talked about Emacs Lisp itself yet. Emacs Lisp is a curious language, quite unlike Common Lisp and Scheme, being most closely related to the earlier MacLisp. One of the major differences that I alluded to earlier was that it's dynamically scoped instead of lexically scoped. This is quite a departure from a majority of contemporary Lisps. Aside from this it's not too difficult of a Lisp to pick up. The hardest part will be understanding how Emacs Lisp interacts with the editor.
There's a thousands different Lisps and I only really covered the big four. This feels a bit shallow, because it is.
Here's some Lisps that are worth giving a glance and might be right for you depending on your interests.
Oh, and to answer the question of which of the previously mentioned Lisps are argued as not-really-lisps:
Bit silly in my opinion but it is what it is.