Irgendwann im Jahr 2019 formulierte der MIT-Doktorand Ajay Brahmakshatriya ein einfaches, wenn auch immer noch ziemlich herausforderndes Ziel. Er wollte es Menschen ermöglichen, die über Fachwissen in einem bestimmten Bereich – wie Klimamodellierung, Bioinformatik oder Architektur – verfügten, ihre eigenen Programmiersprachen, sogenannte domänenspezifische Sprachen (oder DSLs), zu schreiben, auch wenn sie wenig hatten oder keine Erfahrung in der Erstellung von Programmiersprachen. Brahmakshatriya, ein Mitglied der Forschungsgruppe unter der Leitung von MIT-Professor Saman Amarasinghe im Computer Science and Artificial Intelligence Laboratory (CSAIL) des Instituts, wollte, dass diese Sprachen mit allen Hilfsfunktionen ausgestattet sind, die Menschen benötigen, um sie bequem zu nutzen, einschließlich Tools zum Debuggen. Dieser Prozess zum Beseitigen von Fehlern in einer Software ist unerlässlich, waren er und Amarasinghe sich einig, da sie den Mangel an Debugging-Unterstützung als „die Achillesferse für DSLs“ bezeichneten.
Es waren ein paar produktive Jahre für beide. Im Jahr 2021 stellten Brahmakshatriya und Amarasinghe BuildIt vor, ein Softwarepaket, das die Erstellung von DSLs erheblich vereinfacht. Und letzten Monat stellte das Duo auf einer internationalen Konferenz in Montreal, die von der Association for Computing Machinery mitgesponsert wurde, D2X vor, ein Tool, das es einfach macht, Debugging zu jeder DSL hinzuzufügen, und das sich als besonders gut mit BuildIt bewährt hat. Ihr Papier über die Arbeit gewann sogar einen von zwei Distinguished Paper Awards, die auf der Konferenz verliehen wurden.
Der Hauptgrund für die Entwicklung einer Sprache in einem spezialisierten Bereich, erklärt Brahmakshatriya, „ist die Förderung der Benutzerfreundlichkeit“. Eine Bildverarbeitungs-DSL könnte beispielsweise eine Funktion haben, die sagt: „Das gesamte Bild unkenntlich machen“. Das Ausgeben desselben Befehls in einer Allzwecksprache würde viel mehr Codezeilen erfordern, bemerkt Brahmakshatriya. „Das ist einer der Gründe, warum man DSL verwendet. Das andere ist die Leistung.“ Da die Vorgänge für diese Domäne spezifisch sind, können sie leichter optimiert werden – in der richtigen Reihenfolge ausgeführt und somit effizienter und schneller abgeschlossen werden.
Brahmakshatriya beschreibt BuildIt als „eine DSL zum Erstellen von DSLs“. Es erleichtert ein mehrstufiges Verfahren, um eine vorhandene, universell einsetzbare Programmiersprache zu nehmen und sie zu reduzieren, bis sie genau auf die richtige Weise spezialisiert ist. „Angenommen, Sie haben ein Problem und möchten ein Programm schreiben, um es zu lösen“, sagt er. „Sie könnten ein Programm schreiben, um es vollständig zu lösen, oder Sie könnten ein kleineres Programm schreiben, um nur die Unterklasse des Problems zu lösen, an dem Sie interessiert sind. Je spezialisierter Sie das Programm machen, desto schneller läuft es.“ BuildIt wurde entwickelt, um DSLs unter Berücksichtigung dieser Leitprinzipien zu erstellen.
Halide – eine Bildverarbeitungssprache, die 2012 erfunden wurde, Jahre bevor es BuildIt gab – ist eine der ersten DSLs aus Amarasinghes Gruppe. Seine Entwicklung wurde von dem damaligen Doktoranden Jonathan-Ragan Kelley und Andrew Adams, einem CSAIL-Postdoc zu dieser Zeit, geleitet. „Halide ist jetzt sehr beliebt und wird in vielen Adobe-Anwendungen verwendet, einschließlich Photoshop, aber es hat immer noch keinen Debugger“, sagt Amarasinghe. Der Grund dafür, fügt er hinzu, „ist, dass Debugger sehr kompliziert sind. Es ist sehr schwierig, sie zu schreiben, weshalb die meisten kleinen DSLs keine Debugging-Unterstützung haben.“
Laut Brahmakshatriya, der darauf besteht, dass jede DSL ihren eigenen Debugger haben sollte, ist das kein wünschenswerter Zustand. „Sie können vorhandene Debugger nicht direkt für Ihre neue Sprache verwenden, da sie die Domäne nicht verstehen.“ Es ist außerdem unmöglich, ein Programm zu schreiben, das beim ersten Mal vollkommen korrekt ist, sagt er. „Man beginnt immer mit etwas, das Fehler enthält, obwohl sie oft erst viel später im Entwicklungszyklus auftauchen. Wenn an dieser Stelle ein Fehler auftaucht, kann es bei 5.000 Codezeilen sehr schwierig sein, ihn zu finden.“ Folglich müssen Softwareingenieure, sobald ein Programm „Code vollständig“ ist – von seinen Entwicklern als bereit zum Testen erachtet – mehr als die Hälfte ihrer Zeit der mühsamen Aufgabe des Debuggens widmen.
Aber Hilfe ist auf dem Weg in Form von D2X (ausgesprochen „detox“, weil es sich auf die Idee bezieht, Ihr Programm von Giften oder Defekten zu befreien). D2X ist per se kein Programm, sondern wird stattdessen als Bibliothek klassifiziert – ein Stück Computercode, der von anderen Programmen wiederverwendet werden kann. Es ist so konzipiert, dass es mit bestehenden Debuggern (wie GDB oder LLDB) zusammenarbeitet und als Brücke zwischen diesen Tools und einer bestimmten DSL dient. Ein Debugger benötigt Informationen über das Programm oder die Programmiersprache, die bereinigt werden soll. „Jeder Debugger benötigt diese Informationen in seinem eigenen speziellen Format, das ein 400-seitiges Dokument sein kann“, sagt Amarasinghe. „Wenn Sie D2X verwenden, müssen Sie sich darüber keine Gedanken machen. Es ist für Sie erledigt.“
Da D2X als Schnittstelle dient, sagt Brahmakshatriya, „kann Ihr Programm mit gängigen Debuggern ohne Änderungen an den Debuggern selbst debuggt werden.“ Das ist seiner Meinung nach der Hauptvorteil der Kombination von D2X mit BuildIt: „Wenn Sie mit BuildIt eine DSL schreiben, müssen Sie sich keine zusätzliche Arbeit leisten. Sie erhalten einen kostenlosen Debugger, ohne eine einzige zusätzliche Codezeile schreiben zu müssen.“
„D2X adressiert direkt einen inhärenten Widerspruch in Hochleistungssoftware“, kommentiert Adrian Sampson, außerordentlicher Professor für Informatik an der Cornell University. „Auf der einen Seite sind domänenspezifische Sprachen unsere einzige Hoffnung auf ernsthafte Verbesserungen der Recheneffizienz in der modernen Ära. Es ist jedoch schwierig, einen neuen Debugger für eine neue Sprache von Grund auf neu zu erstellen, und das Fehlen eines Debuggers ist ein rationaler Grund, warum ein Programmierer eine „bessere“ Sprache zugunsten einer „schlechteren“ ablehnen könnte. Das Tolle an D2X ist, dass es die Hürde senkt, einen nützlichen Debugger für eine DSL zu konstruieren.“
Aber das ist nicht das Ende der Geschichte, soweit es Brahmakshatriya betrifft. Eine weitere Funktion, die er neben dem Debugging gerne mit BuildIt zusammenführen würde, ist die Bearbeitung, die das Schreiben eines Programms erleichtert. Redakteure können beispielsweise bestimmte Schlüsselwörter in einem Dokument hervorheben, was die Lesbarkeit verbessern kann. Sie können andere Funktionen ausführen, z. B. die automatische Vervollständigung, bei der Text automatisch ausgefüllt wird, nachdem ein kleiner Teil eingegeben wurde.
Brahmakshatriya möchte Profiler zusammen mit Debuggern und Editoren als Teil der BuildIt-Plattform integrieren. „Profiler sind wie Debugger, aber anstatt Ihnen beim Auffinden von Fehlern zu helfen, lassen sie Sie die Leistungsprobleme in Ihrem Programm bewerten“, sagt er. „Wenn das Programm langsamer als erwartet läuft, können Sie mit einem Profiler nachvollziehen, welcher Teil des Programms die Dinge ins Stocken bringt.“ Weitere nützliche Funktionen könnten in Zukunft hinzugefügt werden, sagt er.
All diese Bemühungen, so behauptet Amarasinghe, werden die Aussicht, spezialisierte Sprachen zu schaffen, viel attraktiver machen. „Meines Erachtens gibt es eine große Anzahl von Menschen, die traditionelle Sprachen unterstützen – Tausende von Programmierern, die Tools für C, C++ oder Java erstellen“, sagt er. „Auf der anderen Seite, wenn ich eine einfache DSL baue, habe ich nicht Tausende von Programmierern, die all diese Unterstützung leisten.“ Aber jetzt, mit BuildIt und D2X, fügt er hinzu: „Die kleinen Jungs können all die Dinge bekommen, die die anderen bekommen, einschließlich Debugger und schließlich Editoren und Profiler – die gleichen Vorteile, die mit traditionellen Sprachen einhergehen. Und das können Sie erreichen, ohne Teams von Ingenieuren zu haben, die alle Arten von kompliziertem Code schreiben.“
Diese Arbeit wurde vom Application Driving Architectures Research Center, der US Defense Advanced Projects Agency (DARPA), einem Joint University Microelectronics Program Center, das von der Semiconductor Research Corporation und der DARPA gemeinsam gesponsert wird, unterstützt; die National Science Foundation (NSF); und eine Intel/NSF-Auszeichnung.
