Montag, 30. November 2009

Ein Lisp für die JVM

In der aktuellen Ausgabe der Toolbox ist mein Beitrag »Lisp für die JVM« erschienen. Es geht um ABCL, das noch nicht allzu alte auf der JVM basierte Common Lisp. Seit ich diesen Artikel geschrieben habe, hat sich bei ABCL einiges getan. Mittlerweile liest man von ersten erfolgreichen Versuchen das Lisp auf Googles AppEngine zu betreiben. Auch der Kern des Systems - der Compiler - wird kontinuierlich weiterentwickelt und optimiert. ABCL mausert sich von einem ursprünglich als experimentell einzustufenden Prototypen zu einer vollwertigen CL-Alternative für den Einsatz im Java-Umfeld. Eine tolle Neuigkeit für mich; nicht nur als Autor, sondern auch als Softwareentwickler.

Und Clojure?

Spricht man momentan von einem Lisp für die JVM, erwarten viele Leser einen Artikel über Clojure. Ich habe Clojure durchaus auf meinem Schirm und werde wohl auch demnächst einen Artikel dazu veröffentlichen - für mich war ABCL allerdings die größere, beeindruckendere Nachricht. Ein praktikables und vollständiges Common Lisp für die JVM ist eine große Leistung.

Ich teile nicht die Ansicht, dass ein moderner neuer Lisp-Dialekt sich unbedingt an eine bestehende Laufzeitumgebung wie die JVM binden muss. Ich bin nicht einmal sicher, ob Rich Hickey diesen Punkt wirklich als Vorteil gegenüber Common Lisp gemeint hat. Für mich ergibt seine Aussage lediglich im Vergleich zu Sprachen wie Python oder Ruby einen Sinn: Viele derartige Skriptsprachen sind in den letzen Jahren erschienen; fast alle bringen ihre eigene Laufzeitumgebung mit sich. Bei einer solchermaßen ad hoc durch lediglich eine Referenzimplementierung spezifizierte Programmiersprache empfiehlt sich diese Vorgehensweise womöglich nicht mehr.

JVM kein Alleinstellungsmerkmal

Common Lisp ist unabhängig von einer konkreten Plattformen spezifiziert worden. Der ANSI-Standard legt die Plattform möglichst wenig fest; wieso nicht auch ein Common Lisp für die JVM oder die CLR entwickeln? ABCL beweist das es möglich ist und das der Standard dazu taugt. Wenn ich einen Artikel über Clojure schreibe, wird eine Fixierung auf die JVM oder CLR eher eine Nebenrolle spielen. Sie wird - wenn überhaupt - eher als Nachteil statt als Vorteil bewertet werden müssen. Clojure macht in seiner Designphase momentan genau diesen Emanzipationsschritt durch, der die VM-Bindung letztlich obsolet werden lässt. Ja - es ist pragmatisch und nützlich, aber die JVM ist kein Alleinstellungsmerkmal für Clojure. In einem Artikel über Clojure fände ich insbesondere interessant, wie viel daran dem üblichen Hype entspricht und was tatsächlich innovativ ist.