Das Ausdrucksproblem gilt in der Welt der Programmiersprachen als eine der größten Herausforderungen für Entwickler und Sprachdesigner. Es beschreibt die Schwierigkeit, sowohl neue Datentypen als auch neue Operationen zu bestehenden Datenstrukturen hinzuzufügen, ohne den bereits existierenden Quellcode zu ändern oder neu zu kompilieren – und das alles bei gleichzeitiger Beibehaltung der statischen Typensicherheit. Während bereits zahlreiche Ansätze in diversen Programmiersprachen versucht haben, dieses Problem zu lösen, weist jeder Kompromisse oder Einschränkungen auf, die eine vollumfängliche Lösung bisher verhinderten. Doch eine neue Methode, wie sie vom Entwickler Gavin D. Howard vorgestellt wurde, könnte dieses Problem nun endgültig beheben. Das Ausdrucksproblem entsteht aus dem grundlegenden Konflikt zwischen objektorientierter und funktionaler Programmierung.
Während objektorientierte Sprachen mit Leichtigkeit neue Typen hinzufügen können, ist es oft schwierig, neue Operationen über alle vorhandenen Typen einzuführen, ohne den bestehenden Code anzupassen. Funktionale Sprachen hingegen vereinfachen das Hinzufügen neuer Operationen, erschweren aber zugleich die Erweiterung um neue Typen. Diese Dichotomie führt zu einem starren System, das bei wachsendem Projektumfang und den sich stetig ändernden Anforderungen zur Belastung wird. Traditionelle Ansätze im C++ Umfeld beispielsweise versuchen, durch das Visitor-Pattern Erweiterungen zu ermöglichen, stoßen jedoch am Ende an Grenzen, weil sie typischerweise auf unsichere Casts zurückgreifen müssen, welche die Typensicherheit gefährden. Clojure nutzt zur Lösung Mehrfach-Dynamik dispatchs und Protokolle, wobei es aber die statische Typisierung missachtet und stattdessen dynamische Typen verwendet, wodurch statische Typensicherheit verloren geht.
Haskell bringt seine Typklassen ins Spiel, erleidet jedoch Einschränkungen durch sogenannte „orphan instances“, die dazu führen können, dass Typsicherheit nur eingeschränkt gewährleistet wird und ein Verstoß gegen das „Nicht neu kompilieren“ erfolgen kann. Rust versucht das Problem mit Erweiterungs-Crates und dem sogenannten Orphan-Rule-Ansatz anzugehen, was zwar ein großer Fortschritt ist, dennoch eine gewisse Einschränkung bezüglich der Erweiterbarkeit von bestehenden Typen bleibt, da Erweiterungen nicht beliebig auf bestehende Typen aufgesetzt werden können. Sprachen wie Python, Ruby und Julia verwenden dynamische Typisierung oder Techniken wie Monkey-Patching, die die Erweiterbarkeit zwar maximal erhöhen, jedoch die statische Sicherheit komplett aufgeben und dadurch in professionellen Projekten oft dann nicht in Frage kommen. Go wiederum kann das Problem nur durch unsichere Casts lösen, was aus Typensicherheits-Sicht nicht akzeptabel ist. Gavin D.
Howard schlägt mit seiner neuen Sprache namens Yao einen frischen und überzeugenden Lösungsansatz vor, der den Anspruch, alle Anforderungen des Ausdrucksproblems zu erfüllen, tatsächlich gerecht wird. Das Fundament von Yao besteht darin, dass Traits – also die Schnittstellen oder Interfaces, welche die Definition von Operationen über Typen liefern – nicht wie üblich rein statisch behandelt werden, sondern als Runtime-Werte verfügbar sind. Diese Auslagerung von Traits in den Laufzeitbereich ermöglicht eine bisher ungekannte Flexibilität und erfüllt gleichzeitig die statische Typensicherheit. Im Gegensatz zu traditionellen Methoden, in denen Methoden als Funktionen mit implizitem Selbstargument („self“) implementiert werden, verwendet Yao sogenannte curried Funktionen. Dabei wird die Methode in mehrere einzelne Funktionen zerlegt, die nacheinander aufgerufen werden können und nicht direkt auf eine Instanz angewiesen sind, ähnlich einer teilweise angewendeten Funktion.
Dies erlaubt, dass Methoden an sich selbst Werte besitzen und diese Werte auch außerhalb der eigentlichen Typdefinitionen genutzt und erweitert werden können, ohne dass der Quellcode des Originaltyps geändert werden muss. Ein Beispiel macht die Funktionsweise von curried Methoden in Yao nachvollziehbar: Eine Methode eval gibt eine Funktion zurück, die erst aufgerufen werden kann, wenn sie die erforderlichen Wechselwirkungen mit dem Datentyp ausgeführt hat. Dadurch entstehen völlig neue Möglichkeiten für die Typ- und Operationserweiterung. Die eigentliche Stärke liegt jedoch darin, dass man mit geringem Aufwand neue Implementierungen von Traits für vorhandene Typen als konkrete Werte erzeugen kann, welche dann zur Laufzeit explizit genutzt oder auch kombiniert werden können.
So kann etwa ein Datentyp Constant, der ursprünglich nur eine eval-Funktion unterstützt, durch eine externe Implementierung um eine to_str()-Funktion erweitert werden, die wiederum eine String-Repräsentation des Ausdrucks liefert. Diese Flexibilität erlaubt, dass verschiedene Pakete ihre eigenen Trait-Implementierungen anbieten können, ohne dass Konflikte oder Gefahr für die Konsistenz entstehen. Die Lösung von Howard geht damit weit über die herkömmlichen Grenzen statischer Typisierung hinaus, indem sie eine Mischung aus statischer Typprüfung und dynamischer Trait-Zuweisung schafft. Gleichzeitig wird die Implementierung dieser Traits formell typisiert und geprüft, sodass ein völliger Verzicht auf unsichere Casts oder dynamische Typisierungen möglich ist. Der hybride Ansatz von Yao beruht auf der Überzeugung, dass die Kombination von compile-time-Typen als Konzepte und runtime-Trait-Instanzen als konkrete Werte das Schlüsselprinzip zur Lösung des Ausdrucksproblems ist.
Indem typisierte Traits zur Laufzeit manipulierbar und kombinierbar sind, können beliebig neue Operationen und Datentypen in einem System eingefügt werden, ohne das bestehende System umbauen oder neu kompilieren zu müssen. Natürlich erkauft man sich diese beispiellose Erweiterbarkeit mit gewissen Kompromissen. So sind im Yao-System alle Funktionen technisch gesehen Closures, was eine höhere Laufzeitkosten bedeutet. Auch das Erstellen von Trait-Instanzen zur Laufzeit erfordert zusätzlichen Overhead. Dennoch betrachtet Howard diese Mehrkosten als vertretbar und argumentiert, dass Optimierungen im Compiler diese Nachteile ausgleichen können. Seine Philosophie lautet hierbei „explicit is better than implicit“, was bedeutet, dass der Entwickler bewusst und kontrolliert definieren kann, welche Trait-Implementierungen kombiniert oder verwendet werden.
Ein weiterer großer Vorteil dieses Lösungsansatzes ist die Allgegenwärtigkeit von Currying und Closures, die in Yao nicht nur für Methoden, sondern auch für Funktionen und sogar für das Anlegen von neuen Datentypen verwendet werden. Dies schafft eine einheitliche und flexible Struktur, mit der sich die gesamte Sprache elegant erweitern lässt. Die Möglichkeit, Trait-Instanzen nicht nur konzepteweise zu definieren, sondern tatsächlich als Werte im Programm zu besitzen und zu manipulieren, öffnet ganz neue Türen in der Programmiersprachen-Theorie und -praxis. Denn so kann ein Programm zur Laufzeit sogar entscheiden, welche Implementierung einer Schnittstelle es verwenden möchte – ein Paradigmenwechsel im Vergleich zu herkömmlichen, strikt statischen oder dynamischen Sprachmodellen. Dieser innovative Mechanismus erlaubt es auch, mehrere Implementierungen eines Traits für denselben Datentyp nebeneinander zu definieren und gezielt, je nach Kontext, auszuwählen oder zu kombinieren.
Damit wird das sogenannte Problem der sogenannten „Waisen-Implementierung“ – auch bekannt als „orphan rule“ in Rust oder „orphan instances“ in Haskell – elegant umgangen, ohne die Typensicherheit zu gefährden. Durch solch eine Verschiebung vieler statischer Konzepte in dynamische, dabei aber strikt typgeprüfte und kontrollierte Werte, stellt Yao eine bedeutende Weiterentwicklung dar, die das Ausdrucksproblem auf eine Weise löst, die vorher für unmöglich gehalten wurde. Es ist bemerkenswert, dass dieser Ansatz sowohl die Möglichkeit schafft, neue Datentypen und neue Operationen frei hinzuzufügen, als auch garantiert, dass existierender Code ohne Neukompilation oder Modifikation weiter funktioniert. Somit bewahrt die Sprache sowohl Flexibilität und Erweiterbarkeit als auch Stabilität und Sicherheit. Abschließend lässt sich sagen, dass die vorgestellte Lösung einen Paradigmenwechsel markiert und zahlreiche Diskussionen innerhalb der Community befeuern wird.
Obwohl die Implementierung von Yao noch unvollständig ist und praktische Erfahrungen fehlen, ist das Konzept bereits eine beachtliche theoretische Leistung und könnte die Grundlage für eine ganz neue Generation an Programmiersprachen bilden. Sowohl Entwickler als auch Sprachforscher sollten die Entwicklungen rund um Yao aufmerksam verfolgen, da sie das Potenzial haben, die Art und Weise, wie wir Software heute konstruieren und erweitern, grundlegend zu verändern. Die permanente Suche nach einer perfekten Lösung des Ausdrucksproblems hat nun vielleicht endlich ihr Ziel erreicht – ausgehend von einem tiefen Verständnis der Grenzen bisheriger Ansätze, hat Yao den Schritt gewagt, traditionelle Annahmen über Typen und Schnittstellen in der Programmiersprache radikal neu zu denken.
Die konsequente Verbindung von statischer Typprüfung mit dynamischer Trait-Instanziierung könnte nicht nur die Softwareentwicklung effizienter machen, sondern auch die Innovationskraft bei der Entwicklung zukünftiger Systeme erheblich steigern.
