Das Problem alternativer Implementierungen (Alternative Implementation Problem)

Das Problem alternativer Implementierungen

Der Autor spricht über das Problem alternativer Implementierungen, das in der Softwarewelt immer wieder auftritt. Seine Erfahrungen stammen vor allem aus der Optimierung dynamisch typisierter Programmiersprachen.

• Das PyPy-Projekt entwickelte einen fortschrittlichen JIT-Compiler für Python, wird in der Praxis aber kaum genutzt. Da Python ständig neue Funktionen hinzufügt und sich weiterentwickelt, war es für PyPy schwierig, mitzuhalten.
• LuaJIT genießt hohes Ansehen, aber da die Sprache Lua fortlaufend neue Funktionen erhält, liegt LuaJIT inzwischen mehrere Versionen zurück.
• Das TruffleRuby-JIT bot die beeindruckendste Performance, hatte aber im Vergleich zu CRuby Defizite bei der Feature-Kompatibilität, weshalb es nur begrenzt ausgerollt wurde.

Lehre: Alternative Implementierungen sind letztlich eine zum Scheitern verurteilte Entscheidung

• Wenn man eine alternative Implementierung erstellt, ist man zwangsläufig von den Änderungen der offiziellen Implementierung abhängig.
• Die offizielle Implementierung kontrolliert die Richtung des Projekts, und die alternative Implementierung kann im Grunde nur folgen.
• Traditionell ist es bei der Entwicklung von JIT-Implementierungen für Interpretersprachen viel schneller, neue Funktionen direkt zum Interpreter hinzuzufügen, sodass die offizielle Implementierung dem JIT voraus sein kann.

YJIT: Implementierung eines Ruby-JIT-Compilers innerhalb von CRuby

• YJIT ist ein weiteres Ruby-JIT, hat sich aber dafür entschieden, direkt innerhalb von CRuby selbst implementiert zu werden.
• Dadurch konnte YJIT von Anfang an mit allen CRuby-Funktionen zu 100 % kompatibel sein.
• Inzwischen ist es das offizielle JIT von Ruby und wird bei Shopify, Discourse, GitHub und anderen eingesetzt.

Lehren aus einer breiteren Perspektive

• Auch die Sprache Crystal, die bestehenden Sprachen ähnelt, aber nicht kompatibel ist, hatte nur begrenzten Erfolg.
• Etwas, das wie eine bestehende Sprache aussieht, aber nicht kompatibel ist, verwirrt die Menschen letztlich nur.
• Beim Entwurf einer neuen Programmiersprache ist es besser, nicht zu versuchen, eine Teilmenge einer bestehenden Sprache zu sein, sondern den eigenen Weg zu gehen.
• Nur so kann man sich in eigenem Tempo und in eigener Richtung weiterentwickeln, ohne an die Performance, Funktionen oder Bibliotheken anderer Implementierungen gebunden zu sein.

Meinung von GN⁺

• Das in diesem Artikel beschriebene „Problem alternativer Implementierungen“ ist ein Aspekt, auf den man nicht nur bei Programmiersprachen, sondern auch beim Bau verschiedenster Software- und Hardware-Systeme achten sollte.
• Wenn man sich nur auf Stabilität und Kompatibilität konzentriert, kann Innovation schwerfallen. Aus Sicht realer Nutzer ist Kompatibilität jedoch ein sehr wichtiger Faktor. Entscheidend ist es, ein Gleichgewicht zwischen neuer Technologie und Benutzerfreundlichkeit zu finden.
• Aus langfristiger Perspektive sollte bei neu gestarteten Projekten gründlich überlegt werden, „mit wem ist es kompatibel?“ und „in welche Richtung soll es sich weiterentwickeln?“.
• Beim Entwurf einer neuen Programmiersprache führt es nur zu mehr Verwirrung, wenn man lediglich die Syntax bestehender Sprachen ähnlich gestaltet. Sinnvoller ist es, die eigene Philosophie und Ausrichtung klar herauszuarbeiten.
• Langfristig scheint die Wahrscheinlichkeit größer zu sein, mit kreativen und originellen Lösungen erfolgreich zu sein als mit reinem Wettbewerb im Markt.

[GN⁺]

Hacker-News-Kommentare

• Wenn man eine neue alternative Implementierung entwickelt und diese eine andere Architektur als die bestehende Version hat, können Dinge, die in der bestehenden Version einfach sind, in der neuen sehr schwierig sein. Wenn proprietäre Software zum Beispiel abschnittsweise lädt/speichert, die neue Version aber das gesamte Dokument in den Speicher lädt, muss möglicherweise die gesamte Architektur der neuen Version geändert werden, um das Hinzufügen von Anhängen zu unterstützen.
• Sich als Alternative zu einer bestehenden Implementierung zu positionieren, ist eine Verlustthese. Projekte, die als "Python + X" vermarktet werden, können nur schwer mit der offiziellen Version konkurrieren. Wenn sie jedoch wie MicroPython für Mikrocontroller entworfen sind und nicht mit CPython konkurrieren, sondern mit anderen Programmierumgebungen für Mikrocontroller, können sie erfolgreich sein.
• Trotz Kompatibilitätsversprechen ist die Kompatibilität in der Praxis oft selbst bei alten Sprachfeatures gering, was ein Grund für das Scheitern alternativer Implementierungen ist. Bei Ruby und Python ist die fehlende Unterstützung für native C-Erweiterungen ein Beispiel dafür.
• Aus der Erfahrung mit der Gründung eines Startups folgt, dass man statt grundlegenden Features hinterherzulaufen besser hätte zeigen sollen, dass die Architektur Enterprise-Features unterstützen kann, und sich auf etwas Differenzierendes konzentrieren sollen.
• Entwickler messen Sprachfeatures und Interoperabilität mehr Bedeutung bei als JIT. Es ist einfacher, ein eigenes paralleles Projekt zu starten, als zu einem bestehenden Projekt beizutragen, aber man sollte sich fragen, für wen es eigentlich gedacht ist. Man muss aufpassen, nicht der Selbstverliebtheit zu verfallen.
• Wrapper-Code weicht vom Standard ab und ist schlecht dokumentiert, was Schmerzen verursacht. Man sollte nur unbedingt notwendige Features hinzufügen und die Standardwerte verwenden.
• Ähnlich sind die Probleme, die TiDB aufgrund der MySQL-Kompatibilität hatte. Theoretisch ist es ein offenes Protokoll, in der Praxis gibt aber Chrome den Ton an.
• Kotlin wurde nicht erwähnt.