Warum Polyglot Programming nicht praxistauglich ist

Eine große Herausforderung für Entwickler ist es herauszufinden, ob es überhaupt sinnvoll ist, eine Programmiersprache nur für einen bestimmten Einsatzzweck zu verwenden. Reicht es nicht aus, nur eine Sprache für alle mögliche Zwecke zu nutzen? Eine kritische Auseinandersetzung mit Polyglot Programming und dem Sinn neuer JVM-Sprachen.

Martin Fowler ist erstmals 2005 in seinem Artikel "Language Workbenches: The Killer-App for Domain Specific Languages?" auf die Programmierung mit speziellen Werkzeugen zur Entwicklung von Sprachen eingegangen. Mit ihnen soll es möglich sein, kleine spezifische Programmiersprachen, sogenannte Domain Specific Languages (DSL), zu entwerfen und umzusetzen. In Fowlers Konzept wird eine DSL als die Zukunft der Programmierung angesehen. Neal Ford führte dann 2006 den Begriff Polyglot Programming für die Kombination mehrerer Programmiersprachen in einer Anwendungsentwicklung ein. Auf dieser Basis entwarf wiederum Fowler das Paradigma Polyglot Persistence,das die Verwendung unterschiedlicher Datenbanktypen in einer einzigen Anwendung ermöglichen soll.

Der Autor beschäftigt sich mit dem Mehrsprachen-Paradigma seit 2006. Damals sah er darin noch die Zukunft zum Beispiel der Java-Programmierung, nach der sich gleich mehrere Sprachen auf der Java Virtual Machine (JVM) ausführen lassen.

Erfahrungen damit sammelte er in einem Projekt, in dem verschiedene Sprachen und DSLs zum Einsatz kamen: UML wurde für den Entwurf der Business-Objekte eingesetzt. Über das Konzept der MDA (Model Driven Architecture) wurden Artefakte generiert. Java kam für die Implementierung der Backend-Anwendungen zum Einsatz. Die Skriptsprache Groovy verwendete das Team für die Erweiterung der Backend-Anwendungen und vor allem für das Schreiben der Unit-Tests. Mit ANTLR entwarf und erstellte es eine eigene DSL für spezielle Aspekte der Anwendung. Das Projekt war aufregend, und einige gute Programmierer waren im Projekt involviert. Ein flexibles Produkt wurde erstellt, und es erfüllte die gestellten Erwartungen. Das ist alles in einem Erfahrungsbericht (PDF) nachzulesen.

Gründe gegen Polyglot Programming

Trotz dieser guten Erfahrungen ist nach Ansicht des Autors das Mehrsprachenkonzept in der Praxis gescheitert. Im Folgenden seien einige Gründe dafür genannt:

1. Da es keine leichte Aufgabe ist, eine oder gleich mehrere Programmiersprachen gut zu beherrschen, sollte grundsätzlich überlegt werden, ob man eine neue Programmiersprache beziehungsweise eine mittelkomplexe DSL zum Beispiel dem "gewöhnlichen", in einem Wartungsprojekt arbeitenden Entwickler Programmierer beibringen will. Nicht jeder ist gleichermaßen motiviert und nicht jeder ist scharf darauf, eine neue Sprache zu erlernen.
2. Wer Erfahrungen in der Entwicklung beispielsweise einer großen Java-Webanwendung mit Struts und AJAX besitzt, weiß, wie aufwendig es ist, eine neue Funktion einzuführen. Man wird mit dem Erstellen und Bearbeiten einer Menge unterschiedlicher Dateien konfrontiert, beispielsweise mit Action- und Formular-, XML-Konfigurations-, JavaScript- und auch HTML- oder JSP-Dateien. Es stellt sich die Frage, ob es angesichts der ohnehin hohen Komplexität da anzuraten ist, Groovy, Scala oder Dart in so einem Projekt zusätzlich einzuführen.
3. Das Arbeiten mit einer neuen Programmiersprache bedeutet auch, dass deren Umfeld gut durchdacht sein muss. Eine gute Entwicklungsumgebung, ausreichend Dokumentationsmaterial und Community-Unterstützung sowie eine eindeutige Roadmap und Abwärtskompatibilität sind hier zu nennen. Dafür ist Groovy ein schlechtes Beispiel. In der Frühzeit dieser Sprache war etwa der Editor für Eclipse nicht brauchbar. Nach einer Weile wurde er zwar besser, aber die Sprache erhielt eine Menge grundlegender Veränderungen, sodass alte Groovy-Anwendungen nicht mehr funktionierten. Es gab keinen Weg daran vorbei, auf eine neue Version der Sprache zu aktualisieren. Mit Java 1.1 erstellte Anwendungen lassen sich im Gegensatz dazu immer noch mit Java 6 kompilieren.
4. Bevor eine eigene Sprache beziehungsweise eine DSL entworfen und erstellt wird, sollten zunächst Sprachexperten befragt werden, wie schwer und aufwendig es ist, eine Programmiersprache langfristig zu warten. Besonders wenn man für KMUs (kleine und mittelständische Unternehmen) arbeitet, ist die Größe des Teams und das Budget zu beachten, denn die Wartung einer eigenen Sprache beziehungsweise DSL kann schnell zum Albtraum werden.
   

