Diskussion:Oberon (Programmiersprache)

Erste Anmerkungen

Die Programmiersprache Oberon zeichnet sich dadurch aus, dass sie die objektorientierte Architektur im Gegensatz zum  Beispiel zu C++ unter anderem mit einem integrierten Laufzeitsystem Oberon System und einer Automatischen Speicherbereinigung (garbage collection) vollständig unterstützt.

es wäre mir neu dass eine objektarchitektur garbage collection benötigt. und C++ hat auch eine standard library. oder meint man mit "integriertem laufzeitsystem" die entwicklungsumgebung? wäre mir auch neu dass eine objektorientierte architektur das benötigt.

hier muss noch einiges verbessert werden, vieles nicht npov oder sogar einfach mal schlichtweg falsch, oder durch unglückliche formulierungen verzerrt.
(Der vorstehende Beitrag wurde am 17.12.2006, um 19:31 [MEZ], abgesendet.)

Die Speicherbereinigung ist in der objektorientierten Programmierung nicht zwangsläufig notwendig, ist jedoch sehr nützlicher (für manche sogar essentieller) Bestandteil und dient insofern zur vollständigen Unterstützung von echten objektorientierten Programmen. Das Thema ist eigentlich schon seit über zehn Jahren durch (das ist mehr als die halbe "Lebenszeit" von C++). Der Programmierer kann in der Regel doch gar nicht wissen, wie lange Objekte benötigt werden; das kann nur ein Laufzeitsystem übernehmen. Konsequenterweiser darf der Programmierer dann auch keinen Speicher freigeben, was in C++ leider doch möglich ist, meist auch benutzt wird und die Systeme damit instabil macht. Nur eine exklusiv im Laufzeitsystem integrierte automatische Speicherbereinigung kann diese Aufgabe sicher erfüllen. Siehe auch

• Kapitel 3.1 Laufzeitumgebung der Java-Plattform
• Garbage Collection in C++

Bautsch 09:10, 18. Dez. 2006 (CET)

Dass eine Garbage Collection ganz angenehm und bisweilen auch recht nützlich sein kann, besteitet ja niemand. Und dass man beim objektorientierten Programmieren eine GC mehr zu schätzen weiß als bei rein prozeduralem Vorgehen kann ich auch noch nachvollziehen. Aber trotzdem bleibt die Kritik des Originalposters am Artikel IMHO bereichtigt, da zu einer objektorientierten Programmier- und Laufzeitumgebung eine GC eben nicht zwangsläufig gehört und daher kein Maß für die "Vollständigkeit" einer solchen Umgebung darstellt. --RokerHRO 11:13, 16. Mär. 2008 (CET)

In einer Laufzeitumgebung mit dynamisch erzeugten Objekten (alles andere würde ich nicht als vollständig objektorientiert bezeichnen) kann der Programmierer nicht wissen, wann, wie oft und wie lange ein Objekt noch verwendet wird, da dies unabhängig vom Programmcode existiert. Bei Oberon (und dem Nachfolger Component Pascal) kann der Programmcode während der Dauer der Existenz von Objektinstanzen sogar ohne weiteres ausgetauscht werden, wenn die Definitionen und Schnittstellen kompatibel bleiben. Wie auch immer, in solchen Laufzeitumgebungen muss eine automatische Speicherbereinigung eingesetzt werden, oder der Speicher wird gar nicht bereinigt (zum Beispiel bei Echtzeitsystemen). Membeth 01:05, 26. Jul. 2009 (CEST)

Oberfläche

Hm, es fehlt ein Wort zur Oberon-Oberfläche und den vielen Mausklickmöglichkeiten ;) Gerade diese Oberfläche ist eine echte Stärke von Oberon, zumindest für jeden, der Windowmanager wie ION mag :) --vicbrother 17:29, 6. Jul. 2007 (CEST)

Was die einen (auch ich) als Stärke empfinden, finden andere als zu kompliziert. Die verschiedenen Kombinationen von drei Maustasten zum Edieren von beliebigen Dokumenten (egal ob Text oder Graphik) ist aber sehr effizient und ausgefeilt. Leider bevorzugen einige Computernutzer aber Ein-Tasten-Mäuse und wissen oft gar nicht, was ihnen entgeht. Membeth 01:05, 26. Jul. 2009 (CEST)

