Um beide Sprachen einzuordnen, hilft die Abstammungslinie. Ende der 1960er- und Anfang der 1970er-Jahre entwarf Wirth Pascal als Lehr- und Anwendungssprache für strukturierte Programmierung. Aus den Erfahrungen mit Pascal – und mit einem parallelen, an Nebenläufigkeit orientierten Experiment namens Modula – entstand Ende der 1970er-Jahre Modula-2. Es fügte Pascal das hinzu, was für größere Systeme fehlte: ein echtes, in die Sprache eingebautes Modulkonzept. Rund ein Jahrzehnt später, Ende der 1980er-Jahre, ging Wirth mit Oberon den entgegengesetzten Weg und reduzierte die Sprache radikal auf einen kleinen, sehr eleganten Kern.
Drei Punkte fassen zusammen, warum diese Sprachen bis heute bemerkenswert sind:
Niklaus Wirth zählt zu den einflussreichsten Sprachschöpfern der Informatikgeschichte und wurde für seine Arbeiten mit dem renommiertesten Preis des Fachs, dem Turing Award, ausgezeichnet. Seine Sprachen entstanden nicht als Selbstzweck, sondern als Werkzeuge für Lehre und für den Bau realer Systeme an der ETH Zürich. Diese Doppelrolle – gleichzeitig didaktisch klar und praktisch tragfähig zu sein – prägt Modula-2 und Oberon bis in die Details.
Ein Leitgedanke, der oft mit Wirth verbunden wird, lautet sinngemäß: Software solle so einfach wie möglich gemacht werden, aber nicht einfacher. Ebenso bekannt ist die nach ihm benannte Beobachtung, dass Software oft schneller langsamer wird, als die Hardware schneller wird – ein pointierter Kommentar zur wachsenden, häufig unnötigen Komplexität moderner Programme. Diese Grundhaltung ist der rote Faden hinter beiden Sprachen und der Grund, warum sie bis heute als Referenz für durchdachtes Sprachdesign gelten.
In ihrer aktiven Zeit waren Modula-2 und Oberon durchaus praktische Werkzeuge: Modula-2 wurde für Systemprogrammierung, eingebettete Systeme und Lehre eingesetzt, Oberon trug ein komplettes, an der ETH entwickeltes Arbeitsplatzsystem. In der breiten kommerziellen Softwareentwicklung setzten sich jedoch andere Sprachen durch – vor allem C und später C++, die vom industriellen Umfeld getragen wurden. Modula-2 und Oberon blieben stärker im akademischen und spezialisierten Umfeld verankert.
Für ein Unternehmen ist die eigentliche Relevanz dieser Sprachen daher weniger die Frage, ob man heute noch in ihnen entwickelt – das ist die Ausnahme –, sondern die Ideen, die sie in die Welt gebracht haben. Modularität, saubere Schnittstellen, Typsicherheit und die Disziplin der Einfachheit sind aus diesen Sprachen in die Breite gewandert. Wer sie versteht, versteht besser, warum moderne Sprachen so gebaut sind, wie sie es sind.
Der vielleicht wichtigste Beitrag von Modula-2 ist die Erhebung des Moduls zum erstklassigen Sprachbestandteil. Ein Modul bündelt zusammengehörige Daten und Funktionen und legt fest, was davon nach außen sichtbar ist und was verborgen bleibt. Dieses Prinzip der Kapselung – die Trennung zwischen dem, was ein Baustein anbietet, und dem, wie er intern funktioniert – ist heute in praktisch jeder ernstzunehmenden Sprache Standard. Zu ihrer Entstehungszeit war es eine bemerkenswert klare Umsetzung eines damals noch jungen Gedankens.
Für den Aufbau großer, wartbarer Systeme ist das entscheidend: Module lassen sich unabhängig voneinander entwickeln, testen und austauschen, solange die vereinbarte Schnittstelle stabil bleibt. Genau diese Idee steckt heute in Konzepten wie Paketen, Namespaces und Bibliotheken. Wer verstehen will, warum saubere Modulgrenzen der Schlüssel zu wartbarer Software sind, findet in Modula-2 die vielleicht klarste historische Blaupause.
Während viele Sprachen über die Jahre immer mehr Features anhäufen, ging Wirth mit Oberon den umgekehrten Weg. Aus der Erfahrung mit dem gewachsenen Modula-2 destillierte er einen kleinen, in sich stimmigen Kern und ließ konsequent alles weg, was er für verzichtbar hielt. Das Ergebnis ist eine Sprache, die sich in kurzer Zeit vollständig überblicken lässt – ein bewusster Gegenentwurf zu der Komplexität, die Wirth als Hauptursache schlechter Software ansah.
Diese Haltung ist mehr als eine akademische Fingerübung. Sie ist eine der wirkungsvollsten Aussagen über Softwarequalität überhaupt: Nicht was eine Sprache oder ein System alles kann, ist entscheidend, sondern wie klar und beherrschbar es bleibt. Für Unternehmen, die mit ausufernder Komplexität ihrer eigenen Systemlandschaften kämpfen, ist dieser Gedanke unmittelbar anschlussfähig, auch ganz ohne eine Zeile Oberon-Code.
Das erste und wichtigste Konzept ist das bereits beschriebene Modulsystem. In Modula-2 wird dabei eine für die Zeit ungewöhnlich saubere Trennung gezogen: Die Beschreibung dessen, was ein Modul anbietet, ist getrennt von der Beschreibung, wie es das leistet. Man kann also die Schnittstelle eines Bausteins verstehen und nutzen, ohne seine innere Umsetzung zu kennen. Diese klare Trennung von „Was“ und „Wie“ ist eines der wirkungsvollsten Werkzeuge, um große Systeme beherrschbar zu halten, und sie ist der direkte Vorfahr vieler heutiger Schnittstellen-Konzepte.
Beide Sprachen sind streng statisch typisiert. Das bedeutet: Der Compiler prüft schon vor der Ausführung, ob Werte und Operationen zueinander passen, und weist unstimmige Verwendungen zurück. Ein großer Teil der Fehler, die in schwächer typisierten Sprachen erst im laufenden Betrieb auffallen, wird so bereits beim Übersetzen sichtbar. Für sicherheitskritische oder langlebige Software ist das ein erheblicher Gewinn an Verlässlichkeit – man verlagert die Fehlersuche vom Kunden zurück an den Schreibtisch.
Wirths Sprachen sind dabei bewusst diszipliniert: Sie erschweren die riskanten, trickreichen Umgehungen des Typsystems, die etwa in C alltäglich sind. Wo systemnahe Programmierung zwingend den Zugriff auf Speicher und Hardware erfordert, kapseln Modula-2 und Oberon diese Möglichkeiten in klar benannte, abgegrenzte Bereiche – man muss die Sicherheitszone also ausdrücklich verlassen, statt versehentlich hineinzustolpern. Dieser Grundsatz, unsichere Operationen sichtbar und lokal zu machen, ist bis heute ein Kennzeichen guten Sprachdesigns.
Ein aufschlussreicher Kontrast liegt zwischen den beiden Sprachen selbst. Modula-2 ist reichhaltiger ausgestattet – es bietet unter anderem Sprachmittel für nebenläufige Abläufe und einen vergleichsweise umfangreichen Fundus an Konstrukten für die Systemprogrammierung. Oberon dagegen ist das Ergebnis einer bewussten Diät: Wirth strich viele Konstrukte, die er als verzichtbar oder fehleranfällig ansah, und ergänzte im Gegenzug ein einziges, schlankes Erweiterungskonzept für Datentypen sowie eine automatische Speicherverwaltung.
Diese Typerweiterung erlaubt es, Datentypen aufeinander aufbauen zu lassen – ein minimalistischer Zugang zu Ideen, die man aus der objektorientierten Programmierung kennt, jedoch ohne deren vollen begrifflichen Apparat. Zusammen mit der automatischen Speicherbereinigung, die Oberon einführte, zeigt sich hier Wirths Grundüberzeugung: Lieber wenige, gut gewählte und sauber zusammenspielende Konzepte als eine Fülle von Funktionen, die einander überlappen und in Summe schwer zu überblicken sind.
Für Modula-2 entstanden im Laufe der Zeit mehrere Compiler unterschiedlicher Herkunft, sowohl im akademischen Umfeld als auch als kommerzielle Produkte für verschiedene Plattformen. Für Oberon gibt es ebenfalls mehrere Umsetzungen, darunter die originalen Werkzeuge aus dem ETH-Umfeld sowie Portierungen, die das System auf moderne Betriebssysteme oder in den Browser bringen. Welche dieser Implementierungen aktiv gepflegt werden und auf welchen Plattformen sie heute laufen, ändert sich und sollte im konkreten Fall geprüft werden.
Wichtig für die Einordnung ist: Die Werkzeuglandschaft ist nicht mit der eines heutigen Mainstreams vergleichbar. Es gibt kein riesiges, kommerziell getragenes Ökosystem mit umfassenden Entwicklungsumgebungen, Paket-Verzeichnissen und breiter Werkzeugunterstützung. Stattdessen handelt es sich um ein kleines, engagiertes Umfeld – teils akademisch, teils von langjährigen Enthusiasten getragen. Für spezialisierte oder lehrbezogene Zwecke ist das ausreichend; für eine breite kommerzielle Neuentwicklung wäre es eine ungewöhnliche und begründungsbedürftige Wahl.
Die eigentliche Besonderheit ist das Oberon-System. Wirth und Jürg Gutknecht entwickelten nicht nur die Sprache, sondern gleich ein ganzes Betriebssystem mit grafischer Oberfläche, geschrieben in eben dieser Sprache. Das Ziel war, zu zeigen, dass ein voll funktionsfähiges System mit erstaunlich wenig Code und in hoher Klarheit realisierbar ist – ein bewusster Gegenentwurf zu der schon damals wachsenden Komplexität kommerzieller Betriebssysteme.
Das System führte zudem ungewöhnliche Bedienkonzepte ein, etwa eine sehr enge Verzahnung von Text und ausführbaren Befehlen. Für den heutigen Unternehmenseinsatz spielt das keine Rolle, doch als Studienobjekt ist das Oberon-System bis heute wertvoll: Es demonstriert, wie weit man mit konsequenter Reduktion kommt, und dient in der Ausbildung als anschauliches Beispiel dafür, wie Sprache, Übersetzer und Betriebssystem ineinandergreifen. Das begleitende Werk, in dem Wirth und Gutknecht den kompletten Aufbau offenlegen, gilt als Klassiker für alle, die verstehen wollen, wie ein System vom Prozessor bis zur Oberfläche aufgebaut ist.
Rund um Oberon entstand über die Jahre eine kleine Familie weiterentwickelter Sprachen. Dazu gehören eine erweiterte Fassung, die das Konzept der an Datentypen gebundenen Operationen ausbaute, sowie Varianten, die stärkere Unterstützung für Nebenläufigkeit oder eine engere Anlehnung an verbreitete Komponentenmodelle boten. Diese Ableger fanden teils in bestimmten Nischen und in der Lehre Verwendung, blieben in der Summe aber ebenfalls spezialisiert.
Für die Praxis heißt das: Wer sich mit diesen Sprachen befasst, sollte zwischen der reinen historischen Beschäftigung, dem Einsatz in der Lehre und einem etwaigen produktiven Einsatz unterscheiden. Der jeweils aktuelle Zustand der Werkzeuge, ihre Pflege und die verfügbaren Plattformen sind entscheidend und sollten stets am aktuellen Stand überprüft werden, bevor man sich auf eine konkrete Umsetzung festlegt.
In ihrer aktiven Zeit war die Systemprogrammierung das ambitionierteste Einsatzfeld. Modula-2 wurde bewusst so entworfen, dass es die hardwarenahen Aufgaben, für die man sonst zu C griff, in einem sichereren, klarer strukturierten Rahmen erledigen konnte. Oberon ging noch weiter und trug ein komplettes Arbeitsplatzsystem. Beides belegt, dass es sich nicht um reine Lehrsprachen handelte, sondern um Werkzeuge, mit denen reale, anspruchsvolle Systeme gebaut wurden.
Dass sich diese Stärke nicht in einen breiten kommerziellen Erfolg übersetzte, lag weniger an technischen Mängeln als an der Marktdynamik: C und später C++ hatten ein größeres, industriell getragenes Ökosystem und eine breitere Personalbasis. Für die historische Würdigung bleibt festzuhalten, dass Modula-2 und Oberon technisch vorführten, wie sichere Systemprogrammierung aussehen kann – eine Frage, die heute mit modernen Sprachen erneut intensiv diskutiert wird.
Das mit Abstand robusteste Einsatzgebiet ist die Ausbildung. Gerade weil beide Sprachen einen kleinen, klaren Kern haben, sind sie ideal, um grundlegende Konzepte zu vermitteln: strukturierte Programmierung, Modularität, Typsicherheit und die Disziplin, Komplexität zu vermeiden. Lernende werden nicht von einer Fülle von Sonderfällen und Bequemlichkeitsfunktionen abgelenkt, sondern können sich auf das Wesentliche konzentrieren.
Für ein Unternehmen ist das indirekt relevant: Fachkräfte, die ihre Ausbildung mit solchen Sprachen begonnen haben, bringen oft ein besonders klares Verständnis von sauberem Aufbau mit. Und für die interne Weiterbildung kann die bewusste Auseinandersetzung mit einer radikal einfachen Sprache wie Oberon ein wirksames Mittel sein, um den Blick für unnötige Komplexität in den eigenen, modernen Projekten zu schärfen.
Die vielleicht direkteste Linie führt zu Go. Eine der prägenden Personen hinter Go war ein Schüler Wirths aus dem ETH-Umfeld, und Go trägt diese Herkunft sichtbar: Es setzt auf ein klares Paketsystem, eine bewusst kleine, schnell erlernbare Syntax, schnelle Kompilierung und die Grundüberzeugung, dass Einfachheit ein Wert an sich ist. Wer Gos Philosophie kennt, erkennt darin unmittelbar den Geist der Wirth-Schule: lieber wenige, gut gewählte Konzepte als eine überladene Sprache. Go ist damit ein zentrales Beispiel dafür, dass die Ideen von Modula-2 und Oberon in einer der wichtigsten modernen Sprachen weiterleben.
Das mit Modula-2 popularisierte Modulkonzept ist heute Allgemeingut. Was damals eine bemerkenswert klare Neuerung war – die Sprache selbst zwingt zu gekapselten Bausteinen mit definierter Schnittstelle –, findet sich heute in nahezu jeder ernstzunehmenden Sprache in Form von Modulen, Paketen oder Namespaces. Die konkrete Ausgestaltung unterscheidet sich, doch der Grundgedanke ist derselbe: klar abgegrenzte Einheiten, die verbergen, was sie intern tun, und nur ihre Schnittstelle offenlegen.
Für die Praxis bedeutet das: Wenn heutige Entwickler über saubere Paketstrukturen, Abhängigkeitsmanagement und stabile Schnittstellen sprechen, bewegen sie sich auf einem gedanklichen Fundament, das Wirth mit Modula-2 maßgeblich mitgelegt hat. Dieses Erbe ist unsichtbar, aber allgegenwärtig – ein gutes Beispiel dafür, wie stark Grundlagenarbeit an Sprachen die tägliche Praxis prägt, lange nachdem die ursprüngliche Sprache aus dem Rampenlicht verschwunden ist.
Ebenso einflussreich ist Wirths Haltung zur Einfachheit. Über die Jahrzehnte hat sich in der Sprachentwicklung ein Muster wiederholt: Auf Phasen wachsender Komplexität folgen immer wieder Sprachen, die bewusst reduzieren und Klarheit über Funktionsfülle stellen. Diese Gegenbewegung, die man bei Go besonders deutlich sieht, aber auch bei anderen jüngeren Sprachen findet, ist im Kern eine Wiederaufnahme dessen, was Oberon bereits vorführte.
Auch die aktuelle Debatte um sichere Systemprogrammierung – die Frage, wie man hardwarenahe Software schreibt, ohne die typischen, gefährlichen Fehlerquellen älterer Sprachen – knüpft an Fragen an, die Wirth früh gestellt hat. Modula-2 und Oberon waren Versuche, Systemprogrammierung sicherer und klarer zu machen. Dass genau dieses Ziel heute mit modernen Sprachen erneut verfolgt wird, unterstreicht, wie vorausschauend die Grundfragen der Wirth-Sprachen waren.
Pascal ist der direkte Vorläufer und teilt Grundhaltung wie Erscheinungsbild. Modula-2 lässt sich am besten als konsequente Weiterentwicklung verstehen: Es übernimmt Pascals Klarheit und Typsicherheit und ergänzt das, was für größere Systeme fehlte – vor allem ein echtes Modulsystem und Mittel für systemnahe und nebenläufige Programmierung. Wo Pascal in seiner ursprünglichen Form eher als Sprache für einzelne, geschlossene Programme gedacht war, zielt Modula-2 auf den Aufbau größerer, aus Bausteinen zusammengesetzter Systeme.
Oberon wiederum ist die Antwort auf die Beobachtung, dass auch Modula-2 mit der Zeit reichhaltig und komplex geworden war. Es kehrt zur Radikalität der Anfänge zurück und reduziert die Sprache auf einen minimalen Kern. Damit spannt die Wirth-Familie einen lehrreichen Bogen: von Pascal über den Ausbau in Modula-2 bis zur bewussten Reduktion in Oberon – eine seltene Gelegenheit, die Entwurfsentscheidungen eines einzigen Sprachschöpfers über Jahrzehnte nachzuvollziehen.
Der aufschlussreichste Kontrast ist der zu C. Beide zielten auf systemnahe Programmierung, verkörpern aber gegensätzliche Philosophien. C gibt Entwicklern maximale Kontrolle und Nähe zur Hardware, nimmt dafür aber ein schwaches Typsystem und viele gefährliche Fehlerquellen in Kauf. Modula-2 und Oberon stellen umgekehrt Sicherheit und Klarheit in den Vordergrund und kapseln die riskanten, hardwarenahen Operationen in klar abgegrenzte Bereiche, die man bewusst betreten muss.
Technisch waren die Wirth-Sprachen in puncto Sicherheit oft die klarere Wahl. Durchgesetzt hat sich dennoch C – getragen von einem großen industriellen Ökosystem, breiter Verfügbarkeit und der Nähe zu einer dominierenden Betriebssystemwelt. Diese Konstellation ist ein Lehrstück darüber, dass sich am Markt nicht immer das technisch elegantere, sondern häufig das breiter unterstützte Werkzeug durchsetzt. Bemerkenswert ist, dass die Frage nach sicherer Systemprogrammierung – Wirths ursprüngliches Anliegen – heute mit modernen Sprachen erneut auf der Tagesordnung steht.
Ada teilt mit den Wirth-Sprachen das Ziel großer Sicherheit und strenger Typprüfung, verfolgt es aber mit einer bewusst umfangreichen, reichhaltig ausgestatteten Sprache, die für besonders sicherheitskritische Domänen wie Luftfahrt, Bahn und Verteidigung entworfen wurde. Wo Oberon auf radikale Reduktion setzt, setzt Ada auf umfassende, in die Sprache eingebaute Absicherung. Beide teilen die Überzeugung, dass frühe, strenge Prüfung besser ist als späte Fehler, ziehen daraus aber gegensätzliche Konsequenzen für die Sprachgröße.
Für ein mittelständisches Unternehmen sind die entscheidenden Kriterien bei der Sprachwahl meist die Verfügbarkeit von Fachkräften, ein tragfähiges Ökosystem an Bibliotheken und Werkzeugen sowie die langfristige Wartbarkeit. In allen diesen Punkten liegen Modula-2 und Oberon deutlich hinter den heute etablierten Sprachen. Es gibt kaum Entwickler am Markt, das Werkzeug-Ökosystem ist schmal, und die Community ist klein und spezialisiert. Eine Neuentwicklung in diesen Sprachen würde ein Unternehmen in eine riskante Abhängigkeit von wenigen Personen bringen.
Diese nüchterne Einschätzung ist kein Urteil über die technische Qualität der Sprachen – die ist unbestritten hoch –, sondern über ihre wirtschaftliche und personelle Tragfähigkeit im heutigen Umfeld. Verantwortungsvolle Technologieberatung muss diesen Unterschied klar benennen: Eine Sprache kann exzellent entworfen und trotzdem die falsche Wahl für ein konkretes Vorhaben sein, wenn das Umfeld nicht stimmt.
Es gibt eng umrissene Situationen, in denen der Kontakt mit diesen Sprachen real ist. Die häufigste ist die Pflege von Bestandssystemen: In einzelnen Organisationen laufen langlebige, gut funktionierende Anwendungen in Modula-2, deren Ablösung teuer und riskant wäre. Hier geht es nicht um Neubau, sondern um Werterhalt – um die sorgfältige Wartung, Dokumentation und schrittweise Modernisierung vorhandener Software. Solche Systeme verdienen eine bewusste Strategie, statt sie zu ignorieren, bis das Wissen darüber mit einzelnen Mitarbeitern verschwindet.
Das zweite relevante Feld ist die Aus- und Weiterbildung. Wer Nachwuchskräfte oder Quereinsteiger an sauberes Programmieren heranführen will, findet in der Klarheit dieser Sprachen ein wirksames Werkzeug. Und für erfahrene Teams kann die bewusste Auseinandersetzung mit einer radikal einfachen Sprache wie Oberon ein produktiver Denkanstoß sein: Sie schärft den Blick dafür, wie viel unnötige Komplexität sich in den eigenen, modernen Projekten angesammelt hat.
Der wertvollste Beitrag dieser Sprachen zum Mittelstand ist indirekt, aber greifbar. Die Prinzipien, für die sie stehen – klare Modulgrenzen, strenge Typprüfung, das konsequente Verbergen interner Details und vor allem die Disziplin, Komplexität zu vermeiden – sind unmittelbar auf jede heute genutzte Sprache und Architektur übertragbar. Ein Unternehmen, das diese Prinzipien in seinen tatsächlichen Projekten beherzigt, baut wartbarere, robustere und langlebigere Software, ganz gleich, in welcher Sprache.
Gerade im Mittelstand, wo Software oft über viele Jahre betrieben wird und Wissen an einzelnen Personen hängt, sind diese zeitlosen Prinzipien wertvoller als jedes Modethema. Die Wirth-Sprachen sind hier weniger ein Werkzeug als eine Denkschule – und diese Denkschule zu kennen, hilft bei jeder Technologieentscheidung, auch wenn am Ende eine ganz andere, moderne Sprache zum Einsatz kommt.
Als Sprachen sind Modula-2 und Oberon außerordentlich ausgereift und stabil. Sie wurden von einem der angesehensten Sprachschöpfer des Fachs mit großer Sorgfalt entworfen, über Jahre in der Praxis erprobt und gut dokumentiert. Ihre Spezifikationen sind klar und überschaubar – ein direkter Vorteil ihrer bewussten Einfachheit. Anders als bei manchen jungen Sprachen besteht hier kein Risiko, dass sich grundlegende Konzepte noch stark ändern; die Sprachen sind in einem abgeschlossenen, gefestigten Zustand.
Diese Reife bedeutet allerdings auch Stillstand im Sinne aktiver Weiterentwicklung. Es gibt keine große Organisation, die kontinuierlich neue Features, Sicherheitsaktualisierungen für ein breites Ökosystem oder Anpassungen an neue Plattformen vorantreibt, wie man es von Mainstream-Sprachen kennt. Für die Sprache selbst ist das unproblematisch, für den produktiven Einsatz aber ein wichtiger Punkt: Aktualität und Pflege der Werkzeuge liegen bei einer kleinen Gemeinschaft.
Der kritischste Faktor für jeden Einsatz ist die Verfügbarkeit. Compiler und Werkzeuge existieren, werden aber von einer kleinen, teils akademisch geprägten Gemeinschaft gepflegt. Ob ein bestimmtes Werkzeug auf einer aktuellen Plattform läuft und aktiv betreut wird, sollte im konkreten Fall geprüft werden, da sich dies über die Zeit ändert. Ein breites, kommerziell abgesichertes Ökosystem mit umfassendem Support, wie es Unternehmen von etablierten Sprachen erwarten, existiert nicht.
Ähnliches gilt für Fachkräfte: Entwickler mit fundierter Modula-2- oder Oberon-Erfahrung sind am Arbeitsmarkt selten. Für ein Unternehmen, das ein Bestandssystem in diesen Sprachen betreibt, ist das ein reales Risiko, das aktiv gemanagt werden sollte – etwa durch gute Dokumentation, das bewusste Sichern von Wissen und eine langfristige Perspektive für die Ablösung oder Kapselung solcher Systeme. Verlässt sich eine Organisation stillschweigend auf das Wissen einzelner Personen, entsteht eine gefährliche Abhängigkeit.
Realistisch betrachtet werden Modula-2 und Oberon Nischensprachen bleiben. Eine Rückkehr in die breite kommerzielle Entwicklung ist nicht zu erwarten. Ihre Zukunft liegt in der Lehre, in der Pflege von Bestandssystemen und im Fortleben ihrer Ideen in modernen Sprachen. Das ist kein Niedergang, sondern eine klare, stabile Rolle – man sollte sie nur nicht mit der Rolle einer aktiv wachsenden Mainstream-Sprache verwechseln.
Zu rechtlichen und lizenzbezogenen Aspekten gilt: Die verschiedenen Compiler und Implementierungen stehen unter jeweils eigenen Lizenzbedingungen, die von freizügig quelloffen bis kommerziell reichen können und im Einzelfall zu prüfen sind. Wer eine konkrete Implementierung – insbesondere für den kommerziellen Einsatz oder die Weitergabe von Software – nutzen möchte, sollte die jeweiligen Lizenzbedingungen sorgfältig prüfen. Diese Hinweise sind eine allgemeine fachliche Einordnung aus Projektsicht und keine Rechtsberatung; die verbindliche Bewertung gehört in die Hände fachkundiger rechtlicher Begleitung.