Fazit

So kommt der Autor sechs Jahre nach seiner anfänglichen Begeisterung für Polyglot Programming zu folgendem Bild in der Java-Welt:

• Eine einzige Sprache für alle Aspekte in einer Anwendungsentwicklung – "One for All Programming Language Paradigma" – ist für ihn das beste Konzept. Dem vollends nachzukommen ist wahrscheinlich unrealistisch, aber zumindest anzustreben. In der Java-Welt ist das beste Rezept womöglich immer noch die Kombination aus Java und XML (vielleicht weniger XML). Die Integration mit Groovy, Dart, Ruby, Scala oder irgendwelchen DSLs in einer Anwendung führt schnell zum Chaos.
• Besonders Programmierneulinge tendieren dazu, gerade angesagte, neue Sprachen partout einführen zu wollen, ohne dass deren Integration wohldurchdacht ist. Das soll nicht heißen, dass keine andere Programmiersprachen außer Java eingesetzt werden sollten. Wichtig ist, das Verhältnis von Kosten und Nutzung bei der Einführung einer neuen Programmiersprache oder einer neuen DSL ausdrücklich zu beleuchten.
• Wer für KMUs arbeitet, sollte aus den oben genannten Gründen vorsichtig sein, eine neue Programmiersprache oder DSL einzusetzen.
• Für das Paradigma einer einzigen Programmiersprache für alle Aspekte in einer Anwendungsentwicklung sind im Java-Bereich folgende Konzepte interessant:

1. GWT (Google Web Toolkit) GWT ist ein Compiler, der aus Java JavaScript-Code erzeugt. Damit können Entwickler mit Java in ihrer gewöhnten Umgebung arbeiten, um interaktive Benutzeroberflächen – ganz ohne JavaScript – für das Web zu implementieren.
2. XMLC (XML Compiler): XMLC generiert aus XML und HTML Java-Klassen. Auf dieser Basis können Java-Entwickler XML- und HTML-Objekte ausschließlich mit Java manipulieren.
3. Bei der Auswahl von Frameworks sollte man auf die Anbindungstechniken achten. Ein Framework, das sich ausschließlich mit Java einbinden lässt, sollte bevorzugt werden, etwa Guice: Das Dependency-Injection-Framework verwendet ausschließlich Java. Eine XML-Konfiguration wird nicht benötigt. Damit verhält es sich anders als beispielsweise das Spring Framework oder JBoss Weld, die zur XML-Konfiguration applicationContext.xml beziehungsweise beans.xml verwenden. (Zugegeben, die XML-Nutzung kann sowohl bei Spring als auch Weld heute sehr gering sein.)
   

• Last, but not least: Java als einzige Programmiersprache einzusetzen ist auch deswegen keine schlechte Idee, weil die Android-Community ebenfalls in Java programmiert. Damit hat sich das Paradigma "Learn Once Use Everywhere" auch heute noch bewahrheitet.

Dr. Lofi Dewanto
arbeitet als Softwareentwickler bei der Deutschen Post. Er engagiert sich insbesondere für "javanische" Open-Source-Software sowie MDA. (ane)