Softwareentwicklung: Vor- und Nachteile von Polyglot-Artefakten

In manchen Szenarien macht es in der Softwareentwicklung Sinn ein Entwicklungsartefakt in Form von einem Polyglot umzusetzen. Grundsätzlich bezeichnet man ein Artefakt, dessen Funktionalität in mehreren Programmiersprachen analog umgesetzt wurde als Polyglot. Es können aber auch nur einzelne Teile der gleichen Funktionalität in verschiedenen Programmiersprachen sein, die ein Artefakt zu einem Polyglot machen.
Polyglot-Artefakte sind aufwendig in der Pflege, können aber auch mit Vorteilen wie größerer Interoperabilität punkten. Die nachfolgende Ausführung soll die Vor- und Nachteile von Polyglot-Artefakte aufzeigen.
Die Betrachtung soll sich auf Polyglot-Programmbibliotheken beziehen, um einen festen Rahmen aufzuspannen, kann jedoch auf andere Szenarien transferiert werden. Es wird der komplette Entwicklungszyklus des Artefakts beleuchtet.
Vorweg: Einen hohen Wert sollte man meiner Meinung nach in der Polyglot-Entwicklung auf die von mir als Brückentechnologien bezeichnet legen. Brückentechnologien können die einzelnen Polyglot-Varianten ineinander aufgehen und verschmelzen lassen. Beispiele hierfür sind Standards wie HTTP, die von vielen unterschiedlichen Programmiersprachen unterstützt werden und nach außen hin eine völlig gleiche Funktionalität schaffen können.

Begriffsdefinitionen

• Polyglot-Funktionalität: beschreibt allgemein die Funktionalität, die von einem Polyglot abgedeckt werden soll.
• Polyglot-Variante: eine Variante ist eine Umsetzung der Polyglot-Funktionalität in einer bestimmten Programmiersprache

• bei polyglotten Programmbibliotheken können mehr Anwender/Entwickler erreicht werden: viele Entwickler bevorzugen Programmiersprachen bei denen eine höhere Affinität vorliegt – ein Polyglot kann damit Hemmnisse bzgl. der unterstützten Programmiersprache verringern
• mehr Freiheit bei der Auswahl der Zielplattform: die Auswahl der Ziellaufzeitumgebung wird flexibler durch die steigende Anzahl der Umsetzungen
• Förderung des Austauschs zwischen Entwicklern mit Kenntnissen verschiedener Programmiersprachen
• KnowHow über Funktionalität verschiedener Varianten muss nur für eine Variante erlernt werden. Danach kann das KnowHow auf die anderen Varianten einfach übertragen werden
• Ab einer bestimmten Integrationsstufe können Tests wiederverwendet werden – hier wird jedoch eine Brückentechnolgie notwendig, die den Polyglot ineinander aufgehen lässt, allgemeine Standards: Beispiel http

• Strikte Prozessdefintion des Entwicklungsprozesses; z.B.: jede Variante setzt die Funktionalität auf die gleiche Art und Weise um. Es wird keine Funktionalität in den Hauptentwicklungszweig integriert bevor nicht alle Varianten auf dem gleichen Stand sind.
• Transpiling: durch das Transpilieren einer Programmiersprache, kann eine Polyglot-Variante als Basis genutzt werden. Alle anderen Polyglot-Varianten werden von dieser Variante dann erzeugt. Somit wird die Gefahr verringert, dass die unterschiedlichen Polyglot-Varianten auseinander laufen. Definierte Konventionen, können ein Transpiling vereinfachen,z.B.:
• nur ein Basisset von Sprachkonstrukten nutzen
• Sprachkonstrukte die in anderen Sprachen fehlen durch Konventionen nachstellen (Beispiel: Fehlende Enums durch eine Liste von Konstanten kompensieren und beim setzen eines Wertes prüfen, ob die Konstantenliste diesen Wert enthält) – im Zusammenhang mit verschiedenen javascript-Dialekten von Browsern werden solche Mechanismen auch Polyfill genannt
• Abstrahierung und Standardisierung der Buildprozesse: diese können zum einen die Sicherstellung des regelmäßiges Transpiling vereinfachen, als auch die Einhaltung einer strikten Prozessdefinition vereinfachen

Kurzfristige mögliche Folgen

• kleinere Iterationen innerhalb gleicher Entwicklungszeit möglich
• größere Nutzerkreise

Langfristige mögliche Folge beim verstärkten Einsatz von Polygloten

Verringerung der Segmentierung unterschiedlicher Entwicklungsartefakte: mithilfe einer Brückentechnologie kann erreicht werden, dass die Interoperabilität zwischen den einzelnen Varianten gegeben ist. Somit können die Artefakte ab einem bestimmten Abstraktionslevel bis zu einem gewissen Grad verschmelzen.

Fazit

In vielen Fällen mag die Notwendigkeit eines Polyglots nicht gegeben sein. Grundsätzlich sollte man sich anhand von den Vorteilen, die ein Polyglot mit sich bringt überlegen, ob man diese für sein aktuelles Projekt benötigt und mit den Nachteilen die man sich einkauft leben kann.

Weiterführende Links

http://st.inf.tu-dresden.de/MRT08/papers/MRT08_manuscript18.pdf
https://www.heise.de/developer/artikel/Warum-Polyglot-Programming-nicht-praxistauglich-ist-1479542.html