Learn
Features of Common Lisp
What sets the language apart.
Interactive development
There is no separate compile, run and debug cycle: the program is developed while it runs. Compilation is incremental, functions are defined and redefined on the fly, and every object can be inspected at any time. This is more than a REPL. The whole environment, from the editor to the debugger to the language itself, is made for this way of working.
Stable
Common Lisp was standardized by ANSI in 1994 and has not changed since. It keeps up with the times through its own malleability instead: what the language lacks is added as a library or a macro, not by a breaking release. A program written twenty years ago is likely to run today, unmodified.
Expressive
The Lisp way of solving a problem is to define the idioms the problem needs, small languages as close to the problem as possible, and to write the solution in them. Macros make that possible, and the result is short and declarative in a way few other languages can match. Bottom-up programming comes naturally.
Fast
The main compilers produce native code. Programs can be annotated with types, the compilers optimize on them, and safety, debugging and speed can be traded against each other per function. Performance is well ahead of interpreted languages such as Python and Ruby, and close to C when it matters.
Uniform
Code is data: everything is an S-expression, so there are few syntactic oddities to learn, and the same reader, printer and list functions serve programs and data alike.
Multi-paradigm
First-class functions, closures and destructuring, as in a functional language; and CLOS, an object system with multiple dispatch, method combinations and a metaobject protocol that lets you change how objects themselves work. Other paradigms, logic programming among them, have been added as libraries.
A condition system with restarts
An error in a running program need not unwind the stack. The program stops where the error was signalled and offers restarts, ways to go on, chosen by the code or by the person at the debugger. Long-running and critical software is written this way for a reason.
For a longer tour, see Features of Common Lisp by Abhishek Reddy. Ready to try it? Get started.
Something wrong or missing here? Edit this page on GitLab.