Fanseite?

Könnte man den Artikel mal etwas neutraler formulieren? Irgendwie macht es mich misstrauisch, wenn ausschließlich Vorteile genannt werden, noch dazu mit solchen Formulierungen:

• "[...] der großen Sicherheit und in der Einfachheit der Sprache" – allgemeine Phrase ohne Beweismöglichkeit
• "Die Entwicklungszeiten mit Oberon sind daher sehr kurz, und der Maschinencode ist dennoch sehr effizient und robust." – ebenfalls unbelegte (unbelegbare?) Aussage, die einem Werbeprospekt entsprungen zu sein scheint
• "Die Programmiersprache Oberon zeichnet sich dadurch aus, dass sie die objektorientierte Architektur [...] vollständig unterstützt." – Was genau ist mit "objektorientierte Architektur" gemeint? Wenn dieser Begriff nicht klarer gefasst wird, ist der ganze Satz ebenfalls eine beliebig dehnbare und damit inhaltsleere Werbeaussage.

Nachteile, wie die fehlende Mehrfachvererbung werden so dargestellt, als sei sei ausschließlich ein großer Vorteil. Dass Zeigervariablen automatisch dereferenziert werden, ist ebenfalls kein Alleinstellungsmerkmal. Das machen eigentlich alle modernen Programmiersprachen, die mit Zeigern nichts anderes machen können, außer sie zu dereferenzieren. Selbst in C werden Funktionszeiger (mit denen man keine Zeigerarithmetik betreiben kann) automatisch dereferenziert, da dies die einzig übrigbleibende Operation auf diesen Zeigertypen ist.

Außerdem bleiben bei mir nach dem Lesen des Artikels noch ein paar IMHO wesentliche Fragen offen:

• Ist bei Oberon das Anlegen einer dynamischen Variablen (via NEW) und das Initialisieren ihrer Elemente stets getrennt (wie in den angegebenen Beispielen) oder geht das auch in einem einzigen Ausdruck?
• Wie werden Zeiger intern repräsentiert, so dass das Laufzeitsystem jederzeit feststellen kann, ob sie auf ein gültiges Objekt zeigen? Existieren dafür interne Guard-Variablen? Unterstützt Oberon Nebenläufigkeit? Falls ja, ist der Zugriff auf diese Guard-Variablen gelockt? Falls ja, wie viel Performance kostet damit jeder Zugriff auf ein Objekt über so eine Zeigervariable?
• Für welche Plattformen ist der freie Oberon-Compiler verfügbar?

Soweit mein Senf. --RokerHRO 11:05, 16. Mär. 2008 (CET)

Wegen der objektorientierten Architektur siehe Antwort oben.

Beispiele für Sicherheit und Robustheit von Oberon:

• Kategorische Index- und Datentypchecks.
• Keine Verwechslung von Gleitkomma- und Ganzzahl-Division oder anderen überladenen Methoden oder Operatoren.
• Sehr wenig Hierarchieebenen für Operatoren und somit weniger Ungewissheit, welcher Operator Priorität hat.
• Oberon kommt ohne Laufzeit-Debugger aus, was für sich spricht.

Zur Effizienz und den anderen Punkten:

• Die Übersetzungszeiten und Laufzeiten des ausgeführten Codes sind mit denen von C-Programmen vergleichbar (auch bei echter Objektorientierung).
• Jeder dynamische Datentyp hat bei Oberon einen Typenwächter (es gibt auch statische Typen). Der Zugriff ist sehr effizient und schnell - die Wächter-Tabellen benötigen für jede Instanz natürlich etwas Speicher auf dem Heap, das ist aber heutzutage wirklich kein Thema mehr.
• Mir ist kein Programmierproblem bekannt, dass die mehrfache Implementationsvererbung erforderlich macht. Im Gegenteil ergeben sich aus dem Diamond-Problem Ungewissheiten für Programmierer und Compiler, vom ineffizienten Ballast bei der Implementierung und Compilierung der mehrfachen Implementationsvererbung einmal ganz abgesehen.
• Die Erzeugung einer Instanz mit NEW() ist immer getrennt von der Initialisierung (Oberon verwendet auch keine Konstruktoren, sondern normale Prozeduren, wie zum Beispiel Init(); oder InitialisiereObjekt();). Mit NEW() allozierte Speicherbereiche werden allerdings immer mit Nullen aufgefüllt.
• Ich habe Oberon-Implementation für Windows, MacOS und Linux gesehen.

