Ascription is an Anathema to any Enthusiasm

Dan Weinreb wrote a long blog post recently outlining what Common Lisp’s “Conditions (exceptions) are really about.”  He argues, and I won’t disagree, that they provide a clean, even elegant, way to handle all the long tail of situations that arise when your trying to be fastidious about the contract for your functions.  One of the things that used to be unique about Lisp was it’s elegant support for unwinding the stack when odd things forced you to abandon what ever your doing.  It was a lot easier to see to it that the printer handle was relinquished, the file closed, the gate shut in Lisp than it was in Fortran or C.  These days most languages are better about admitting that these things happen and something should be in the language to help.

Interestingly though the Common Lisp condition system remains a much more elegant thing than you find in other languages.  I don’t really understand why.  The condition system doesn’t just provide a way to unwind the stack, passing along an object instance to describe what ‘exceptional’ condition arose.  It also allows the handler for these conditions to resolve them.  In effect this provides an elegant way to implement call backs, i.e. that situation where a low level body of code needs to ask the higher, or later written, code how to resolve a problem.  For example you can use the condition system to implement the classic call back scenario where a GUI widget wants to provide it’s users with the ability to do additional checking on user input.

There’s more, but what I really wanted to get off my chest (and that’s what a blog’s for eh?) is that I sometimes I like to muse about raising a condition is yet another example of how complex function calling really is.  Back in the day we used to be able to figure out what function would implement a call site at link time.  Later we got used to having dynamic linking do some of that, and it was common in memory constrained systems to load and flush code on the fly under the covers when in the function call.  I’ve seen systems where you switched interpreters in the function call for performance and space trade off reasons.  These days people are used to having a complex method dispatch that puzzles out what method will will take care of the request.  The method dispatch is a messy beast when you allow new classes to be loaded.  It was with some pleasure that I first read the mythical man month’s description of how some ornate linker came to be obsoleted; since at the time I was struggling with how loading compiled lisp files was an amazingly disruptive event; since it upset all your method tables.

Generally method dispatch is done by searches up stream in the acyclic directed graph of types.  I.e. the behavior of the function is inherited from the class hierarchy.  The class hierarchy is not the only hierarchy in most programs.  For example there is almost always a containment hierarchy, i.e. the OK button is inside this dialog; or for example this file write is taking place inside the task of writing the log, inside the task of handling this web request.

At one point in my life I was quite enthusiastic about the idea of language designs that might allow these other hierarchies more respect.  During that period I built a few class systems where behavior was inherited first from the containment hierarchy and only secondarily from the class hierarchy.

What I like about conditions is how when a condition is raised and the system goes off seeking a handler for that condition - it’s just another variant of method dispatch - and the call hierarchy is were we search for the handler.  For me the fact that these calls often don’t return; or return in such unusual ways is part of what’s delightful about the condition system.

Finally Google is revealing some of the means they will provide to allow third parties to run code closer to their assets. Last week was good for Python! Since, we learned that Google’s leading language for developers will be Python. While they assert that the platform is language neutral it certainly looks like only Google can “harden” and deploy a new language. The crowd demanded both an unknown language and Perl, the presenter flinched. That is going to be very rough on the long tail of languages.

I found the 1st and 2nd segments of their announcement videos interesting. Everybody got very nice hair cuts.

There is a lot of value in this offering and the “you don’t have too” theme that runs through out their patter is a strong way to present that. They really are taking a lot of pain out the developer’s job! So while they are probably encouraging the die off of a lot of interesting languages they are enabling a lot of tiny applications.

Their persistent store is cute (note you can’t write to the file system otherwise). I suspect this is a lock-in point, though the semantics of the store look reasonably simple.
In addition to writing to the file system, no pure TCP/IP interfaces, and no threads. Which reflects the nature of the underlying computer. Amusingly this is a non-preemptive computing model, just like the old Macintosh. You have to do all your work triggered by http requests, and those can’t run too long.

I’m fascinated by my emotional reaction to all this. While I’ve rationally seen this coming for a very long time. In fact I’m surprised it’s taken so long! It makes me sad to see the old craft skills become less necessary. It makes me excited to see the opportunities this opens up; it’s always fun with a large population is empowered to author software. That’s one of the big-hard-problems, letting more people be authors.

That kind of somewhat discombobulated emotional reaction in an expert is a good sign in a platform offering. This is going to be big and it is a nice counter point to Amazon’s approach.

Wrote small Common Lisp library for accessing the echonest music analysis API. All the other APIs are jealous.
Writing this was fun because I got to use Relax NG for the first time in actual code. By inspecting the XML that comes back from echonest I guessed at what the schema was and wrote it up in the compact form of RNG (see here). Isn’t that easy to read!

Inserting the library cxml-rng for validating your XML given a Relax NG schema and inserted it into the SAX pipeline took less than a half dozen tokens (see here). My reward: is that the handler that loads the XML into a useful data structure doesn’t need to be as paranoid. How relaxing!

Assorted brush clearing.

Adding additional libraries to a clbuild setup is easy. Just add lines to your wnpp-projects file. For example:

cl-json get_darcs http://common-lisp.net/project/cl-json/darcs/cl-json

Give it a try and add additional things until everything you need is included. I’ll admit to editing the dependencies file by hand.

Sooner or later you get to things for which this doesn’t work. You can teach clbuild about additional projects by just adding them to the source directory and then using the register-asd command on that project. Given that your stuck doing that you will need to tell clbuild not to attempt to download them. You the command called skip marks the project to prevent any attempt to download.

That scenario arises if you want to use cl-xmpp, which depends on cl-sasl. Cl-sasl uses yet another source control system, GNU arch, which clbuild doesn’t handle yet. Clbuild is really pretty awesome at dealing with the excessive diversity of source control systems members of the Lisp community have embraced. We do love our exceptions.
I did try using get_tarball, which is deprecated, but that didn’t work out. Possibly because the tarball filename is cl-sasl_0.3; and that code appears to want it to be cl-sasl. I didn’t look further.

Cl-xmpp did not work, out of the box, with my ejabberd. That problem appears to be explained in this archive of the development mailing list. The resolution involves passing :mechanism :sasl-digest-md5 to xmpp:auth, but it also requires a patch to ejabberd to improve it’s xml conformance. I haven’t made the ejabberd patch yet, or maybe I need to upgrade ejabberd.

Ben Laurie recently observed “people don’t really talk much about the experience of writing and debugging code.” I suspect if that void were filled we would see many dull postings like the above; or more likely postings like the ones Jason S. Cornez makes in the archive above.

This posting is, in part, triggered by Ben’s comment. But it’s also provides a checkpoint. I need to context switch to other activities at this point. I certainly didn’t expect to devote quite so much time to this when I added this to my wnpp-projects file Saturday afternoon.

cl-xmpp get_cvs_clnet

Update: ejabberd is probably doing the right thing (see here)… Hm, looks like the code forked and a better version is to be had as so:

cl-xmpp get_git http://www.lichteblau.com/git/cl-xmpp.git/

Maybe I should always read the entire transcript of the development mailing list before I start anything.

I’ve been musing recently that there are a few words which you can use to kill most any software project:

• Safe - As in “What could possibly go wrong?”
• Scalable - As in, “How do you plan to make that approach scale?”
• Social - “Shouldn’t the account management include a social network?”
• Socialize - As in “But first, let’s socialize this idea in the organization.”
• Semantic
• Sustainable - “I don’t understand your business model.”
• Simple
• Standard

I needed to post this so I stop seeking more S words to add to the list.