I've put up version one of proceedings of the lightning (5-minute in theory, closer to 10-minute in practice) talks from the Bordeaux Libre Software Meeting Lisp track. Not everyone made my arbitrary deadline, but most did: and for those who didn't, there is the possible lifeline of a version two at some point in the future. (I hope we'll get Gilbert Baumann's thoughts on reader/editor integration, and Tim Moore's on CLIM interoperability: it was interesting stuff).
Comments and corrections are welcome: either to the e-mail addresses listed therein, or on freenode's #lisp channel, where quite a lot of the authors hang out.
As for my “keynote” talk, which I'm conscious that I haven't discussed yet: essentially, I attempted to make the case for protocol-oriented programming.
“What is protocol-oriented programming?” the cry rang out. Well, it probably already has a technical meaning (I confess: I didn't check), but the way I mean it is as at least cursory thinking about whether it makes sense to document the means by which a program (or function, or basic computational unit) achieves something, as well as what it is intended to achieve.
Why would one want to do that? Well, in languages less impoverished than C and its cousins, it is possible to hook into provided functionality: Lisp in particular is very trusting, allowing the user (or, perhaps the author of library Y) to override behaviour in library X. A protocol is then the contract between these two libraries (and any overriding that has occurred) so that the resulting mixture continues to function as expected.
An obvious example of a protocol in this sense is the CLOS Metaobject Protocol: libraries or users are allowed to selectively override slot-value-using-class, but if it's overridden inconsistently with (setf slot-value-using-class), expect Bad Things to happen (so Don't Do That Then). However, I believe that there's much greater scope for protocol-oriented programming than has hitherto been realized: for instance, I bet the McCLIM people would love a protocol for fontconfig, rather than an opaque library. And so on, and so on.
Part of the point I was making was that the Lisp community is too small to build isolationist libraries, while undisciplined development (first, take a copy of the library; then, modify the source) leads to a scaling problem and a combinatorial explosion, making it difficult for any given user to use the enhancements by two other people. Of course, the downside is that protocol-oriented programming — or exposing your internals (see, it even sounds disgusting) — is difficult. Film at 11.