« July 2005 | Main | September 2005 »


Wilbur and HTTP client access

Let me preface this all by saying that even though most people by now probably think that Wilbur2 is never going to materialize, I have - from time to time - been working on the last missing pieces.

Currently, I am worrying about HTTP client functions (and other "URL access" functions), these are an important part of Wilbur's "Data Source API". Several options to implement this exist:

  1. The "classic" Wilbur implementation has its own HTTP client, a piece of code that's quite complicated. It has been read-time conditionalized for Allegro, MCL, etc., and contains quite a bit of platform-dependent code.

  2. As an alternative to #1, I could take Trivial-HTTP and add some just to make sure that things like chunking and redirects work (OK, so this is essentially what #1 does, except that it also does some fancy header parsing).

  3. Lately, on OpenMCL, I have been using a piece of code that essentially calls curl in a separate process and pipes the output back to the CL process, to be read as a stream. It was trivial to bolt onto the existing interface so that it is call-compatible with #1.

  4. As an alternative to #3, I could use cl-curl, which basically calls libcurl directly. I haven't yet studied the source code enough to understand whether I would have to play with processes (ahem, threads in CL) to get the same nice "asynchronous" behavior I now get with #3. Generally, I am not crazy about linking with foreign libraries if I need to provide/use some "glue code" (there is some in cl-curl); I already do some of that on MacOS X to determine the proxy settings for HTTP, and would prefer that I didn't have to.

There are other alternatives besides the ones above. For example, AllegroServe (well, actually Portable AllegroServe is the one I have used in some projects) has an HTTP client but earlier experience with that was less than pleasant.

I love Common Lisp, but I have to say that Java/Python/etc. developers don't generally have to struggle with these types of issues. The general observation is that we are still missing a lot of stuff that should be considered "standard" (not standard parts of the language, but standard in the sense that every developer does not have to solve these problems over and over again).

Posted by ora at 11:37 | Comments (1)


Common Lisp "style" redux

Yesterday I wrote again about Common Lisp style, commenting on an article I spotted on "Lisp at Light Speed". I assumed the article was written seriously, but now several people have pointed out that it in fact is a satire.

Unfortunately, I have 20+ years of experience of not only writing Common Lisp code but also reading and critiquing other people's Common Lisp code, and I did not understand the joke. You may want to believe that this says something about me, if you wish. Sad fact is, however, that I have seen examples of all of those things discussed in the satire, except they were written very seriously.

So as it is, the article may have been satirical, or not. I can't tell.

Common Lisp is a difficult programming language. Understanding how Common Lisp works, in principle, is not hard, but mastering the "correct" idioms takes a long time to learn. When coding in C (say), it does not so much matter whether you use the correct idiom or not (the language is so simple and "close" to the processor), but with Common Lisp you can do a lot of damage if you are not careful. A consistent use of language idioms helps others read your source code (or, as it is in my case, helps me read my source code since I tend to forget in about 24 hours what I have written) - this is true for most programming languages, but in Common Lisp it is useful to understand what goes on "under the hood" (I have seen code where the novice programmer thought he had written an algorithm of linear complexity but where an analysis revealed polynomial - cubic, in fact - complexity, due to misunderstandings about how the language works).

(I happen to also enjoy Paul Graham's writings...)

Posted by ora at 14:35 | Comments (2)