eclm09 report

A good time was had by all, including, most importantly, me. The European Common Lisp Meeting has a really nice feel to it, as several people commented to me. Well done Edi and Arthur once again!

The venue was quite stunning, with fabulous views over the Elbe and some of the enormous port. The walking tour on the Saturday was largely interesting (and we didn’t get too wet…). The boat-trip and dinner on the Saturday was fun, too (and we didn’t get wet at all…). The A380 is big. A hangar with multiple A380s is even bigger.

Although not technical, the overall positive theme of the talks – you can actually do something with Common Lisp! – was a refreshing change from the recent “What’s wrong with CL” emphasis. (I’m not saying there shouldn’t be a conversation about CL’s future, just that it shouldn’t be the only topic of conversation.

Dan Weinreb kicked things off with a variation of his Google tech talk. My strong impression was that it featured as a great table-of-contents for a fascinating semester course – which we’re still waiting for. Come on Dan – more! We can take it! He mainly talked about the business rules tier of QRES (the presentation layer being Java and AJAX, the database being Oracle). This is made up of ca. 750k lines of home grown lisp code (including unit tests and tools) and 150k lines of open source libraries (he namechecked Hunchentoot, drakma, usocket, and cffi). There are 50 lispers working on the codebase. Coding standards are important. Code reviews are essential. They’re not completely happy with with the support for large-scale modularity and incremental builds in lisp. Interesting quote: “How to apply experience from previous software projects to new software projects is much more difficult that most people imagine.” Dan finished with three plugs: his CPAN for Lisp proposal; Clojure is interesting; ‘Coders at Work’ is a terrific book.

Paul Tarvydas discussed his Visual Frameworks/CL-VF programming system, which is used in JetLetter, a high performance junk direct mail processor. He made a number of though-provoking claims, including ‘encapsulation should be by process’, ‘we learn from EE that asynchronous components + diagrams = reliable designs’, ‘specialization is better than generalization’, ‘not everything should be a diagram (a = b + c); but not everything can be text (a diagram)’, and my favourite ‘in lisp, refactoring means throwing away the code and starting again; code is cheap, thinking and architecture are hard/expensive’.

Dimitri Simon discussed his Piano product. It was a charming presentation, and it’s easy to see how Dimitri has ended up with every major aeronautical outfit as a customer. The piano system was evolved rather than architected or designed, and has a low 5 figures lines of source code. After sharing the religious experience that was Coral Common Lisp on the Mac II, Dimitri shared some thoughts on lisp from his self-declared ‘non-progammer’s point of view:

  • re-focus on the basics
  • the lisp user audience is not necessarily programmers
  • don’t push lisp features too hard – lisp will stand up on its own once discovered
  • simplicity and stability trump features
  • hide things that are scary (like debuggers and steppers)
  • are editors overloaded? (all you need are indenting, eval, retrieve source…)
  • give lots of examples of saving images and creating apps
  • all that is needed is very elementary graphics (x/y plots; sine waves; not file formats)
  • start at (+ 1 2) not (defun factorial (n)
  • let them make their mistakes (e.g. Fortran mindset)
  • examples, examples, examples

We saw what serious industrial customers demand from the GUI of an application with a 5-6 figure licence fee: fixed-width font text output and simple line graphics.

Michael Wessel discussed RacerPro. He said he’d talk about the role of Lisp if he had time. He didn’t. The semantic web is apparently Web 3.0, and with certain classes of description logics you will be able to draw faulty assumptions about old ladies and cats. Unlike every other presentation there wasn’t even a hint of an actual real-world use.

David McClain told us what had happened to SigLab over the last 2.5 years. Well, it moved from synchronous to asynchronous and became GigaDSP – all the eye-candy and 46k LOC, including a liberal use of CLOS and non-standard method-combinations. But wait – there’s more! There is ButterFLY, the best ideas of Erlang (a weak and primitive language otherwise) translated into 40k lines of lisp code for easy control of distributed computing: software transactional memory for queues and system table updates, but not for everything, and home grown security that is explicitly not OpenSSL. And more! OKeaNOs, a massive distributed object repository with exabyte+ individual file size limits, self-describing objects and self-reliant retrieval. All used for developing and running a 10Gbps radio LAN at 140GHz in the jungles of Vietnam. (Or something.) Interesting observation: when developing you can expect one bug per 10 lines of C code versus 50-100 lines of lisp code.

Hisao Kuroda talked about a bunch of products produced by his team (of 12) Common Lispers. His main observation was that the sheer volume of data now having to be analyzed leads to a requirement for statistical analysis/machine learning/visualization/clustering. He addressed the question ‘Why not R?’ by noting that with their extremely domain-specific solutions they have to get below the level R implements to be able to tweak etc. And, of course ‘you think you know when you can learn … but are certain when you can program’. This led to the question ‘Why Lisp?’, to which the answers were maintainability (on industrial strength implementations), ease of integration, platform independence, and runtime efficiency. But he had some observations for compiler vendors (which I reproduce as verbatim as possible):

  • No CL compiler has standard code optimization
    • constant folding (+ 1 2 3) and (+ 1 n 2)
    • constant propagation (let ((a 1)(b 2))(+ a b))
    • common sub-expression elimination (+ (- x y) (- x y) (- x y))
    • loop optimization
  • SMP
    • SBCL (non-thread safe libraries)
    • LispWorks (alpha)
    • ACL (not at all)
  • BLAS/LAPACK
    • F2CL version is slow and buggy
    • displaced array can’t be optimized
    • maybe it’s impossible to beat Intel MKL
  • SSE instruction support

He had a colleague produce a paper on the compiler performance of ACL, LW and SBCL which he will translate from the Japanese and send to the vendors.

And speaking of compiler implementation, Martin Simmons discussed the new SMP features of LispWorks 6. There was a fair amount of detail here, presented in an engagingly low-key way. As someone commented, the key message was ‘don’t use locks’.

Then came the lightning talks. Adlai Chandrasekhar presented sheeple, a prototype-based object system with multiple dispatch, multiple inheritance and a mainly working MOP. Luke Gorrie pointed us to OpenFirmware as a compilation target and/or a source of device drivers. Jeremy Jones demonstrated cross-platform (OSX, Windows, Linux) GUI development using Cocoa (cocotron/GNUStep) and CCL. Nick Levine gave the first of what I imagine will be many talks of his upcoming O’Reilly book ‘Lisp Outside the Box’ aka the Emu book (looks like a dodo but has a hell of a kick?). Stefan Richter tantalised us with his company’s automated software project management AIs ‘The Deadline’ and ‘Captain Feature’, and impressed (me, anyway) with an approach to the business of producing software that actually trusts programmers (and he recommended The Daemon). Tobias Rittweiler highlighted the results of some recent (paid!) work on Slime: improved autodoc highlighting of keywords; support for named readtables; improved hyperdoc support; fancy macroexpansion; and sensible handling of unwound dx objects. Dieter Hoffman presented Preforma – from meaning to machine processing and back; I have no idea.

Most common shout-outs went to LispWorks and Edi Weitz, with SBCL coming in third. The dinner was pleasant. The drinks afterwards were gruelling. I had fun.

3 Responses to “eclm09 report”

  1. Edi Weitz Says:

    I have to correct the remark I made from memory about the size of Piano. The code base has about 70,000 lines of code. My recollection that it’s pretty much 50/50 between core code and GUI code was right, though.

  2. Arthur Lemmens Says:

    Thanks for the report! I find it hard to believe too, but David McClain’s previous ECLM talk was 3.5 years ago, not 2.5 years. See http://weitz.de/eclm2006

  3. evrim Says:

    ITA is making tests to recruit finest people around the world and you tell me that they are using hunchentooth as a web server? That’s wierd, really wierd.

Leave a Reply