Polyglote Programmierung

Als ich die Überschrift das erste Mal las, dachte ich zuerst es geht um Internationalisierung und UTF-8, aber nein das Thema polyglotte Programmierung ist spannender. Vereinfacht beschreibt polyglotte Programmierung einen Mix aus unterschiedlichen Programmiersprachen zur Lösung von Softwareentwicklungsaufgaben und bildet damit einen einen Gegenpol zu der vor allem Im Java-Bereich dominieren Auffassung, das eine Programmiersprache für alle Probleme (Server, Smartcard, Client, Real Time) reicht. Oder um es sehr plakativ austzzudrücken: Java und C gegen XML und DSL (domain-specific language). Auf der Heise-Seite gibt es eine kritischen kurzen Artikel zur polyglotten Programmierung (http://www.heise.de/developer/artikel/Warum-Polyglot-Programming-nicht-praxistauglich-ist-1479542.html) bzw. ist das Original auf Englisch als Blog Post erschienen (http://lofidewanto.blogspot.de/2011/10/why-is-polyglot-programming-or-do-it.html). Auch wenn ich offen gegenüber neuen Entwicklungen bin, so kenne ich die Konfigurationshöllen ala Spring und Maven. Auch wenn sich heute der Zustand in der Spring Welt verbessert hat, so bestärkt mich der Artikel in meiner Skepsis gegenüber polyglotten Projekten. Ein Problem der polyglotten Entwicklung muss aus meiner Sicht stärker betont werden, das Problem der Wartbarkeit polyglotter Projekte. Ich bin der Meinung, dass polyglotte Projekt entgegen der eigentlichen Ziele der polyglotten Programmierung zu einer höheren Komplexität neigen. Und die Nachteile, mehr Fehler und hohe Änderungsträgheit überwiegen. Aus meiner Sicht sind gut designte Objekte und Pakete nichts weiter als eine Vorform einer DSL. Wichtig ist, die Benennung und die Sichtbarkeit von Objekten und Methoden so einzusetzen, dass man mit ihnen so effektiv umgehen kann, wie man man es von einer DSL erwarten würde.