# Oberon (Programmiersprache)

Oberon ist eine von Niklaus Wirth und Jürg Gutknecht entwickelte, objektorientierte, streng strukturierte Programmiersprache. Sie ist den ebenfalls von Wirth entworfenen Vorgängern Pascal und Modula-2 recht ähnlich, allerdings strukturierter und mächtiger als Pascal, gleichzeitig aber erheblich weniger umfangreich als Modula-2. Die Definition der Sprache war Anfang 1986 abgeschlossen. Das Oberon System ist ein eigenständiges Betriebssystem der ETH Zürich, das in der Sprache Oberon implementiert ist, als Entwicklungsgrundlage für die Sprache diente und ebenso wie der Compiler kostenlos erhältlich war.

## Überblick
### Einordnung

Oberon ist das Ergebnis eines Forschungsprojekts, eine Programmiersprache und ein Betriebssystem für Arbeitsplatzrechner zu entwickeln. Wirth und Reiser führten die Motivation für das Projekt auf die Zeit der Implementierung des persönlichen Rechners zurück. So hätten die damaligen üblichen Betriebssysteme beim Umsetzen der Prinzipien der Softwaretechnik versagt. Dazu seien eine voreilige Flucht in Standards gekommen sowie Programme, die Schichten auf veraltete Grundsysteme stapelten. Die Softwaretechnik habe einen wirtschaftlichen Mitteleinsatz und die Einfachheit der Lösungen vermissen lassen. Als Leitmotiv für das Projekt zitierten sie Einstein: „Mach es so einfach wie möglich, aber nicht einfacher.“ Das Projekt wurde nach dem größten Mond des Planeten Uranus benannt, dessen Monde zu dieser Zeit von einer Voyager-Raumsonde fotografiert wurden. Oberon sei auch der Name des Elfenkönigs.
Die Entwicklung von Oberon begann 1985 und mündete in einer vollständigen Definition der Sprache Anfang 1986 als Ergebnis einer Kooperation zwischen Niklaus Wirth und Jürg Gutknecht. Der dazu veröffentlichte Report umfasst lediglich circa 16 Seiten.
Ein Ziel der Programmiersprache Oberon war es, den erweiterbaren Entwurf zu unterstützen. Während ihr Vorgänger Modula-2 zwar strukturierte, modulare und hierarchische Programmierung erlaubt, um Abstraktionsebenen einzuführen, fügt Oberon die Erweiterbarkeit von Datentypen hinzu und zwar derart, dass erweiterte Typen kompatibel mit ihren Ausgangstypen bleiben. Modula-2 bietet dieses Merkmal nicht. Reiser und Wirth sahen darin die eigentliche Neuerung der „in den achtziger Jahren zur Modewelle avancierten objektorientierten Sprachen.“ Diese hätten darüber hinaus mit dem Ziel eines Paradigmenwechsels altbekannte Konzepte umbenannt. Aus Variablen wurden Instanzen, aus Prozeduren Methoden und aus dem Prozeduraufruf das Senden von Meldungen. Oberon hingegen blieb bei den Begriffen des Datentyps und der Prozedur, um einen „Bruch mit der Tradition“ zu vermeiden.
Die nachfolgende Tabelle zeigt einen Terminologienvergleich zwischen der objektorientierten Programmierung (OOP) und Oberon.
Terminologienvergleich :
| OOP-Terminologie | Oberon-Terminologie |
| Klasse | Zeigertyp, der einen Record-Typ mit Prozedurvariablen referenziert, welcher einen abstrakten Datentyp definiert |
| Objekt | Zeigervariable, die auf eine Record-Variable dieses Typs zeigt |
| Methode | Eine Prozedur des Record-Typs |
| Meldung senden | Aufruf einer dynamisch gebundenen Prozedur |
| Unterklasse (Subclass) | Erweiterter Record-Typ |
| Oberklasse (Superclass) | Basistyp einer Erweiterung |
| Vererbung (Inheritance) | Typerweiterung |
| Überschreiben einer Methode | Ändern der einem Record-Feld zugewiesenen Prozedur in einer Erweiterung |
| Empfänger (Receiver) | Das als Parameter übergebene Objekt bei einem Prozeduraufruf |
| Super-Aufruf | Aufruf einer Prozedur, die an den Basistyp einer Erweiterung gebunden ist |
| Dynamisches Binden | Aufruf einer Prozedurvariablen |
Oberon hat im Vergleich zu seinem Vorgänger Modula-2 einen verminderten Befehlsumfang. In der damit erreichten Vereinfachung und Vereinheitlichung sahen Reiser und Wirth „echten Fortschritt“ beim Vermitteln wissenschaftlicher Grundlagen, da die Ausdruckskraft Oberon erhalten bliebe.
Oberon wurde wie auch schon Modula-2 parallel zu einer Workstation, in diesem Fall Ceres, entwickelt. Oberon fand nach seiner Veröffentlichung unter anderem zu Bildungszwecken in Lehreinrichtungen Verwendung. Es existierten seinerzeit auf Oberon basierende, ebenfalls kostenlos verfügbare Werkzeuge, die auch kommerziell eingesetzt wurden, wie zum Beispiel die Programmiersprache Component Pascal und die integrierte Entwicklungsumgebung BlackBox Component Builder.
Wirth veröffentlichte Revisionen von Oberon in den Jahren 2007 und 2016. Im Rückblick wies er darauf hin, dass Oberon (im Jahr 2021) an „vielen Stellen“ im Einsatz gewesen sei, konstatierte jedoch, dass ein Durchbruch von Oberon im Gegensatz zu Pascal aufgrund „komplexer, kommerzieller Systeme mit weiter Verbreitung“ nicht stattgefunden habe.

