Some people give me the impression that they have a religious

relationship to CL. Now when a new Lisp dialect shows up, it just has to suck (like basically all other Lisps announced here in the past 6 years). — André Thieme, comp.lang.lisp, 20. Feb 2009

Was geschieht heutzutage in der Lispwelt? Seit der Fertigstellung von ANSI Common Lisp Anfang der 90er Jahre scheint die Entwicklung von Lisp als Sprachfamilie zu stagnieren. Wo man hinblickt, nur zwei Namen: Scheme und Common Lisp.

Nun entwickelt sich Scheme immerhin fort, wenn auch in den Augen vieler in eine völlig absurde Richtung, die die raison d'être der Sprache selbst geradezu in Frage stellt. Man scheint nicht zu wissen, was das Kind eigentlich mal werden soll: eine sehr einfache Sprache und ein Grundgerüst für den Bau von höheren Werkzeugen, oder doch eine als solche praktikable, aber entsprechend weniger hübsche Sprache, die sich mit unschönen Dingen wie Modulen und Syntax herumschlagen muß?

Darüber ist man sich im Lande Common Lisp indes ganz und gar einig: Lisp sollte eine praktisch einsetzbare Sprache sein, die alles für den Programmierer Nötige mitliefert. Mag das Resultat auch wie ein von Kriegen gezeichneter Veteranfrankenstein aussehen — wen kümmert's? Solange die Verwendung Spaß macht, kann einem doch egal sein, ob Theoretiker die Sprache nun besonders elegant finden oder nicht. Da nimmt man auch gern in Kauf, daß viele Dinge über ein systemnahes C-Interface bereitgestellt werden, Frevel hin oder her.

APL is like a diamond. It has a beautiful crystal structure; all of its parts are related in a uniform and elegant way. But if you try to extend this structure in any way — even by adding another diamond — you get an ugly kludge. LISP, on the other hand, is like a ball of mud. You can add any amount of mud to it and it still looks like a ball of mud. — Joel Moses

Naturgemäß passen sich in das Frankensteinmonster Common Lisp alle denkbaren Arten von Erweiterungen ein. Auch größere Paradigmenwechsel können eingebettet werden: Neben den unzähligen Prolog-in-Lisp-Varianten gibt es unter anderem die an Haskell erinnernde funktionale Sprache Qi und Kenny Tilton's Dataflow-Erweiterung Cells.

Einerseits ist das ein schönes Feature von Lisp. Andererseits macht es dies aber gerade für den typischen idealistischen Lisp-Jüngling zu einem harten Brocken, Verbesserungen in der Sprache selbst anzuleiern. Daß welche sinnvoll wären, bestreiten auch die eingefleischtesten Lispveteranen nicht, aber den ANSI-Prozeß neu aufrollen? Die vielen Implementierungen alle auf einen neuen Standard einschwören? Zeit in einen langwierigen Community-Prozeß investieren, dessen Ausgang wahrscheinlich eh nicht sonderlich strahlend sein wird? Nein danke. Schreib doch lieber eine Bibliothek. Schau, Lisp ist so erweiterbar, da geht das.

So kommt es denn auch, daß manch einer versucht, sein eigenes „Common Lisp 2.0“ zu entwerfen — und kläglich am Desinteresse der Gemeinschaft scheitert. Praktisch jeder Verbesserungsversuch wird kurzerhand mit der knappen Feststellung abgetan, die paar Neuerungen seien den mühevollen Umstieg nicht wert, und überhaupt habe man das alles schon vor dreißig Jahren ausprobiert und keiner habe etwas davon wissen wollen. Warum schreibst Du nicht einfach eine Bibliothek?

Man mag versucht sein, diese scheinbar überhebliche Grundeinstellung der Lispgemeinde als reine Bornhiertheit abzutun. In Wahrheit aber handelt es sich um puren Pragmatismus. Wenn eine Sprachfamilie so beschaffen ist, daß man einen Konzept-Interpreter für seinen eigenen Dialekt an einem Wochenende schreiben kann, dann passiert dies nunmal auch jeden Monat mindestens einmal. Würde man jedem der so entstehenden Minidialekte seine volle Aufmerksamkeit widmen, hätte man eine Menge Arbeit, von der man höchstwahrscheinlich nichts hat. Und mal im Ernst: Würde der Gemeinde eine weitere Bibliothek nicht tatsächlich mehr bringen als drei neue Interpreter für inkompatible neue Dialekte, die sich nur oberflächlich voneinander und den schon existierenden unterscheiden?

