Lisp in Web-Based Applications
Paul Graham
(This is an excerpt of a talk given at BBN Labs in Cambridge, MA, in<br>April 2001.)
Any Language You Want
One of the reasons to use Lisp in writing Web-based applications<br>is that you *can* use Lisp. When you're writing software that is<br>only going to run on your own servers, you can use whatever language<br>you want.
For a long time programmers didn't have a lot of choice about what<br>language to use for writing application programs. Until recently,<br>writing application programs meant writing software to run on<br>desktop computers. In desktop software there was a strong bias<br>toward writing the application in the same language as the operating<br>system. Ten years ago, for all practical purposes, applications<br>were written in C.
With Web-based applications, that changes. You control the servers,<br>and you can write your software in any language you want. You can<br>take it for granted now that you have the source code of both your<br>operating system and your compilers. If there does turn out to be<br>any kind of problem between the language and the OS, you can fix<br>it yourself.
This new freedom is a double-edged sword, however. Having more<br>choices means that you now have to think about which choice to<br>make. It was easier in the old days. If you were in charge of a<br>software project, and some troublesome person suggested writing<br>the software in a different language from whatever you usually<br>used, you could just tell them that it would be impractical, and<br>that would be the end of it.
Now, with server-based applications, everything is changed. You're<br>now subject to market forces in what language you choose. If you<br>try to pretend that nothing has changed, and just use C and C++,<br>like most of our competitors did, you are setting yourself up for<br>a fall. A little startup using a more powerful language will eat<br>your lunch.
Incremental Development
There is a certain style of software development associated with<br>Lisp. One of its traditions is incremental development: you start<br>by writing, as quickly as possible, a program that does almost<br>nothing. Then you gradually add features to it, but at every step<br>you have working code.
I think this way you get better software, written faster. Everything<br>about Lisp is tuned to this style of programming, because Lisp<br>programmers have worked this way for at least thirty years.
The Viaweb editor must be one of the most extreme cases of incremental<br>development. It began with a 120-line program for generating Web<br>sites that I had used in an example in a book that I finished just<br>before we started Viaweb. The Viaweb editor, which eventually grew<br>to be about 25,000 lines of code, grew incrementally from this<br>program. I never once sat down and rewrote the whole thing. I<br>don't think I was ever more than a day or two without running code.<br>The whole development process was one long series of gradual changes.
This style of development fits well with the rolling releases that<br>are possible with Web-based software. It's also a faster way to<br>get software written generally.
Interactive Toplevel
Lisp's interactive toplevel is a great help in developing software<br>rapidly. But the biggest advantage for us was probably in finding<br>bugs. As I mentioned before, with Web-based applications you have<br>the users' data on your servers and can usually reproduce bugs.
When one of the customer support people came to me with a report<br>of a bug in the editor, I would load the code into the Lisp<br>interpreter and log into the user's account. If I was able to<br>reproduce the bug I'd get an actual break loop, telling me exactly<br>what was going wrong. Often I could fix the code and release a<br>fix right away. And when I say right away, I mean while the user<br>was still on the phone.
Such fast turnaround on bug fixes put us into an impossibly tempting<br>position. If we could catch and fix a bug while the user was still<br>on the phone, it was very tempting for us to give the user the<br>impression that they were imagining it. And so we sometimes (to<br>their delight) had the customer support people tell the user to<br>just try logging in again and see if they still had the problem.<br>And of course when the user logged back in they'd get the newly<br>released version of the software with the bug fixed, and everything<br>would work fine. I realize this was a bit sneaky of us, but it<br>was also a lot of fun.
Macros for Html
Lisp macros were another big win for us. We used them very<br>extensively in the Viaweb editor. It could accurately be described<br>as one big macro. And that gives you an idea of how much we depended<br>on Lisp, because no other language has macros in the sense that<br>Lisp does.
One way we used macros was to generate Html. There is a very<br>natural fit between macros and Html, because Html is a prefix<br>notation like Lisp, and Html is recursive like Lisp. So we had<br>macro calls within macro calls, generating the most complicated<br>Html, and it was all still very manageable.
Embedded Languages
Another big use for...