Eine mehrsprachige Programmierweise hat in letzter Zeit enorm an Beliebtheit gewonnen. Dabei wird idealtypisch das Paradigma verfolgt, immer genau die Sprache zu benutzen, die zu dem jeweiligen Problemfeld passt, anstatt beharrlich innerhalb einer Programmiersprache zu verweilen. Wie man am besten bei der Einführung einer neuen Programmiersprache in einem Unternehmen vorgeht, zeigt Jay Fields in seinem lesenswerten Blogeintrag „Lessons Learned while Introducing a New Programming Language“.

Schwierigkeiten bei der Einführung einer neuen Sprache

Jay Fields gehört dieser polyglotten Avant-garde an, die sich gerne am Repertoire verschiedener Sprachen bedient. In seinem Beruf ist er schon mit einer Menge an Programmiersprachen in Berührung gekommen und hat dabei gelernt, dass jede Sprache, egal ob Java, Cold Fusion, C#, Ruby oder Flex, ihre Vor- und Nachteile haben kann. In seinem Blog berichtet er nun von seinen Erfahrungen bei der Einführung einer neuen Sprache – in seinem Fall die Sprache Clojure im Unternehmen DRW – und stellt fest, dass es sich dabei um eine gar nicht so einfache Aufgabe handelt.

Seine Best Practices teilt er mit der Community:

Zuerst gilt es, überhaupt einmal eine Sprache zu finden, die den technischen Bedürfnissen einer Organisation entspricht und auch von den Mitarbeitern akzeptiert wird. Bringt die Programmiersprache nicht entscheidende Vorteile für den Arbeitsprozess, sollte ihre Einführung erst gar nicht in Betracht gezogen werden. Wie schon der US-amerikanischer Informatiker Alan Perlis feststellte:

A language that doesn’t affect the way you think about programming, is not worth knowing

Um Unterstützung für sein Projekt zu gewinnen, musste Fields einige Verbindlichkeiten zur Einführung von Clojure festlegen:

1. Wenn seine Kollegen am Code arbeiten möchten, würde er, falls gewünscht, mit ihnen arbeiten.
2. Wenn seine Kollegen nicht am Code mitarbeiten möchten, würde er selbst all das reparieren, was kaputt ist.
3. Wenn sich die Einführung der neuen Sprache als zu anspruchsvoll und aufwendig erweisen würde, würde er alles zurück in Java umschreiben.

Natürlich musste die Sprache auch in der etablierten Toolchain der Organisation funktionieren. Immerhin verlangt man einem Team schon so einiges ab, wenn man von ihm das Erlernen einer neuen Sprache fordert – da sollte man nicht auch noch erwarten, dass das Team die prinzipielle Art und Weise verändert, wie und mit welchen Tools es arbeitet. Für Fields war dies keine schwierige Aufgabe: Clojure ist mit Hilfe des La Clojure Plug-ins in der IntelliJ IDE fast genauso einfach ausführbar wie Java.

Sind alle praktischen Fragen zur Einführung der neuen Sprache geklärt, gilt es, sich in die Thematik einzuarbeiten und gegebenenfalls Hilfe bei Experten zu suchen. Erklären sich der Erfinder der Sprache oder leitende Persönlichkeiten aus der Community bereit, Hilfestellung zu leisten – umso besser. Als Initiator der Sprachreform trug Fields eine enorme Last auf den Schultern: Sollte irgendetwas schief gehen, würde ohne Zweifel er dafür verantwortlich gemacht werden. Ein Grund mehr, stets allumfassend und ausführlich informiert zu sein.

Letztendlich gilt jedoch: Man sollte niemanden dazu zwingen, eine neue, ihm noch völlig unbekannte Programmiersprache zu erlernen. Innerhalb der DRW Trading Group bildeten sich sogar zwei separate Teams, eins davon arbeitete mit dem neuen Clojure, das andere weiterhin mit Java.

Wie viele Sprachen braucht der Entwickler?

So viel zu den Schwierigkeiten, die einem begegnen könnten, wenn man sich daran macht, eine neue Programmiersprache in einer Organisation einzuführen. Nicht beantwortet bleibt natürlich die Frage, ob es überhaupt Sinn macht, neue Sprachen einzuführen! Sollte man sich nicht vielmehr darauf konzentrieren, eine einzige Sprache effizienter zu machen und damit die babylonische Sprachverwirrung innerhalb der Entwickler-Community ein für allemal zu beenden?

JAXenter-Leser dürften sich an Lofi Dewanto erinnern, der sich nach anfänglicher Begeisterung für die polyglotte Programmierweise doch für eine universelle Programmiersprache, die in der Lage ist, alle Problemfelder einer Anwendungsentwicklung zu schließen, ausgesprochen hat. Beim polyglotten Programmieren sah er u.a. das Problem, Fachleute ausfindig zu machen, die gleich mehrere Programmiersprachen flüssig beherrschen und diese effizient verwenden können. Auch das Tooling vieler neuer Sprachen sei noch lange nicht auf dem Stand von Java angekommen, weshalb er eine Rückbesinnung auf die Tugenden von Java als universelle Sprache vorschlägt.

Ähnlich wie übrigens der Anbieter sozialer Enterprise-Netzwerke Yammer. Sie erinnern sich: Hatte Yammer im August 2010 damit begonnen, Teile seiner Software-Architektur auf Scala-Basis zu entwickeln, ist man knapp ein Jahr später wieder zurückgekehrt zu Java. Die Komplexität Scalas wiege die Produktivitätsvorteile nicht auf – so die offizielle Begründung.

Welcher Meinung sind sie? Verwenden Sie viele verschiedene Sprachen, je nach Charakteristik des Problems? Oder beschränken Sie sich lieber auf eine einzige Programmiersprache, möglicherweise sogar auf Java? Vielleicht teilen Sie ja auch die Ansicht Matt Foemmels, der für sich selbst feststellte:

I hate all programming languages