Membeth 01:05, 26. Jul. 2009 (CEST)

Membeth schreibt: „Oberon kommt ohne Laufzeit-Debugger aus, was für sich spricht.“ – Ja, das spricht aus meiner Sicht

ganz klar dafür, dass es sich nicht um ein professionelles Entwicklungssystem handelt. Vielleicht weiß ich nur nicht, was

ein solcher Laufzeitdebugger sein soll, dieses Wort habe ich nämlich heute auch zum ersten Mal gelesen.

Highbrow (Diskussion) 10:22, 20. Jun. 2016 (CEST)

Das System ist hochprofessionell und verfügt selbstverständlich über einen umfassenden Post-Mortem-Debugger und das entsprechende Programmierkommando HALT zum Setzen von Haltepunkten. Ein Run-Time-Debugger (= Laufzeit-Debugger) ist in echten objektorientierten oder parallelisierbaren Laufzeitsystemen weder sinnvoll noch erforderlich, und folglich ist die Verwendung solcher Laufzeit-Debugger als Programmierwerkzeug nicht professionell, aber diesen Unterschied verstehen möglicherweise nur Programmierer, die tatsächlich und sehr effizient ohne Laufzeit-Debugger arbeiten (können). Siehe auch letzter Absatz vom Abschnitt Debugger#Funktionen_eines_Debuggers. --Membeth (Diskussion) 12:49, 20. Jun. 2016 (CEST)

Neutralität

Hi, bin eben durch Zufall über den Artikel gestoßen und war überrascht wie eindeutig einseitig er geschrieben ist. Fände es als normaler Wikipedia-Nutzer besser, auch Nachteile zu nennen, oder zumindest, falls die Sprache die perfekte Lösung für alles ist, zu erklären, warum sie sich nicht wie ein Lauffeuer verbreitet. Außerdem finde ich es schwierig von einem Betriebssystem zu sprechen, ohne dies weiter zu beschreiben, da die meisten Nutzer darunter etwas wie Linux, Windows oder OS X verstehen, also weit mehr als eine Basis-Software, die das Ausführen von Programmen erlaubt.

Als Nachteile fallen mir nur die geringe Verbreitung und die zwar sehr effiziente, aber für Standard-Benutzer nicht eben simple Bedienung ein. Membeth 01:05, 26. Jul. 2009 (CEST)

Erwähnenswert fände ich hier jedenfalls, dass es die eine Sprache Oberon gar nicht zu geben scheint, vielmehr existieren mehrere zueinander inkompatible Varianten (Oberon, Oberon-2, Oberon-07, Active Oberon, siehe hierzu den englischsprachigen Artikel). Was bedeutet "effiziente Bedienung" im Zusammenhang mit einer Programmierspreache? Das bezieht sich offenbar auf das in Oberon geschriebene "System Oberon", das aber nicht identisch ist mit der Sprache selbst. "Geringe Verbreitung" ist ein Euphemismus angesichts der Tatsache, dass inzwischen offenbar praktisch niemand mehr diese Sprache zu benutzen scheint. --FritzVonHomburg (Diskussion) 22:29, 18. Sep. 2022 (CEST)

Garbage Collection und Objektorientierung?

Ich bin über diesen Satz gestolpert, wie auch andere hier: "Die Programmiersprache Oberon zeichnet sich dadurch aus, dass sie die objektorientierte Architektur im Gegensatz zum Beispiel zu C++ unter anderem mit einem integrierten Laufzeitsystem Oberon System und einer Automatischen Speicherbereinigung (garbage collection) vollständig unterstützt". Es geht mir aber nicht darum, ob das Laufzeitsystem und die Garbage Collection nun die objektorientierte Architektur unterstützt oder nicht, sondern ob es die Garbage Collection und Objektorientierung überhaupt gibt in Oberon. Vielleicht habe ich es ja nur übersehen, aber die Sprache scheint vollständig hier definiert zu sein:

