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.
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.
ReplyDeleteWas 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).
ReplyDeleteSetting 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.)
ReplyDeleteHello 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
You can add places for asdf-install to install things: look at asdf-install:*locations*.
ReplyDeleteMaking one set of libraries per project is an interesting idea. I don't know of a good solution to multiple package versions in LISP...
Commenting on this piece is going back in time a bit, but I am picking up Common Lisp seriously for the first time in... well... abou 20 years. So re: CL libraries there is now quicklisp... http://www.quicklisp.org/ I don't know much about it yet, but the CL community seems thrilled... "Quicklisp is really what you always wished existed for installing and managing Common Lisp libraries."
ReplyDeleteHello Patrick,
ReplyDeleteI think that you will like QuickLisp: it really does make it easier to set up projects that are smaller and use the single QuickLisp repository on your laptop. A real time saver.
BTW, are you using Elephant? I have been working one of the authors of Elephant, Ian Eslick. Interesting that I used his cool open source project, then a few years later I get to work with him :-)
Best regards,
Mark