Weighing Exotic Technologies
Thursday, 9 February 2006
Peter Coffee makes a case for LISP in E-Week (via Phil Windley’s Technometria), arguing that Lisp trades memory/CPU usage for expressiveness, so that one can deliver applications quicker.
While I agree that Lisp is more expressive than, say Java, it’s not necessarily the platform to chose to develop web applications with.
- Forget about using Common Lisp for portability. The reality is Common Lisp’s feature set no longer match web development or database development. Want sockets (the basic building blocks of web applications)? Well, you will have to rely on vendors’ library for support. The same goes for anything that builds on top of sockets: SMTP, SOAP, or POP3
- The Lisp web developer community is very small, this means that there is no secondary market of component makers to service this community. Want a HTML calendar? Roll your own. Want AJAX? Roll your own. Want professional looking charts? Roll your own. The days of grandfather making his own axes are over.
- A lot of features that Lisp pioneered have made it into new languages. JavaScript has closures, C# and Java has garbage collection. You give up Lisp macros, but you pick up attributed languages and templates with C# or Java.
Note: this is not a criticism of Lisp, but of exotic technologies. If you want to deploy exotic technologies, make sure they live on the upper layers of your stack, for instance, as scripting languages. This way, they will still be able to talk to your JDBC drivers, or use the comprehensive framework libraries of Java or .Net or even PHP, and tap into the large pool of third party components available for these languages.
Just in case you think I’m a .Net bigot or a Java zealot, I spend about 80% of my time developing on top of Zope, a Python web platform, and from personal experience, although Python is nice an productive, one ends up spending a lot of time writing and debugging components that one could have bought if one were using .Net or Java, and I often wonder if the the gain in productivity makes up for the time spent writing instead of buying.
No. 1 — April 7th, 2006 at 6:36 am
Your examples are bad. There are libraries for all of the above applications that are cross platform and vendor neutral. Here’s a link to a list of some of the libraries that are available: http://www.cl-user.net/asp/Crla2/sdataQIUw8QhMnSxcDQjr-br2OxCk8yBX8yBX8oQ5Ss9v-ujgNp5/sdataQu3FsSHnB==
As far as templates, C++ templates are reasonable but Java template suck ass. As far are attributes, Lisp syntax is completely extensible. If you really want attributes then add them. There’s one library I know of that makes XML a valid lisp syntax.
No. 2 — April 7th, 2006 at 8:54 am
Thanks for commenting Mike.
Not being a lisper myself, I relied on the authority of the people writing LispSockets who wrote quote: “One of the Great Complaints about Lisp is its lack of standard sockets” unquote. I relied on it to infer that the higher level functions built upon sockets are going to be non-standard and not easily portable … if portability was a goal. Incidentally the project home page talks in terms of future tense, ie. “project will be able to… ” etc. Doesn’t give me much confidence, especially since this is 2006.
I wasn’t very clear in my post about templates and attributed languages. Lisp’s macros rock, but in terms of language tradeoffs, C# and Java are stealing enough ideas from Lisp but Lisp isn’t stealing CLR and Java’s standard library, or third party component library. Take the example of the snazzy kind of charts referred to in the post, is there any way someone running on Lisp could take advantage of these?
No. 3 — April 7th, 2006 at 12:21 pm
Actually, as far as other libraries are concerned. There is an interface between lisp and .net. There is also an interface between lisp and java as well. Also anything that can be or is written in c can be used in lisp. C++ libs can also be used via swig. The commercial lisps also have interfaces to COM. So, yes, you can use those libs in lisp. The socket libraries may not be part of the standard but they are standardized in practice. I’m not familiar with that socket lib and it is not the one normally used.
Your choice to talk about standards is ironic given that Java is not standardized and C# has a very superficial standard where common lisps standard is both deep and broad.
You seem to be focused on licensing code, I’m quite certain that you could find the libraries to license if you looked. It has been my experience that commercial libs are more trouble then the are worth, however
Lisp is not just about macros. They are great and allow lisp to be extended as the programmer desires. It is also the whole lisp philosophy of building up the language to better suit the application domain.That the language is itself programmable. Lisp being as old as it is predates many of the programming paradigms that are currently in use, such as oop and aspect oriented. But as each new programming method has emerged, lisp has subsumed it. For java to support aspect oriented programming, a whole new language and compiler had to be created. For lisp it is just an add on library. Lisp has been described as the 100 year language. This is because of lisps adaptibility. Can you imagine using Java or C# in fifty years? I have no doubt that lisp will be in active use in fifty years. It may be significantly evolved but it will still be lisp.
No. 4 — April 7th, 2006 at 3:58 pm
Thanks for the heads up to the .net interface. I wasn’t looking hard enough. Are you referring to RDNZL ?
The last time I looked at FFI, I was playing with CLISP (I’m running on Windows). Without UFFI support, it was very hard to get ODBC going, which is the bare minimum for a toy project.
Your point about aspect oriented programming being easier with Lisp et c…. I’m already sold on that. I’m only voicing what are the barriers that keep me using more Lisp.
No. 5 — April 8th, 2006 at 1:35 am
UFFI is an older interface. CFFI is the current interface. There are a number of database interfaces for common lisp. The main one would be http://www.cliki.net/CLSQL. UFFI info http://www.cliki.net/UFFI. All things CL related can be found at http://www.cliki.net/index.
I also use CLISP for just that reason. Stuff I have to write has to be cross platform and CLISP is as good in that regard as Java but is faster and more memory efficient. CLISP supports both UFFI and CFFI. There is also swig. There is also an inexpensive (Free for personal, $250 for redistribution) commercial CL for windows called Corman Common Lisp. It looks quite good and has both Windows API and COM support. It also compiles to very fast native code.
As far as .net is concerned there is RDNZL but there is also http://foil.sourceforge.net/
No. 6 — April 10th, 2006 at 11:02 pm
There is also http://www.lsharp.org/, if your a masocist.