[FoRK] eclm09 report

Eugen Leitl eugen at leitl.org
Wed Sep 16 08:26:16 PDT 2009


Wish I was there...

http://blog.splittist.com/2009/09/16/eclm09-report/

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

	  o constant folding (+ 1 2 3) and (+ 1 n 2)

	  o constant propagation (let ((a 1)(b 2))(+ a b))

	  o common sub-expression elimination (+ (- x y) (- x y) (- x y))

	  o loop optimization

    * SMP

	  o SBCL (non-thread safe libraries)

	  o LispWorks (alpha)

	  o ACL (not at all)

    * BLAS/LAPACK

	  o F2CL version is slow and buggy

	  o displaced array can’t be optimized

	  o 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 nd GUI code was
right, though.



More information about the FoRK mailing list