http://www-old.oberon.ethz.ch/oreport.html (ich habe hier einen Verweis auf das Archiv verwendet, da wenn man auf der Hauptseite http://www.oberon.ethz.ch/language/index auf "Language" klickt, bekommt man nur einen Hinweis, daß die Seite in Bearbeitung ist und man das Archiv ansehen möge. Laut HTTP-Seiteninformation ist diese Webseite jetzt schon über ein Jahr alt...)

Dort finde ich weder eine Erwähnung von Garbage Collection, noch von typischen Merkmalen objektorientierter Sprachen, wie Klassen mit Methoden. Wenn ich das richtig sehe, können nur Strukturen definiert werden, die zwar vererbt werden können, aber keine Methoden beinhalten und z.B. polymorphe Methoden bieten. Welche konkrete Oberon Implementierung ist hier gemeint?

Die automatische Speicherbereinigung ist selbstverständlich nicht Bestandteil der Programmiersprache, sondern des Laufzeitsystems. In der Programmiersprache kann die Speicherbereinigung mit einem Prozeduraufruf (Kernel.GC();) erzwungen werden. Ansonsten macht das Laufzeitsystem dies in regelmäßigen Abständen automatisch (außer natürlich bei Echzeitsystemen mit zeitkritischen Anwendungen). Allerdings ist auf modernen Rechnern für den Benutzer praktisch keine Verzögerung zu merken, wenn auf dem Heap eine Million Objekte überprüft und / oder freigegeben werden. Membeth 01:05, 26. Jul. 2009 (CEST)

Klassen werden in Oberon durch Verbunde (RECORD) repräsentiert (genial). Für diese Strukturen können auf einfache Weise typgebundene Prozeduren (Methoden) definiert werden. All dies erlaubt konkrete, generische und abstrakte Strukturen mit Vererbung und somit also auch Polymorphie. Membeth 01:19, 26. Jul. 2009 (CEST)

Oberon kennt keine Typ gebundene Prozeduren sondern nur Vererbung, die Typ gebundenen Prozeduren sind nämlich erst mit Oberon-2 in die Sprache aufgenommen worden! Genauso wurde die FOR Schleife wieder in die Sprache aufgenommen, nachdem sie beim Schritt von Modula-II zu Oberon entfallen ist. An die Autoren der Wiki Seite kann man nur die Aufforderung richten sich sowohl den Oberon Report (dieser stammt noch von N.Wirth) als auch den Oberon-2 Report (dieser ist im Wesentlichen von Hanspeter Mössenböck) durchzulesen und diese Seite hier komplett zu überarbeiten. Im aktuellen Zustand ist sie im Wesentlichen falsch und trifft Aussagen über Oberon-2 und nicht über Oberon. Oberon-2 ist eine OOP Sprache, Oberon ist nur Objekt basiert. -- 87.155.85.1 19:42, 4. Aug. 2009 (CEST)

Die Definition von Methoden mit Oberon-2 in der Definition der typgebundenen Prozeduren ist eleganter und sicherer (es können nicht so leicht Fehler bei der Implementierung gemacht werden). Nichtsdestoweniger werden auch bei Oberon mit der Hilfe von Prozedurtypen Prozeduren an Datentypen (RECORDs) gebunden und sind somit aus meiner Sicht Methoden, da sie genauso wie bei Oberon-2 das Verhalten von Objekten beschreiben. Der kleine Nachteil (und die Gefahr) besteht darin, dass bei auf diese Weise gebundenen Prozeduren immer explizit das Objekt selber als Parameter übergeben werden muss, damit es in der Methode verwendet werden kann. Membeth 15:34, 6. Aug. 2009 (CEST)

Oberon hat kein eingebautes Dispatching, und das ist essentiell für das OOP Paradigma. Es wird somit auch kein Polymorphismus unterstützt. Es wird sogar in Text "From Modula To Oberon" von N. Wirth explizit ein Beispiel angegeben, in dem Dispatching mit Sprachmitteln von Oberon nachgebaut wird, und zwar folgender Codeblock:

   p := M.element(K);
   IF p # NIL THEN
   IF p IS Rectangle THEN ... p(Rectangle).w ...
   ELSIF (p IS Circle) & ~p(Circle).shaded THEN ... p(Circle).rad ...
   ELSIF ...

