Wie viele Programmiersprachen sind zu viel?
Verschiedene Ansätze ermöglichen in zunehmendem Maße, innerhalb eines Projekts unterschiedliche Programmiersprachen zu kombinieren. Doch nicht alles, was technisch möglich ist, ist auch sinnvoll.
- Golo Roden
Verschiedene Ansätze ermöglichen in zunehmendem Maße, innerhalb eines Projekts unterschiedliche Programmiersprachen zu kombinieren. Doch nicht alles, was technisch möglich ist, ist auch sinnvoll. Daher stellt sich die Frage: Wie viele Programmiersprachen sind zu viel?
Interessiert man sich für Programmierung, beschäftigt man sich naturgemäß über kurz oder lang mit einer Programmiersprache. Welche das ist, ist häufig eher dem Zufall oder dem persönlichen Umfeld geschuldet, als dass es eine gezielte Wahl wäre. Doch egal mit welcher Sprache man beginnt – zu Beginn denken die wenigsten Entwickler darüber nach, dass man über kurz oder lang weitere Sprachen wird lernen müssen.
Götz & Golo
"Götz & Golo" ist eine gemeinsame Serie von Götz Martinek und Golo Roden. Der eine ist Geschäftsführer der sodge IT GmbH, der andere CTO der the native web GmbH. Was die beiden vereint, ist ihre große Leidenschaft für die Entwicklung von Software. Seit September 2019 nehmen sie sich monatlich ein Thema vor, zu dem dann jeder seine individuelle Perspektive beschreibt, ohne den Artikel des jeweils anderen im Vorfeld zu kennen. Der zugehörige Artikel von Götz findet sich im Blog von sodge IT. Die Fragestellung zu diesem Beitrag lautete: "Projekte mit vielen Sprachen sind möglich. Aber ist das auch sinnvoll?"
Das ist auch wenig verwunderlich, schließlich bietet eine einzige Programmiersprache zunächst schon einen dermaßen großen Fundus, dass man das Ende davon noch nicht einmal erahnen mag. Mit der Erfahrung wächst jedoch die Einsicht, dass sich nicht alle Programmiersprachen gleichermaßen für verschiedene Aufgaben eignen.
Natürlich sind alle gängigen Programmiersprachen im theoretischen Sinne gleichermaßen mächtig, doch wird wohl kaum jemand auf die Idee kommen, eine Webanwendung in Assembler zu programmieren – auch wenn das durchaus möglich wäre. Doch es ist einfach nicht effizient. Man lernt also nach und nach, dass Sprachen ihre jeweiligen thematischen Schwerpunkte haben und man je nach Bedarf gut beraten ist, eine passende Sprache auszuwählen.
Technische Integration und fachliche Separation
Zunächst wirken unterschiedliche Programmiersprachen wie unterschiedliche Welten, die wenig bis gar nichts miteinander gemein haben und auch nicht miteinander vereinbar sind. Wer C++ programmiert, kombiniert das selten mit Visual Basic. Doch auch hier lernt man im Lauf der Zeit, dass sich verschiedene Sprachen durchaus technisch integrieren lassen, sei es auf Ebene des Linkers oder auf der Basis von virtuellen Maschinen, die Laufzeitumgebungen für verschiedene Sprachen darstellen, beispielsweise die Java Virtual Machine (JVM) oder die Common Language Runtime (CLR).
Hinzu kommt die Möglichkeit zur Integration verschiedener Sprachen über Netzwerkprotokolle. Wer einen Dienst entwickelt, der über HTTP angesprochen werden kann, für den spielt es keine Rolle, ob die Verwender des Dienstes die gleiche oder eine andere Programmiersprache verwenden. Technologie nicht zu einer systemrelevanten Größe werden zu lassen ist so gesehen einer der großen Vorteile einer Microservice-basierten Architektur. Wird Fachlichkeit in verschiedene Dienste zerlegt, können Technologieentscheidungen für jeden Dienst einzeln getroffen werden.
Mit umfangreichen Möglichkeiten geht jedoch auch große Verantwortung einher. Nicht alles, was technisch möglich ist, ist auch sinnvoll. Nachdem man also die Entwicklung von einer einzigen Sprache hin zu einem dienstbasierten Technologiezoo vollzogen hat, stellt sich die Frage: Wie viel ist zu viel? Ist es sinnvoll, jeden Dienst in einer anderen Sprache zu entwickeln? Oder sollte man eher versuchen, einen gemeinsamen Nenner zu finden?
Programmiersprachen haben Schwerpunkte
Um auf diese Frage eine vernünftige Antwort zu finden, muss man sich zunächst vor Augen führen, dass der Einsatz mehrerer Sprachen innerhalb eines Projekts gar nicht so abwegig ist, wie es zunächst scheint: Jede clientseitige Webanwendung basiert letztlich auf HTML, CSS und JavaScript – einfach deshalb, weil Webbrowser nichts anderes ausführen können.
An dem Beispiel zeigt sich auch wunderbar, dass diese drei Sprachen ganz unterschiedliche Schwerpunkte setzen: HTML dient der semantischen Gliederung, CSS der visuellen Repräsentation und JavaScript zur Definition von Verhalten. Allerdings hat man in dem Kontext auch keine andere Wahl: Webbrowser verstehen nun einmal weder C# noch Go, so gerne man diese Sprachen auch einsetzen würde. Das Umfeld bestimmt hier also die Technologie.
Doch was ist mit Server-Anwendungen, die als Backend laufen und nur über Netzwerkschnittstellen angesprochen werden? Wie geht man mit ihnen um? Sind hier unterschiedliche Sprachen für verschiedene Dienste erstrebenswert oder gilt es eher, eine Mischung zu vermeiden?
Technologie ist kein Selbstzweck
Die Antwort auf diese Frage ist eigentlich sehr simpel – und sehr untechnisch: Technologie ist nämlich kein Selbstzweck, sondern erfüllt stets einen (höheren) Zweck. Software wird nicht um ihrer selbst Willen geschrieben, sondern um eine fachliche Anforderung zu erfüllen. Software wird beispielsweise geschrieben, um das Leben von Menschen und/oder Tieren einfacher, sicherer, komfortabler oder auf eine andere Art angenehmer zu machen. Den Fachverantwortlichen ist es daher in der Regel auch gar nicht wichtig, ob für die Realisierung auf Technologie A oder B gesetzt wird.
Was aber wichtig ist, ist, dass die entwickelte Software die fachlichen Anforderungen angemessen erfüllt. Dazu bedarf es Entwickler, die ihre Werkzeuge beherrschen und diese richtig anzuwenden wissen. Daraus lässt sich direkt die erste Prämisse ableiten:
Es ist schwierig und zeitaufwendig, eine Technologie wirklich gut zu kennen und umfangreiche Erfahrung mit ihr zu sammeln. Es ist für eine einzelne Person fast unmöglich, sich in mehreren Technologien beziehungsweise Programmiersprachen gleichermaßen gut auszukennen.
Das heißt, der persönlichen Neugier zum Trotz sollte man für ein Projekt zunächst einmal jene Sprache und Plattform auswählen, mit denen man sich gut auskennt. In meinem persönlichen Fall waren das lange Zeit C# und .NET, inzwischen sind es JavaScript, TypeScript und Node.js. Auch wenn ich persönlich Lisp und Go durchaus spannend finde, fehlt mir schlichtweg die Erfahrung, sie produktiv in der gleichen Qualität einzusetzen – und mir fehlt die Zeit, mir diese Erfahrung anzueignen, wenn ich zugleich den bestehenden Technologiestack nicht vernachlässigen will.
Wenn man sich mit einer Programmiersprache beziehungsweise einer Plattform gut auskennt, weiß man auch um deren Stärken und Schwächen. Es ist also durchaus sinnvoll, nicht alles mit einer einzigen Sprache zu entwickeln – die Frage ist nur, ob man sich selbst mit anderen Sprachen in einem produktiven Umfeld befassen sollte oder ob man das nicht eher anderen überlassen sollte, für die die gewählte Sprache das tägliche Brot darstellt.
Natürlich ist es sinnvoll, über den eigenen Tellerrand zu blicken, um den eigenen Horizont zu erweitern, aber man muss (und kann) nicht alles in der gleichen Tiefe lernen.
Softwareentwicklung ist Teamarbeit
Wie schon in meinem Plädoyer für eine offene und tolerante Kommunikation in der IT-Unternehmenskultur angesprochen, ist Softwareentwicklung keine Sache von Einzelkämpfern, sondern Teamarbeit. Gute Teams zeichnen sich dadurch aus, dass sie einerseits eine gewisse gemeinsame Basis haben, die die einzelnen Teammitglieder verbindet, es aber andererseits auch genug Unterschiede gibt, dass man sich gegenseitig voranbringen und voneinander lernen kann.
In einem Team ist es also durchaus denkbar, dass unterschiedliche Entwickler verschiedene Programmiersprachen einsetzen, weil es aus fachlicher Sicht sinnvoll ist, nicht alles mit einer einzigen Sprache abzudecken.
Man muss aber aufpassen, das verbindende Element innerhalb eines Teams nicht zu verlieren: Verwendet jeder Entwickler nachher eine andere Programmiersprache, ist das Team kein Team mehr, sondern nur noch ein zusammengewürfelter Haufen von Einzelkämpfern. Das Gleiche gilt auf der nächsthöheren Ebene, also teamübergreifend: Es ist nicht sinnvoll, dass jedes Team den Technologiestack komplett neu definiert. Versäumt man das, endet das in chaotischem Wildwuchs, der langfristig gesehen nicht mehr wart- und pflegbar ist.
Die richtige Balance finden
Fasst man das alles zusammen, kann man festhalten, dass es auf die richtige Balance ankommt. Die Anzahl der parallel eingesetzten unterschiedlichen Programmiersprachen, Plattformen und Technologien sollte so niedrig wie möglich, aber so hoch wie nötig sein. Man sollte keine neue Programmiersprache einführen, weil sie einem Entwickler besser gefällt als die vorhandene. Man sollte sie aber einführen, wenn sie deutlich dazu beiträgt, ein fachliches Problem effizienter zu lösen.
Man sollte eine neue Programmiersprache auch nicht deshalb einführen, weil sie gerade angesagt ist. Man sollte sie aber einführen, wenn absehbar ist, dass die bestehende Sprache langfristig nicht mehr tragfähig sein wird, und man allmählich die Weichen für die Zukunft neu stellen möchte.
Sprachinteroperable Plattformen und Microservices sollten also nicht die Motivation sein, unterschiedliche Sprachen einzusetzen. Es ist völlig in Ordnung, wenn eine Landschaft mit einer einzigen Sprache entwickelt wurde. Sprachinteroperable Plattformen und Microservices sind aber die notwendige Voraussetzung, um zu verhindern, dass technologische Entscheidungen zu einer systemrelevanten Größe werden, aus deren Abhängigkeit man sich nie mehr lösen kann. Insofern sind diese Konstrukte durchaus positiv zu bewerten, man darf nur Potenzial und Motivation nicht verwechseln.
Fazit
Zusammenfassend lässt sich also sagen, dass prinzipiell nichts gegen ein Mischen verschiedener Programmiersprachen einzuwenden ist, wenn es dafür gravierende fachliche oder technologische Gründe gibt. Man sollte sich aber hüten, Programmiersprachen nur deshalb zu mischen, weil es technisch machbar ist und weil man damit persönlichen Präferenzen nachgibt.
Insofern ist die richtige Balance wichtig, und es gilt (wie so oft) – so viel wie nötig, so wenig wie möglich.
tl;dr: Es wird immer einfacher, verschiedene Programmiersprachen in Projekten zu kombinieren und zu vermischen. Dafür sollte es aber gute fachliche oder technologische Gründe geben. Man sollte sich außerdem hüten, Technologie als Selbstzweck zu sehen, und persönlichen Präferenzen zu viel Gewicht zu geben. ()