### Besonderheiten

Hanspeter Mössenböck und Wirth haben Oberon mit wenigen Ergänzungen zur Programmiersprache Oberon-2 weiterentwickelt, die kompatibel zu Oberon ist. Wesentlich ist die Aufnahme von Prozeduren in den Befehlsumfang, die als Teil des Datentyps eines Objekts definiert werden können. Eine solche Prozedur erhält stets bei ihrem Aufruf eine Referenz auf das Objekt, über das ihr Aufruf erfolgt ist. Bei Oberon muss in diesem Fall eine Prozedur zunächst einer Prozedurvariablen des Objekts zur Laufzeit zugewiesen und, sofern benötigt, eine Referenz auf das Objekt als Parameter der Prozedur bei ihrem Aufruf übergeben werden. Ferner wurden unter anderem die For-Schleife und die Exportmarkierung - (als Alternative zu *) eingeführt, letzteres, um Variablen oder Objektkomponenten schreibgeschützt sichtbar zu machen.
Mössenböck bezeichnet die Frage, ob die Konzepte des Moduls und der Klasse in Oberon gleichzeitig vorhanden sein müssten, als berechtigt, da beide eine Datenstruktur verstecken und nur über Prozeduren zugänglich machen können. Er begründet das gleichzeitige Vorhandensein mit einer unterschiedlichen Sichtbarkeit. Das Modul regelt die Sichtbarkeit von außen, während innerhalb eines Moduls sämtliche Bestandteile der enthaltenen Klassen sichtbar sind.
Oberon sieht verglichen beispielsweise mit dem standardmäßigen Verhalten von C++ eine automatischen Speicherbereinigung (garbage collection) vor. Damit wird die Verwendung von Programmanweisungen zur Deallokation des von Objekten im Heap belegten Speichers obsolet. Wird erneut freier Speicher für ein Objekt im Heap benötigt, wird dort zunächst der Speicher von allen Objekten freigegeben, die aus keinem der geladenen Module mehr referenziert werden.
Oberon verlangt, dass Operanden in Ausdrücken und die Bestandteile von Wertzuweisungen kompatibel sind, und nennt diese Forderung strenge Typisierung. Ein Compiler kann so prüfen, ob Ausdrücke oder Zuweisungen sinnvoll sind, so dass Programmierfehler bereits vor der Programmausführung erkannt werden.
Der im Rahmen des Oberon-Projekts von Wirth und Gutknecht entwickelte Compiler – Wirth hielt die Entwicklung einer Programmiersprache ohne einen dazugehörigen Compiler für anmaßend und unprofessionell – für die NS-32000-Mikroprozessorarchitektur hatte zum Ziel, selbst kompakt zu sein und eine schnelle Übersetzung von Quelltext in effizienten und knappen Maschinencode aufzuweisen. Der erzeugte Maschinencode überprüft standardmäßig zur Laufzeit, ob der für einen Zugriff auf ein Array-Element verwendete Index in dem Bereich liegt, der bei der Deklaration des Arrays im Quelltext angegeben wurde. Ist dies nicht der Fall, liegt ein Fehler vor und die Programmausführung wird abgebrochen. Da die Indexprüfung einen zusätzlichen Laufzeitaufwand nach sich zieht, erlauben dieser und andere Compiler, sie per Option abzuschalten.
Der Compiler erzeugt ebenso eine Liste von Zuordnungen zwischen Prozeduren und Variablen im Quelltext und dem entsprechend erzeugten Maschinencode. Damit kann im Fehlerfall bei einem Programmabbruch der letzte Zustand der Programmausführung angezeigt werden hinsichtlich der Folge der aufgerufenen Prozeduren und deren Variablen. Das dazu verwendete Werkzeug ist üblicherweise ein symbolischer Debugger.
Die Quelltexte der Compiler waren in der Regel frei verfügbar. Es gab verschiedene integrierte Entwicklungsumgebungen wie zum Beispiel POW!.
Die Zeit, die ein Compiler benötigt, um seinen eigenen Quelltext in Maschinencode zu übersetzen, auch Selbstübersetzungszeit genannt, kann als Maß für die Qualität des Compilers angesehen werden. Die Selbstübersetzungszeit eines Oberon-2-Compilers betrug im Jahr 1991 mit einer DECstation 5000 (MIPS R3000, 25 Megahertz) lediglich 7 Sekunden. (Anmerkung: Auf modernen Computern ist die Taktrate über einhundert Mal schneller, und die Selbstübersetzungszeit beträgt damit deutlich weniger eine Zehntelsekunde. Zum Vergleich: Im Jahr 1985 dauerte die Selbstübersetzung für den Modula-2-Compiler von Niklaus Wirth auf einem Lilith-Computer (vergleichbare Rechenleistung wie eine VAX 750) knapp zwei Minuten.)

## Code-Beispiele

Hello World im Ulmer Oberon-System:
Die objektorientierte Programmierung wird mit erweiterten Datenverbünden vom Datentyp RECORD erreicht. Die Definition von Methoden wird durch typengebundene Prozeduren, und die Definition von Sichtbarkeiten durch Exportmarkierungen (* für Schreib- und Lesezugriff und - für Lesezugriff) erwirkt. Beispiel in Oberon-2:
Attribute, die nur einen Lesezugriff haben, können durch typengebundene Prozeduren (Methoden) verändert werden. Beispiel in Oberon-2:

## Weiterentwicklungen

Ausgehend von Oberon und Oberon-2 sind die Programmiersprachen Component Pascal, Active Oberon und Zonnon entstanden.