Blog (Atom feed)

My personal Lisp rejuvenation

I was lucky enough to attend ELS this year since I was able to make it coincide with a vacation. Overall, it was a wonderful experience. The talks were interesting, the conversation was invigorating, and the organization was seamless. Kudos to the organization committee for running such a great ship.

In terms of work with Lisp, I haven’t done much in the past eight years since I defended my thesis. I did a lot of Lisp hacking back then, but work and other things have prevented me from doing anything with it since. I attended ILC 2014 in the hopes of getting involved again, but sadly, that didn’t happen. Things are different now and, after attending this year’s ELS, I’m looking forward to contributing in some way.


In general, I was quite happy with the talks. I didn’t read any of the proceedings ahead of time and aside from a couple of talks, that didn’t hinder my ability to follow what was going on. Most of the presentations were enjoyable and there were only a few moments where my mind wandered into “please end this person’s presentation misery” territory.

One talk that stuck with me, in a good way, was Stefan Karpinski’s keynote on Julia. It addresses something that has always been a pebble in my programming language shoe: numbers. Do they have to be entirely intrinsic? No. I’ve seen this before, but it was great to see how Julia attacks it. I really like its approach.

The talk did reaffirm my love/hate relationship with live coding during a presentation. Although mostly canned, there were still those debugging moments and other small disorienting things. It came dangerously close to being a window into someone’s coding session instead of a demonstration.

Another idea that connected with me was James Anderson’s somewhat confrontational idea of inferring system descriptions (pdf). I’ve always appreciated attacks on sacred cows and he was unafraid to ask why we are writing system descriptions at all. Build systems and dependency management has always been a fascinating bugbear for me and I’d love to try a different approach. James’ idea of making the Lisp system spit out the dependencies seems like something worth trying.

The standout talk for me was Christian Schafmeister’s talk about CANDO, not only due to the technical content, but the infectious enthusiasm of the presentation itself. CANDO is a system for creating and working with molecules using Clasp, which is a version of Common Lisp on LLVM – the thing I’m working on these days – that makes interoperating with C++ seamless. Dr. Schafmeister has been working for a long time on this and it shows. This is a project I’d like to work on.


Conferences are all about the chatter and, for not knowing anyone, I’m happy to say that everyone I interacted with was friendly and inviting. I was a bit nervous about just walking up to a table and joining a conversation, but no one seemed to mind and were happy to address “the new guy” without making me feel alienated. The social atmosphere is what really won me over.

Again, many praises to the conference organizers for getting good catering and creating lots of opportunity for conversation. Special mention goes to Jon Atack for organizing a social dinner on Monday night. This was my only chance for an evening social event since I ended up missing the conference banquet.

One theme that I noticed, and quite liked, was an apparent willingness to write programs that would interoperate with outside entities. I got less a sense of that in the past, although it may well have existed. It seemed like people were more willing to use Lisp as part of a heterogenous deployment rather than the “be-all and end-all.” Maybe reimplementing some things isn’t worth it.

Nitpicks and grumblings

The hacker ethic is alive and well in the Lisp community, but in some cases it was hopelessly childish. At this point, chiding other languages about closures has run its course. There’s no need to bring this point up except in cases where communities in other languages insist on taking credit for their existence. I suspect the tolerance of the smug Lisp weenie has worn thin and it probably shouldn’t be pushed any further.

Packaging and dependencies is still done poorly and no one can agree on what works. I was in on a few conversations about it and I can’t say there was anything close to a consensus. ASDF is important but isn’t enough. Quicklisp is great but not sustainable. I’m sure dependency management will be a pain when I start to develop again, but then, I’m not particularly happy with other language approaches either.

There was a lot of talk about better documentation. I heard “we’re getting to it” a bit too much to trust that anything will come of it, however. And as much as I sympathize with the UltraSpec, but I don’t think official documentation should be in a wiki (although a searchable HyperSpec would be nice).

As much as I hate to admit it, specialization and optimization are important elements of any system or library. It has to perform well in many circumstances. It can’t just be possible to do something, it has to be offer a reasonable path to such performance, with documentation or clear coding idioms. I saw a lot of “look what is possible” and not “look how to do it”. There was too much focus on extensibility that likely no one would use. Extensiblity should not be a goal in and of itself; it’s rarely a selling point.

On a purely personal note, I’m pretty sure I got Robert Standh’s cold while I was there. I won’t hold that against him, though. ;)

Next steps

I’m going to have a go at doing something to help Clasp. I didn’t know about it until the conference and was thinking about CL and LLVM on the flight over, so it seems very apropos.

My connectivity during my vacation was pretty terrible (not the conference or the venue’s fault) so I didn’t actually get to do anything until I got home – which means back to work tomorrow. Still, I’m excited about Lisp development again and after a few years of work under my belt, I’m sure my views will be a little different this time around, likely for the better.

May 15, 2016

Generated on 2022-01-02