Comments:"Why Lisp?"
URL:http://lisperator.net/blog/why-lisp/
Aug
11
2012
Early 2010 I joined the IT team of a small research center in Italy. Our
manager at the time was a smart guy, a programmer himself—Emacs user and
Haskell lover. We started a big project and, although their initial plan was
to develop it in PHP (having already a few PHP devs there), the manager
agreed I can use whatever language I want to bring us faster to the
objective. He'd prefer Haskell, but I don't know it. I was having some 10
years experience with JavaScript, but not on server-side (NodeJS was in early
stages those days), 8 years with Perl and only a few months with Common Lisp.
I picked Lisp and I still congratulate myself for that choice.
No dependency hell
Earlier this year I changed my old server for a better one. To do that I could have simply copied the full HDD contents from the old server to the new one, but my old server was a messy combination of Debian stable + testing + unstable and I thought the only way to clean the mess is by starting all over. Having a freshly reconfigured server, I had to reinstall all my Perl stuff, such as my old website. That was somewhat painful and I realized just how easy it is to deploy Common Lisp applications versus Perl (or anything else, probably).
With Lisp, you just build your application and get one binary; you copy that to your server and you're done. With Perl, you have to install a load of modules on the server; some of them are available in Debian via apt-get, others are only on CPAN, some require gcc/g++ and random C/C++ libraries you didn't even know you're using, and some simply fail to build anymore.
After 8 years of Perl, I can promise you that setting up a (web) development environment with Common Lisp is much much easier.
Not unreadable
In the years I've been using Common Lisp I noticed that I can look through code that I didn't touch in 2 years and immediately understand what it does.
More importantly, I can read code written by others and understand what they meant relatively easily. This is helped by a great feature of the environment (Emacs/SLIME) which provides cross-referencing tools, for example, I can place the cursor on the name of a function and ask “where is this defined”, and it jumps to the place of the definition, which could be in my own code or in third party code. But I can also ask “where is this function called” or “where is this variable referenced”. This is extremely useful for code refactoring and it beats every “modern” IDE I've seen.
Organic growth
In most other languages, the development cycle is, roughly, (1) edit, (2) compile (depending on the language), (3) run the program to test it. I can still remember the days when I had to run /etc/init.d/apache restart in order for Apache to pick up the changes I've done to my Perl modules.
In Lisp things are different. You're not just writing your program; you're growing it. Lisp is alive. Your program starts from nothing—you really just start the REPL—and then you keep adding to it and changing it as it runs. You talk to it all the time; you can inspect and modify data and functions as the program runs; even when problems arise, such as a hard error, you can drop into a debugger and inspect local variables at various stack frames, or even evaluate arbitrary expressions in a certain stack frame.
Many of these ideas, which Lisp pioneered, were implemented later in other languages. For example you can attach the GDB debugger to a running process and inspect live data; however, you cannot change the running process, like for example you can't redefine functions.
The only way to understand how great this is is to try it; you won't get it from this short blog post, nor from a thousand pages book.
Stable as a rock
When I was younger, I had the feeling that if some software library was not updated in 5 years it's unmaintained and it's probably broken. That, sadly, is usually the case with many programming languages—because they're moving targets. They change frequently and they depend on lots of external factors—operating system, compilers, shared libraries etc.
That doesn't seem to apply to Common Lisp. The language is extremely stable. You often find code written a decade ago that still functions properly. You might think that this happens because Common Lisp did not “evolve”, and that's one face of the truth.
Programmable programming language
The fact is, Common Lisp is powerful enough that you can modify the language from itself, without the need for a new spec (and by that I don't simply mean that you can define functions and variables). I don't know of a single programming paradigm that wasn't brought to CL; in fact most paradigms, and even whole programming languages, were prototyped in Lisp long before they had a life on their own.
Support for macros, of course, is most of what makes this possible. But the fun part is that even if Lisp didn't have macros, you could implement them in Lisp itself with a bit of effort. That can't be said about other languages because it's only the Lisp syntax that makes macros possible. There were attempts to add macros to other languages (most notably C's #define) but they're not even close to Lisp macros. But of course, Lispers know this already, and non-Lispers still wonder what macros are good for.
Going further than “ordinary” macros, you can define reader macros. Experienced Lispers avoid them unless they're really necessary. The extent to which you can change the language is only limited by your imagination, and that's probably why the standard was not updated in almost twenty years; it's very good as it is; like the United States Constitution, it gives power to the people. I guess nobody wants to change that (well, not the people, anyway).
Lisp is simple!
The Lisp beginner might read this in disbelief. I know for myself, before using Lisp I thought that it's a weird language and that it must be extremely complicated. Nothing is further from the truth, but the truth is hard to see when your brain is wired to think in terms of for and while statements, in blocks delimited by { curly brackets }, and especially when you expect the language to read your mind about operator precedence.
A Lisp interpreter can be written in just a few lines of code, as this great paper by Paul Graham shows. My first Lisp interpreter was written in Perl, based only on ideas in this document and with a quick and dirty parser.
Like mathematics, Lisp is based on just a few axioms. Common Lisp did get big and complex—like mathematics—but it's written in a simpler Lisp, which is in turn written in an even simpler Lisp. The analogy goes on—complex mathematics is defined in terms of simpler mathematics, which is itself defined in terms of even simpler maths. Eventually, it all goes down to the void set. It's based on absolute, incontestable truths.
If you bootstrap a very simple Lisp compiler, you can then define and redefine the language in terms of itself. I did this and it was a fabulous experience. If you want to learn Lisp but you fear it's complex, my suggestion is to start looking at it from the bottom, from the simple things. Just as you learn maths.
So this new website is powered by Common Lisp. I expect the code I wrote these days to function for decades, but this of course depends on other factors (there's a lot of CSS, HTML and JavaScript into it).
This is actually the first website I do in Common Lisp. I make a difference between websites and Web applications—in many ways, a website is harder to make. I've been working on a CL tool to make this easier—Sytes—using this tool and some other neat CL libraries like Quicklisp, buildapp and sb-daemon, I think it's as easy now to get started with writing websites in CL as you can do with PHP. I hope to prove that soon.
In the mean time, if you want to get in touch you can email me or leave a comment in these pages. Comments are moderated, because I'm fed up with comment SPAM; this means I'll have to approve your comment in order for it to appear on the website, but if you enter your email address you'll receive an email and will be able to validate your comment yourself. Your email address is not published.