Sunday, January 06, 2008
Cool: Common Lisp Elephant object persistence package
One of my customers uses Common Lisp for a lot of development and we go with Franz, largely because of AllegroCache object persistence and great support.
Until today, I had never bothered getting Elephant installed and set up with a back end data store (I chose CL-SQL with native PostgreSQL). Since I own my own licensed copy of Franz Lisp (and my customer provides me with another license for their work), I was always happy to just use AllegroCache.
Anyway, after reading Vetle Roeim's blog post Implementing a blog in Common Lisp I decided to take a little time setting up Elephant and Edi Weitz's Hunchentoot web server and his HTML-TEMPLATE Common Lisp templating system. I used a fairly recent release of SBCL Common Lisp on a MacBook. This is all free open source software. I found the Elephant API to be easy to use.
After having some fun with this, I do have a few comments on Common Lisp vs. Ruby development:
Until today, I had never bothered getting Elephant installed and set up with a back end data store (I chose CL-SQL with native PostgreSQL). Since I own my own licensed copy of Franz Lisp (and my customer provides me with another license for their work), I was always happy to just use AllegroCache.
Anyway, after reading Vetle Roeim's blog post Implementing a blog in Common Lisp I decided to take a little time setting up Elephant and Edi Weitz's Hunchentoot web server and his HTML-TEMPLATE Common Lisp templating system. I used a fairly recent release of SBCL Common Lisp on a MacBook. This is all free open source software. I found the Elephant API to be easy to use.
After having some fun with this, I do have a few comments on Common Lisp vs. Ruby development:
- Common Lisp compiled code runs much faster than Ruby: typical benchmark results are about 30 times faster - but Ruby's slowness is mitigated if a lot of processing is performed in native libraries like Ferret.
- Development with Common Lisp takes longer than Ruby (for me, at least). It would have taken me 10 minutes to get set up with Ruby for this tutorial while it took a full 90 minutes to get 20 different Common Lisp packages and install them in the project directory for Vetle's tutorial. It is true that I will keep this project around, and if I ever need to use Elephant, HTML-TEMPLATE, Hunchentoot, etc., then I will just clone and modify this project (if I don't care about using the most up to date libraries). Common Lisp ASDF is a good package manager but in my opinion is not as good as Ruby Gems.
- I find that I work a little faster in Ruby than Common Lisp, mostly because the language is terser: simply less code to write and read. That said, Common Lisp is also a great language to work in.
# posted by Mark Watson, author and consultant : 1:15 PM
Comments:
<< Home
Lisp is more verbose (although I find that an aid to reading); however a good editing environment fixes that. I have SLIME configured to expand filenames, e.g. I can type ds-bn[TAB] and it will be expanded to destructuring-bind. This helps a lot.
Was that using asdf-install to install packages? If you weren't using the excellent asdf-install package that may have been one reason it took so long (think gems for ruby).
Setting up that same setup what i do is install libdb4.5 and cl-sql-(slqlite|postgres) through apt-get, and then its just a matter of asdf-install:install whatever libraries are needed.
Setting up that same setup what i do is install libdb4.5 and cl-sql-(slqlite|postgres) through apt-get, and then its just a matter of asdf-install:install whatever libraries are needed.
Hello Eadmund: I usually use Franz's Eli+Emacs, sometimes Slime+Emacs, rarely LispWork's IDE. (LispWorks paid me several years ago to improve their documentation, so I am very familiar with their IDE, etc.)
Hello Chris: you are of course correct. I used to have asdf-install on my system (and have it automatically in OpenMCL and SBCL), and it was "ruby gem like". I probably did waste a lot of time by manually installing the packages. That said, for a serious Lisp project, isn't it better to have all project dependencies installed in the same directory structure as your application code? This helps prevent breaking systems when doing global updates. If I remember correctly, asdf-install stores fetched librares in a central place, shared among all your projects.
Thanks,
Mark
Post a Comment
Hello Chris: you are of course correct. I used to have asdf-install on my system (and have it automatically in OpenMCL and SBCL), and it was "ruby gem like". I probably did waste a lot of time by manually installing the packages. That said, for a serious Lisp project, isn't it better to have all project dependencies installed in the same directory structure as your application code? This helps prevent breaking systems when doing global updates. If I remember correctly, asdf-install stores fetched librares in a central place, shared among all your projects.
Thanks,
Mark
<< Home
Subscribe to Posts [Atom]