Geschieht in der Lisp-Welt, um die Frage vom Anfang endlich aufzugreifen, also zwangsweise gar nichts? Auch das wäre eine Fehleinschätzung. Die Wahrheit ist, daß sich auch Lisper nach einem hell leuchtenden Stern am Horizont sehnen, der ihnen die Hoffnung gibt, in etwas Zukunftssicheres zu investieren. Machen wir uns nichts vor: Auch, wenn die Lispgemeinde am Wachsen ist, den Industrieliebling Java wird eine stagnierende Sprache wie Common Lisp nie einholen. Was also tun, um in den Genuß einer größeren Marktakzeptanz zu kommen? Was, um es mit der Fülle von Bibliotheken aufzunehmen, die die Großen zu bieten haben?

Die Antwort scheint heute klar und deutlich sichtbar zu sein: Wir schlagen Java mit seinen eigenen Waffen, und zwar durch — Clojure. Nicht JFLI und nicht ABCL, nicht eine Brücke von Common Lisp nach Java und nicht ein CL-System auf der JVM, sondern ein neues Kind der Lispfamilie. Wie kommt es, daß selbst die scheinbar so sture (man könnte auch sagen: traditionsbewußte) Lispgemeinde diesen frech in modernem Gewand umhersausenden Neuling mit Freude umarmt, wo sie doch bislang jeden anderen, der es versuchte, in einem achtlos gebastelten, wackeligen Korb aufs Meer hinaustreiben hat lassen?

Die Gründe lassen sich nur schwer allesamt erfassen. Was Clojure gegenüber früheren Versuchen der Lispmodernisierung schon einmal klar auszeichnet, ist, daß ihr Papa Rich Hickey mit Common Lisp bereits zum Beginn seines Projekts gut vertraut war und selbst zur Lispgemeinde gehörte. Ihm war bewußt, was an Common Lisp so großartig ist, und er schaffte es, dieses Wissen bei seinem eigenen Sprachentwurf gekonnt zu nutzen. Herr Hickey traf jede seiner Designentscheidungen mit der Kenntnis der Lisptradition im Hinterkopf. Auf diese Weise gelang es ihm, ein Lisp zu entwickeln, das nicht nur neue Märkte anspricht, sondern auch den Lisper, der seine liebgewonnenen kleinen sprachlichen „Lispigkeiten“ nicht ohne einen Kampf hergibt.

Andererseits ist Clojure eben gerade kein Common Lisp 2.0. Papa Hickey ließ sich nicht davon beirren, daß Common Lisp an sich bereits eine sehr gute Sprache war. Er hatte eine Vision, und die zog er durch, ohne mit der Wimper zu zucken. Eine funktionale Sprache sollte es sein. Nebenläufigkeitsfreundlich. Java-kompatibel. Alle schönen Erinnerungen an Common Lisp mußten hinter diesen Grundzielen zurückstecken. Nie die Lispigkeit außer Acht lassen — aber Kompatibilität mit Common Lisp ist kein Kriterium! So zieht folglich auch das typische „Wozu-das-alles-Du-hättest-nur-eine-Bibliothek-schreiben-müssen“-Argument nicht, und auch der erfahrene Lisper wird genötigt, sich Clojure doch ein bißchen genauer anzusehen, um ein Urteil zu fällen.

Wahrung der Lisptradition auf der einen Seite und Mut zu einem Neubeginn auf der anderen: Rich Hickey wäre mit seiner Kreation sehr wahrscheinlich nicht so weit gekommen, hätte er einen dieser beiden Aspekte außer Acht gelassen. Es drängt sich die Frage auf, ob eine weitreichendere Lektion hinter dieser Erkenntnis steckt als bloß eine softwarebezogene.

Wie dem auch sei, Clojure ist hier, und sie wird uns eine Weile lang begleiten. Heißen wir unseren frechen, aber klugen kleinen Neuling willkommen! Möge sie glücklich aufwachsen und zusammen mit ihren Geschwistern die Zukunft prägen.