Schon früher in diesem Blog habe ich mich als Ada-Anhänger geoutet. Ich habe in Ada eine komplette CD-/DVD-/BluRay-Brenner-Software geschrieben, weiß also so ungefähr von was ich rede. Die weitaus meisten Zeilen Code habe ich allerdings in anderen Programmiersprachen, vornehmlich in Java, verbrochen.
Schon als ich damals 1996 nach vielen Jahren Ada meine ersten Gehversuche mit Java (Version 1.0.2, die Programmier-Opas erinnern sich) machte, rieb ich mir verwundert die Augen. Wie kann man Mitte der 90er, mit so vielen Vorarbeiten wie Algol und Smalltalk und Pascal und Modula und Ada eine derart rudimentäre, vor allem bei den Basisdatentypen so schwach aufgestellte Sprache wie Java auf den Markt werfen? Es wirkte wie eine minimale OO-Erweiterung wie es sich C-Fans ausmalen würden. Keine Generics, keine Enums, keine funktionalen Elemente, kein vernünftiges Scoping (Methode-in-Methode), kein Operator Overloading, keine „unsigned“-Typen, ein sehr schwaches Konzept der Nebenläufigkeit…vom Sprachstandpunkt aus wirkte es wie ein Zurück-in-die-70er. C, eine Prise Objektorientierung, der Rest des Gehirnschmalzes steckte dann in der Standardbibliothek und der virtuellen Maschine nebst der Applet-Idee.
Seither ist viel Zeit vergangen. Jede Menge Programmiersprachen kamen und die meisten gingen auch wieder. Im Bereich systemnahe Programmierung scheint derzeit Rust immer noch der Hype der Stunde zu sein. Und jeder Ada-Kenner fragt sich: was soll denn an Rust eigentlich so besonders sein? Wäre da Ada nicht von Anfang an und seit 1980 die bessere Wahl gewesen? Um Salz in die Ada-Wunde zu streuen, arbeiten sich die Rust-Evangelisten ja auch immer an C als Benchmark ab, anstatt mal über den Tellerrand zu schauen.
Eine Frage kann ich jedenfalls beantworten: warum Ada keine weitere Verbreitung geschafft hat. Das liegt schlicht am (fehlenden) Ökosystem. Vor GNAT gab es keinen bezahlbaren, qualitativ hochwertigen Compiler. Und seit GNAT gibt es leider immer noch keine problemlos und überall einsetzbare Toolchain. Die von AdaCore gepflegten Pakete haben schon auf der Windows-Plattform ihre Stabilitätsproblemchen wenn man auf die „Libre“-Schiene setzt. Andere CPUs als x86/x64 werden sowieso nur sparsam unterstützt. Jahrelang musste man, wenn man für ARM compilieren wollte, ganz bestimmte FSF-GCC-Versionen einsetzen und extreme Vorsicht walten lassen – meist kam man nicht umhin, GNAT selbst zu bootstrappen. Dazu das IDE-Problem: egal ob Plugins für die großen IDEs wie Eclipse, VisualStudio oder NetBeans, oder Standalone-Pakete wie GPS: die Qualität war bestenfalls durchwachsen, teilweise katastrophal schlecht oder in den Anfängen stecken geblieben (Projekt Hibachi). Und manchmal auch nur ein klassisches „one-off“ wie GNATbench im Libre-Bereich. Geholfen hat sicher auch nicht AdaCore’s Taktik, die Libre-Toolchain GPL-only zu machen. So mussten interessierte Entwickler, die nicht an die GPL gebunden sein wollten, auf die FSF-GCC-Variante ausweichen, mit den ganzen zusätzlichen Reibungsverlusten. Oder die one-offs wie „GNAT for JVM“ oder „GNAT for .NET“ – sowas sorgt einfach nicht für das Gefühl von Stabilität und Verlässlichkeit, eigentlich Stärken von Ada.
Dadurch ergab sich auch eine große Distanz zwischen Hobby-Programmierern und der Profi-Welt: Ada ist ja sehr verbreitet in gewissen Industriebereichen, vor allem Militär und Luftfahrt. Dort dominieren die extrem teuren Ada-Toolchains und IDEs mit ihren zig Zertifizierungen und Gedöns, die Bemühungen z.B. von Aonix mit ObjectAda im Zeitalter von Windows 95 und NT waren auch eher kurzlebiger Natur. Und so leben die Profis in ihrer Welt, und die Hobby-Programmierer verwenden weit überwiegend lieber eine leichter zugängliche Programmiersprache.
Nimmt man dann noch die Problematik „Drittbibliotheken“ dazu, die in der Ada-Welt eher sparsam vorhanden waren, hat man eben einfach kein konkurrenzfähiges Ökosystem, sondern Gefrickel. Untauglich für Neueinsteiger, mühsam für interessierte Hobbyisten, frustrierend selbst für Profis. Immerhin gibt es inzwischen Bemühungen, einen Ada-spezifischen Paket- und Library-Manager zu entwickeln mit dem schönen Namen Alire. Noch Beta. Too little, too late. Auch die Bemühungen um Ada-Unterstützung in Visual Studio Code unterzubringen sind respektabel, stecken aber noch in den Kinderschuhen und sind mit dem Stand anderer Sprachunterstützung wie beispielsweise für Python noch lange nicht vergleichbar.
Will man heute eine Programmiersprache in den breiten Einsatz bringen, reicht eben ein Compiler und ein bisserl Toolchain drumrum bei weitem nicht aus. Man braucht über viele Systeme verfügbare, stabile Toolchains. Man braucht IDEs. Man braucht Bibliotheken. Beispielanwendungen. Dokumentation. Tutorials. Viele Seiten, die sich mit Ada beschäftigen, scheinen direkt dem Internet der 90er entsprungen zu sein (hier z.B. eine ZIP-Bibliothek). Damit kann man bei den Entwicklern von heute einfach nicht mehr in der Breite landen und bleibt im Exotendasein stecken.
Es ist unendlich schade um das Potenzial, das in Ada steckt. Aber meine Prognose lautet: das wird nix mehr. Ada wird zurecht vergessen bleiben.