Das bewegt sich ganz eindeutig auf dem Niveau von Modula-II Varianten Records oder den C-Libraries (z.B. Xt) mit OOP Konzept, und ist natürlich ein eindeutiges Zeichen dafür, daß die Programmiersprache OOP nicht unterstützt. Typtest dürfen in einem sauberen OOP Programm gar nicht auftreten. Es gibt wenige Ausnahmen, wie etwa das Double Dispatch Pattern, das sich in den meisten OOP Sprachen nur über Typchecks umsetzen läßt, da diese kein Double Dispatch direkt unterstützen. Aber auch da ist die Aussage gilt Sprache X unterstützt kein Double Dispatch. Essentiell ist jedenfalls, daß Oberon keine Polymorphie unterstützt, weil es kein Dispatching kennt, und somit auch keine Methoden kennt. -- 87.155.84.199 21:58, 6. Aug. 2009 (CEST)

Es ist im wesentlichen eine Frage der Definition des Methoden-Begriffes. Mir ist nicht bekannt, dass nur die verbreitete Art und Weise, wie Methoden zum Beispiel in Java verwendet werden, die einzig zulässige für Objektorientierung ist. Es gibt Herangehensweisen, die umständlicher sind (Oberon), es gibt aber auch welche, die einfacher und klarer sind:

Die Existenz und Benutzung einer IS-Anweisung ist jedenfalls kein Indiz für fehlende Objektorientierung, auch wenn sie in vielen objektorientierten Programmiersprachen nicht existiert oder die Verwendung zumindest selten oder unüblich ist. Hier ein Beispiel aus der Model-Viewer-Controller-Programmierung in Component Pascal (respektive Oberon-2), das die WITH-Anweisung benutzt. Diese WITH-Anweisung ist nichts anderes als eine multiple IS-Anweisung. Die Aufnahme dieser Anweisung in den Sprachschatz der sonst so minimalistischen Programmersprache möge ein Indiz für die Nützlichkeit sein. Die Variable c ist vom generischen Typ Controller, und die Methode HandlePropMsg verarbeitet Meldungen von Typ Properties.Message, deren Eigenschaften vom Typ Properties.Property in Listen auftauchen:

  PROCEDURE (c: Control) HandlePropMsg- (VAR msg: Properties.Message);
  
     VAR p: Properties.Property;
  
     BEGIN
  
        WITH
           msg: Properties.ControlPref DO
              ...
           | msg: Properties.PollMsg DO
              ...
           | msg: Properties.SetMsg DO
              p := msg.prop;
              WHILE p # NIL DO
                 WITH
                 p: Prop DO
                    ...
                 | p: Properties.StdProp DO
                   ...
                 ELSE
                 END;
                 p := p.next;
              END;
           | msg: Properties.TypePref DO
              ...
        ELSE
        END;
  
     END HandlePropMsg;

Aus meiner Sicht ein schönes Beispiel für elegante, generische, polymorphe und objektorientierte Programmierung, das klar strukturiert und leicht nachzuvollziehen ist (man denke nur an die unübersichtliche Ereignis-Bearbeitung mit EventListenern und Adaptern in Java). Bautsch 13:22, 24. Aug. 2009 (CEST)

Gibt es Oberon noch?

Gibt es Oberon überhaupt noch? Die Webseiten der ETH wurden seit 2008 oder 2009 nicht mehr aktualisiert, viele Links sind tot. Downloads nicht mehr möglich. Möglicherweise ein schönes Beispiel dafür, wie in Europa mit modernen Technologien umgegangen wird. MichaelL2008 (Diskussion) 16:38, 23. Dez. 2014 (CET)

Siehe zum Beispiel:

• The Programming Language Oberon, Revision 1.10.2013 / 10.3.2014, Niklaus Wirth

Im Übrigen empfehle ich die Beschäftigung mit der Weiterentwicklung mit der Bezeichnung Component Pascal.

Ansonsten stimme ich aber voll zu: In Europa werden geniale Erfindungen selten hinreichend anerkannt, geschweige denn gewertschätzt oder gefördert. --Bautsch (Diskussion) 18:51, 23. Dez. 2014 (CET)