Why Lisp

Home Research Publications Code Lab

I Like Lisp. Often, I have to explain to people why such a "weird," "obsolete," "unsupported," or "difficult" language is, in fact, the greatest thing in programming, ever. This is why.

Table of Contents

1 Garbage Collection

Maxim: Anything that a computer can do is beneath human dignity.

Manually managing memory requires large amounts of bookkeeping code for something that a computer could easily do. Not only that, it has been a constant source of bugs in programs for decades. Moreover, garbage collection makes a language more expressive, by letting objects be shared between different data structures, something not with manual deallocation where every object must have a known owner, or the programmer must implement an ad-hoc GC mechanism such as reference counting. Thus, Garbage Collection is good, and still calling free is nothing short of embarrassing.

1.1 Caveat

Current state-of-the-art garbage collectors can introduce pauses into an application that are on the order of milliseconds. While this is imperceptible to humans, some dynamical systems might care. Thus, if your particular application has millisecond-level realtime constraints – as many robotics applications do – then you may have issues using any garbage collected language for those parts of the application with stringent timing constraints.

2 Interactive Development

The Lisp development process does not look anything like the C development process. In C, one has a separate editor, compiler, and application, and one invokes each of them in turn during development. In Lisp these are all one and the same, 1 the "Lisp System," or just, "the Lisp." Thus there are no separate edit, compile, execute steps. The compiler is always available to the runtime, and new functions are dynamically compiled and linked into the running application, often as soon as they are written. Debugging occurs online too, with the programming testing out new changes at the REPL, and recompiling functions to fix a bug or add a feature. This interactive development style is not only allows for much faster development than C's edit/compile/debug cycle, it is just a far more pleasant programming experience.

3 Uniform Syntax and Code as Data

The parenthesis. It is syntax you can learn in three minutes and use to express anything. The biggest advantage, and one that seems to slip past most who just give Lisp a cursory glance, is that code and data are expressed the same way. A Lisp expression is nothing more than a list of symbols. By using a syntax that is really just an ever so slightly abstracted Abstract Syntax Tree, some very interesting things can be done… macros.

4 Macros

Plenty of other people have written about how wonderful Lisp macros are (and they really are). Paul Graham gives a pretty good explanation (halfway down, starting with "Many language have"). I won't try to duplicate his explanation, but suffice it to say "If a computer could write your program, just what the hell are you actually doing?".

5 Performance

Modern Lisp systems have good native compilers that produce fast code. The Python (naming predates Guido's little language) compiler used by CMUCL, SBCL, and Scieneer CL is very good about inferring types and eliminating unnecessary code paths. The language itself has been designed to both allow rapid development and (if necessary) later optimizations. Compare this to a language like (Dutch) Python, which seems to have been created with "Frustrate Compiler Developers" as a design goal. Not to say that such scripting languages don't have their place, but when you can get equivalent expressiveness, and very efficient code, I have a hard time figuring out just what that place is.

6 Myths

Lisp is slow!
Modern lisp implementations are fully native-compiled, and have good garbage collectors. They are fast. Python and Ruby are slow!
Lisp is hard!
Lisp is different. C++ is hard, and if you write bad code, your program explodes (or you create a huge security hole, and we have worms, botnets, and the spam-tastrophy). In Lisp, if you write bad code, your program will be slow, or worst case it throws an unhandled condition and gives you a debugger. But even better, the compiler will tell you that you've written bad code so you can go back and fix it.
Lisp systems/libraries are difficult to install!
Counter example: On debian/ubuntu, apt-get install emacs sbcl slime and M-x slime (and if you a vi-er, M-x viper). Once you've got the basic system installed, quicklisp is excellent for installing libraries.
Lisp is dead!
Lisp has been dying longer than many languages (and many programmers) have been alive. It will probably outlive us all.

7 Historical Note

Twenty years ago, software garbage collection was slow, so people who wanted to use garbage collected languages (lisp being the most popular), resorted to specialized hardware for assistance (see Symbolics, and LMI). However, this final development in the CISC approach to hardware came right as the benefits of RISC were being realized. Thus, it quickly became a fact the one could acheive better performance by running Lisp on conventional RISC hardware than by running it on the specialized Lisp machines. Of course, because software garbage collection was still slow, C would run even faster on RISC.

Step forward fifteen years, to around 2005, and software garbage collection has become quite performance competitive with manual memory management, even exceeding malloc/free performance in some cases. Thus, modern Lisps can now be – and are – quite performance competitive with C.

Lisp is the language of Today, discovered fifty years in the Past.


1 Traditionally true. Now Emacs (a lisp system itself, actually) is often used as a lisp editor, and though to the user the combined system appears highly integrated, the editor and (Common) Lisp system do technically run in a separate OS processes.

Author: Neil T. Dantam <ntd@daneel.golems.org>

Date: 2014-07-01 17:01:01 EDT

HTML generated by org-mode 6.33x in emacs 23