Tracking change and innovation in the enterprise software development community
Defy all
Challenges.
Microsoft®
Visual Studio
2008
Terracotta:
Scale your
Apps w/ease
Offload the DB:
Learn More!
Testing Tools to
Support Agile
Software Delivery
Whitepaper
Posted by Kurt Christensen on Oct 25, 2007 09:50 AM
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.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:
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.
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.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.
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.
Hibernate without Database Bottlenecks
The Future of Software Delivery According to visionaries Grady Booch & Erich Gamma
IBM software architect eKit: Grady Booch podcast, whitepapers, articles
VersionOne is recognized by Agile practitioners as the leader in Agile project management tools. Companies such as Adobe, BBC, CNN, Dow, HP, IBM, Sony and 3M have turned to VersionOne to help deliver greater value to their customers.
To those familiar with Ant, Slava Akhmechet wrote an excellent article explaining Lisp in terms of Ant syntax and custom tasks. For myself as a Java developer, it really helped me bridge the gap to understand the power of Lisp.
The resurgence in lisp for things like this can only be a good thing I think. I would love to see more success stories. Common lisp is a bit of a big beast (but its grown that way over the years), but other then that, lisp should be friendly (certainly more so then the popular opinion is of it), and fun.
I wish that there were resources present to dump the cruft of the CL spec, bring some of the libraries up to speed, or maybe we could see a bit of interest in Dylan.
I agree. I wouldn't know enough to call it "cruft" though, but it certainly represents a bit of a barrier. The nicest thing about lisp is there is no syntax, really. You are working almost directly in the AST, which when pretty printed, is really quite easy to read.
There seems to be a lot of interest in functional languages like Lisp, Haskell and OCaml at present. I think this is a good thing as it brings an alternative computational model to the table which suits some problems very well (and of course CS graduates can dust off that functional programming knowledge they were forced to pick up during their degrees :-)
I'm interested though. Why now? What's driving it? Functional programming has been around for a long time and it's always remained (largely) an academic interest. Why has mainstream practice suddenly got interested?
I'd think:
/Niclas
---
niclasnilsson.se
I think I agree with you, Niclas. I know that the Paul Graham essays are what initially made me curious about Lisp. There was one part in particular from "Beating the Averages", that made me go out and buy Peter Seibel's book:The source code of the Viaweb editor was probably about 20-25% macros... What that means is that at least 20-25% of the code in this program is doing things that you can't easily do in any other language. However skeptical the Blub programmer might be about my claims for the mysterious powers of Lisp, this ought to make him curious. We weren't writing this code for our own amusement. We were a tiny startup, programming as hard as we could in order to put technical barriers between us and our competitors. (emphasis mine)
Aptana RadRails: An IDE for Rails Development by Javier Ramírez discusses the latest Aptana RadRails IDE, a development environment for creating Ruby on Rails applications.
Cliff Click discusses how to optimize generated bytecode for running on the JVM. Click analyzes and reports on several JVM languages and shows several places where they could increase performance.
Scott Ambler, Practice Lead for Agile Development at IBM, speaks on the current status of the Agile community and practices having a look at the perspective of the Agile’s future.
Dave Nicolette and Karl Scotland try to introduce non-technical managers to one of the most popular Agile development techniques: Test-Driven Development (TDD).
Smooks is best known for its transformation capabilities, but in this article Tom Fennelly describes how you can also use it for structured event streaming.
Successful architectures evolve over time to meet changing business requirements. Luke Hohmann presents how to collaborate with key members of your business to manage architectural changes.
In this article, Dr. Tobias Komischke explains how colors used in a GUI can influence our interaction with a computer and offers advice on using the appropriate colors for the interface.
In his presentation, recorded at QCon San Francisco, MuleSource architect Dan Diephouse explores ways to use the Atom Publishing Protocol (AtomPub) when building services in a RESTful way.
7 comments
Reply