Paragent is a web-based, open source IT administration tool implemented in... Common Lisp? In their latest
blog entry, the Paragent developers describe their experiences using Lisp:
We decided to take a closer look at Lisp as a possible implementation language for the new server component, along with Ruby/Rails, PHP and Python... After much deliberation, we decided to give Lisp a go. True to the promises, we were able to develop and launch the first version of Paragent in record time with a limited budget.
InfoQ asked Tim Ritchey, CTO of Paragent.com, to elaborate on why his team chose Lisp, and how it has worked out:
As a small company with a new product, we are in constant contact with early adopters, and we roll their feedback very quickly into interim releases. One of the great benefits of using Lisp is the ability to work "live" in a running system. When you compile a function, it is pulled into the running image, and you get immediate feedback. There is no long edit-compile-run cycle to break your stride. This is especially useful when pair programming, as there is hardly ever any downtime.
We have one example of being on site talking with a customer, and there was a very important feature for them that would really make or break the deal. While the customer was looking over our shoulders, we were able to bring up the server, code the feature, run some tests and roll it out live. In 30 minutes, we were able to seal the deal. I don't think there are many other platforms with which I would want to attempt that.
There has been a small resurgence in the popularity of Lisp recently, due in part to Peter Seibel's book
Practical Common Lisp. Of course,
some companies have been using Lisp successfully for years. But a common complaint from developers new to Lisp has been the antiquated tooling and the apparent lack of third-party libraries. For tooling, the Paragent developers took matters into their own hands and produced
Cusp, a Common Lisp development plugin for Eclipse. And when asked about whether or not a dearth of libraries has been an issue for Paragent, Tim Ritchey had this to say:
In the beginning we were worried about the library situation... In the end, it turns out we haven't really had any issues there. In most cases, there are very good libraries for everything we have needed (HTTP client, SMTP, security, graphics rendering, etc.) or, there are very good foreign function interfaces in Common Lisp, so if there is not a native Lisp library, we can bring in almost anything else we need.
I think that one thing that scares people off with the Common Lisp library situation is the impression that many libraries appear to be one-offs by individual programmers, where other language libraries have entire teams that work on them. I don't want to chalk it up to the magic fairy dust of Lisp productivity, but most of these libraries, even though they may seem understaffed and rarely updated, are actually quite stable and productive... The smaller number of Lisp developers means we seem a bit thin on the ground, but I can't think of a single case where we have been held up by library support.
Whether or not Lisp becomes more popular with a new generation of developers remains to be seen. But experienced developers understand that of all the technology choices they make, the choice of language often has the greatest impact, and so any team committed to the
principles of agile software development might at least consider Common Lisp as an alternative.