Document ID: /fineweb-2-swissfilter-quality_10-filterrobots/filtered/03438.jsonl.gz/845

|ROLF:||Wir beginnen mit einer Philosophie der Objekte. Ich schlage vor, dass wir im Gesprächsmodus unsere bisherigen Ideen zusammentragen.

Mit "Objekt" verbinde ich vor allem Gegenstand, objektiv und neuerdings objektorientierte Programmierung. Vielleicht ist es sinnvoll, wenn wir uns fragen, warum die objektorientierte Programmierung "objektorientiert" heisst. Ich gehe davon aus, dass dieser Name ganz unbewusst und naiv entstanden ist, dass wir aber jetzt - im Nachhinein - diese Programmierung dazu benützen können, zu verstehen, was wir mit Objekt genau meinen. Vielleicht siehst Du einen anderen Anfang?
|RÖBI:||Jein. Wir führen den Dialog mit Hilfe von Objekten. Der html-Editor, mit dem ich diesen Text schreibe, ist ein Werkzeug, ein Gegenstand oder eben ein Objekt. Die html-Datei, die mir als Träger dient ist ebenfalls ein Gegenstand oder in der Sicht der objektorientierten Programmierung ein Objekt. Dein Anfang ist als Textteil aus dieser Perspektive ebenfalls ein Objekt und so ist es dieser Textteil und selbst die einzelne Zeichenkette wird in der objektorientierten Sichtweise als Objekt aufgefasst. Ich schlage vor, den Dialog selbst zum Gegenstand der Reflexion über Objekte zu machen und die Objekte zu definieren, die bei unserer Art des Dialogschreibens implizit gehandhabt werden.

|ROLF:||Die Idee unseren Dialog als Gegenstand der Objektanalyse zu verwenden, finde ich gut, auch wenn mir vor dem Umfang graut.

So wie Du jetzt angefangen hast, lese ich Objekt als Synonym zu Gegenstand oder zu Ding. Ich glaube, dass wir den Ausdruck auch im Alltag gezielter verwenden. Mir scheint, ich spreche nur von Objekten, wenn ein bestimmter Kontext explizit gegeben ist, etwa würde ich von den Objekten einer Liegenschaftsverwaltung sprechen, nicht aber von den Gegenständen einer Liegenschaftsverwaltung. Daraus will ich etwas lernen.
Für unseren Dialog denke ich aber vor allem an die objektorientierte Programmierung als gegebener Kontext.
|RÖBI:||Genau. Ich will diesen Kontext verwenden und die objektorientierte Terminologie auf das beziehen, was wir tun, wenn wir diesen Dialog im gegenständlichen Sinne herstellen. Mir schwebt vor, für die Herstellung des Textes, so wie er im Browser jetzt vor uns liegt, Werkzeuge einzusetzen, die nach den Gesetzen der objektorientierten Programmierung hergestellt werden. Damit wir uns nicht in der Vielfalt der Handlungen verlieren, die wir ausführen um den Text herzustellen, schlage ich für die Objektanalyse folgendes Szenario vor: An einer bestimmten Stelle des im Browser angezeigten Dialoges erscheint eine Schaltfläche für das Umschalten in den Autorenmodus. Das Betätigen der Schaltfläche verzweigt zum Ende des Dialoges und ermöglicht das Eingeben von Text. Mit dem Wechsel in den Autorenmodus erscheint anstelle der Schaltfläche Autorenmodus die Schaltfläche Lesemodus. Das Betätigen der Schaltfläche wechselt in den Lesemodus.

Wir könnten uns an diesem Beispiel mit der objektorientierten Terminologie - wie sie etwa im Buch "NeXTSTEP, Object-Oriented Programming and the Objective C Language, 1993" präsentiert wird -, vertraut machen und sehen, wie sie unser Hyperlexikon beeinflusst. Zu object ist beispielsweise vermerkt: "A programming unit that groups together a data structure (instance variables) and the operations (methods) that can use or affect that data" (233) und an anderer Stelle: "Likely, if you've ever tackled any kind of difficult programming problem, your design has included groups of functions that work on a particular kind of data - implicit "objects" without the language support. Object-oriented programming makes these function groups explicit and permits you to think in terms of the group, rather than its components. The only way to an objects data, the only interface, is through its methods" (5).
Wenn ich Dein obiges Beispiel von den Objekten einer Liegenschaftsverwaltung in dieser Hinsicht lese, dann frage ich nach den Methoden des Objektes, um die Daten im Sinne der (Liegenschafts)Verwaltung zu manipulieren.
|ROLF:||Ich bin zunächst einer fassbaren Definition interessiert. Danach will ich schauen, wo sich diese Definition wie bewährt. Damit schlage ich natürlich - in den Augen der Programmierer - einen unpraktischen Weg vor, weil diese Objekt direkt in ihren vermeintlichen Kontext sehen wollen, also an Liegenschaftsverwaltungen und oder Sprachen nicht interessiert sind.

Ich beginne aber gerne mit dem Vorschlag von Nextstep, denn ich zuerst in mein Verständnis übersetzen will:
"A programming unit" heisst "Ein Programm"
"that groups together" heisst .... ? Das verstehe ich eigentlich nicht. Als englisch-deutsch-Uebersetzung würde ich lesen: "das gruppiert" oder "eine Gruppe erzeugt". Aber ich kann mir nicht recht vorstellen, wie ein Programm ein Gruppe macht, resp. was das heissen soll.
".. a data structure (instance variables) and the operations (methods)" heisst "eine Datenstruktur und Operationen". Das sind zwei Begriffe, die wir wohl erläutern müssten. Ohne weiter nachzudenken sage ich: eine Datenstruktur ist ein Objekt.
"operations, that can use or affect that data" heisst "Operationen, die Daten verwenden oder betreffen". Ich unterstelle, dass Daten hier irgendwie auf die davor genannte Datenstruktur verweist, verstehe allerdings nicht recht wie.
Vielleicht würde ein Beispiel helfen?
|RÖBI:||Ich versuche es zunächst mit einem Bild.

Ein Objekt ist ein in sich geschlossener Teil eines Programms oder anders gesagt, ein Programm setzt sich aus Objekten zusammen. Es ist es wichtig, dass das, was in der OOP als Objekt bezeichnet wird, in der Programmiersprache referenziert werden kann. Wenn also in einem Programm von einem Objekt die Rede ist, dann ist damit gemeint, dass diese Einheit aus Methoden (oder Operationen) und Daten (oder Datenstrukturen) besteht. Zwar kann ich, so wie Du, sagen, dass eine Datenstruktur ein Objekt ist, aber hier ist gemeint, dass zur Datenstruktur Methoden gehören, mehr noch, dass die Datenstruktur durch die Methoden eingekapselt ist und nur via diese Methoden behandelt werden kann. Bestimmt die Datenstruktur den Zustand der Einheit so bestimmen die Methoden ihr Verhalten.
Das Beispiel, das NeXTSTEP verwendet, ist die Wasserversorgung eines Eigenheims. Stell Dir ein Objekt vor bestehend aus Methoden zum Starten und Stoppen des Wasserzuflusses, Setzen der Durchflussrate, Melden der in einer bestimmten Periode verwendeten Wassermenge und so weiter. Um diese Aufgaben auszuführen müsste das Objekt eine Datenstruktur haben um den Durchfluss aufzuzeichnen, die Durchflussrate zu ändern, die verbrauchte Wassermenge aufzuzeichnen und es müsste mit den entsprechenden Methoden bestückt sein. Vielleicht hilft es Dir, wenn Du das Beispiel und die Erläuterungen dazu im Original liest.
|ROLF:||Ich will insistieren: Was ist ein "geschlossener Teil eines Programms"? Und was heisst "in der Programmsprache referenzieren"?

Dazu würde ich erneut Beispiele brauchen. Ich versuche also Dein Nextstep- Beispiel zu interpretieren:
Die Wasserversorgung eines Eigenheims, oder sagen wir - für einfache Gemüter wie mich - etwas praktischer und nachvollziehbar einfacher ein WC mit Wasser-Spülung. Der Spülkasten hat eine Spültaste und eine Uhr, die den Wasserverbrauch anzeigt. Ich kann die Taste drücken und danach ablesen, wieviel Wasser ich verbraucht habe.
Nun will ich mein WC mit dem Computer steuern und natürlich die Messwerte der Wasseruhr auch am Computer sehen. Also muss ich zunächst mein WC aufrüsten. Ich muss fernbedienbare Schalter einbauen und die Messuhr, die bisher die Umdrehungen eines Wasserrädchens direkt mechanisch - wie etwa der Kilometerzähler am Fahrrad - anzeigte, muss ein Signal erzeugen, dass ich im Computer auswerten kann.
Jetzt muss ich ein Computerprogramm schreiben. Ich kann - wie Du vorschlägst - sagen, dass das Programm bestimmte Aufgaben löst, aber im Moment des Programmierens muss ich bestimmte Aufgaben lösen: ich müsste ein Objekt sehen, eine Struktur und Methoden. Ich sehe also das Objekt WC-Spülung - das ist eine funktionale Bestimmung eines Systems, die im weiteren belanglos ist. Dann sehe ich die Struktur der WC-Spülung, das sind Wasserbehälter, Röhren, Schalter und Uhren. Dann sehe ich Methoden. Ich nehme hier nur eine einzelne Methode. Diese Methode ermöglicht es mir, den Wasserverbrauch zu begrenzen. Wenn 100 Liter Wasser verbraucht sind, stellt die Wasserzufuhr ab, und das WC kann nicht mehr gespühlt werden. Das ist nicht so unsinnig, wie es scheint, sondern eine kommerziell motivierte Methode, weil ich später mit anderen Methoden Geld verlange, damit wieder Wasser kommt. Hier genügt aber ein abgegrenzter Teil der Methode "Geld kassieren", der selbst eine Methode ist, nämlich "Wasserzufuhr begrenzen".
Bevor ich weiter interpretiere, werde ich Gewahr, dass ich am interpretieren bin. Ich frage deshalb, ob Du Deinen Text auch so lesen und paraphrasieren kannst und willst, oder ob Du die Sache anders siehst.
|RÖBI:||Dein Insistieren und Deine Paraphrasen sind ganz in meinem Sinne. Bevor Du weiter interpretierst will ich mit Hilfe Deines Beispiels nochmals verdeutlichen, was ich mit "geschlossener Teil eines Programms" gemeint habe. Der OOProgrammierer ist bestrebt, Objekte zu definieren, die er wiederverwenden kann. Im Kontext Deines Beispiels könnte dies die Wasserzufuhr sein, die aus weiteren Objekten besteht, so etwa wie Du sie aufgezählt hast: Wasserbehälter, Ventile, Röhren und Uhren. Wenn er die Wasserzufuhr als eigenständiges Objekt definiert hat, kann er sie neben der WC-Spülung bei weiteren Objekten, die ebenfalls eine gesteuerte Wasserzufuhr umfassen, wie etwa die Kaffee- oder die Geschirrspülmaschine, wiederverwenden, ohne sich um die im Objekt Wasserzufuhr definierten Details zu kümmern. Deine Methode "Wasserzufuhr begrenzen" wird dann je nach Objekt verschiedene Werte annehmen: 100 Liter (WC-Spülung); 10 Liter (Kaffeemaschine); etc. Mit "in der Programmiersprache referenzieren" habe ich gemeint, dass mit einem Ausdruck auf ein Objekt verwiesen werden kann etwa in der Weise objekt.methode (wert). Auf unser Beispiel bezogen würde innerhalb des Objektes WC-Spülung der Ausdruck lauten: Wasserzufuhr.begrenzen (100) und innerhalb des Objektes Kaffeemaschine Wasserzufuhr.begrenzen (10).

|ROLF:||Ich bin etwas irritiert. Zuerst wegen Deinen Erläuterungen. Geht es dabei um etwas anderes, als
um Proceduren oder Funktionen, die man immer wieder aufrufen kann? Und dann: Was heisst, dass mit einem Ausdruck auf ein Objekt verwiesen wird. Ich nehme an "objekt.methode (wert)" ist der Ausdruck, der auf etwas verweisen soll. Worauf? Worin besteht das Objekt?

Generell scheint mir, ich wollte über die wirkliche Welt der Gegenstände etwas sagen und Du antwortest auf der Ebene der Programmiersprache. Meinst Du, dass man von Objekten nur in der Programmiersprache sinnvoll sprechen kann. Wäre es nicht überhaupt sinnvoll, von Objekten zu sprechen?
|RÖBI:||In der Meinung, wir wären immer noch bei Deiner Eingangs gestellten Frage, warum die objektorientierte Programmierung "objektorientiert" heisst, habe ich mit meinen Erläuterungen offenbar offene Türen eingerannt. Ganz sicher bin ich mir nicht. Daher die Frage: siehst Du keinen Unterschied zwischen dem Aufgerufenen? Sind Dir Prozeduren, Funktionen und Objekte gleich gültig? Was den Mechanismus des Aufrufens betrifft, geht es bei den Objekten, wie Du sagst, tatsächlich um nichts anderes, ist es aber für den Programmierer nicht ein Unterschied, ob er im Programm Objekte definieren und aufrufen kann oder ob er lediglich Prozeduren und Funktionen zur Verfügung hat?

Ich zähle ein Programm ebenfalls zur wirklichen Welt der Gegenstände. Wenn ich für die Steuerung meines WC's den Computer einsetzen will, dann stelle ich die Steuerung als Gegenstand her. Ich meine allerdings nicht, dass man nur in der Programmiersprache sinnvoll über Objekte sprechen kann, aber seit wir bei der Herstellung der Steuerung von Objekten den Ausdruck Objekt programmatisch verwenden, kann ich nicht mehr gleich wie bis anhin über Objekte sprechen. Ich sehe also keine Objekte überhaupt sondern solche, worin die Verwendung des Ausdruckes in der OOP aufgehoben ist.
Vor diesem Hintergrund will ich nun aber gerne mit Dir über die wirkliche Welt der Gegenstände sprechen und die Ebene der Programmiersprache verlassen.
|ROLF:||Jetzt sehe ich' wieder umgekehrt. Lass uns konkret werden: Ich habe (am WC, und später vielleicht auch an der Kaffeemaschine) einen Wasserbehälter, der hat ein Einlassventil und einen Durchlaufmengenmessgerät. Ich will, dass nach einer bestimmten Menge Wasser das Einlassventil schliesst (bis es mit einem weiteren Befehl wieder geöffnet wird, was wir hier ausser Acht lassen wollen).
Der Durchlaufmesser sei eine Art Wasserrad mit einem Fahrradkilometerzähler. Wenn die Zahl 100 angezeigt wird, wird ein Kontakt in der elektrischen Ventilsteuerung geschlossen, worauf das Ventil schliesst. Alles ganz simpel und mechanisch. Siehst Du da bereits "programmatisch" Objekte?
Oder wann kommen die Objekte ins Spiel?

|RÖBI:||Ein harziger Dialog - scheint mir. Deiner Beschreibung der Wasserzufuhr stimme ich auch diesmal vorbehaltlos zu. Deine Frage hingegen impliziert, dass wir wissen, was Objekte sind. Nachdem der Versuch - vorerst - fehlgeschlagen ist, aus der mir bis dahin unbekannten OOP in dieser Hinsicht etwas Definitives zu erfahren, möchte ich zurückkommen auf Dein oben bekundetes Interesse an einer fassbaren Definition. Wie kommen wir dazu?

|ROLF:||Harz hält und hält zurück. Ich verstehe den bisherigen Dialog als beliebiges Gespräch, in welchem sich Indizien über user Voswissen ansammeln. Argumentationen liefern den Rohstoff für Begriffe. Aber vielleicht dient dieses konkrete Gespräch im Moment noch nicht.

Ich habe in unserem Lexikon unter Objekt schon früher einen Versuch angefangen. Dabei schien mir das Wesentliche im Unterschied zwischen Objekt und Instanz zu liegen. Dieser Versuch ist aber eher sprachphilosophisch als an einer Programmiererfahrung orientiert. Ich glaube, dass sich darin zwei Welten zeigen und dass man eine aufwendige Brücke bauen muss, um sie zu verbinden. Falls Du mit "harzig" diese Kompliziertheit meinst, kann ich Dir nur zustimmen. Die praktische Vernunft der Ingenieure - ich denke beispielsweise an Thomas, erkenne sie aber ohne weiteres auch bei Marco - hat schon lange entschieden, dass die Technik nicht verstanden werden kann. Wenn wir es trotzdem versuchen, wäre es erstaunlich, wenn wir auf Anhieb gut fortkommen. Wir brauchen Musse.
Die Brücke müsste dergestalt sein, dass wir nicht nur feine Definitionen im Lexikon haben, sondern dass wir aufgrund dieses Wissens effizient programmieren können - oder eine effiziente Programmierumgebung spezifizieren können. Ich jedenfalls leide nach wie vor daran, dass ich weder mit Aion noch mit Nextstep arbeiten kann.
Bist Du bei Nextstep der Unterscheidung Objekt versus Instanz begegnet?
Und noch ein PS: Worin unterscheiden sich die Beispiele Mehrfamilienhaus und WC-Spülung eigentlich?
|RÖBI||Mit "harzig" habe ich zunächst gemeint, dass wir uns zurückhalten, indem wir uns gegenseitig irritieren. Irritationen können den Dialog aber auch in eine Richtung treiben, die letztlich dient. Nachdem Du irritierst warst, weil ich auf der Ebene der Programmiersprache argumentierte und Du über die wirkliche Welt der Gegenstände sprechen wolltest, zielt die Frage der Unterscheidung Objekt versus Instanz wieder auf erstere. Eine fassbare Definition ist "in der wirklichen Welt der Gegenstände" verankert, aber welche Gegenstände es sind, die einer Verankerung dienen, ist mir nicht klar. Das ist eine Frage, die mich seit langem immer wieder beschäftigt: wohin muss ich die Aufmerksamkeit richten, damit ich die Basis für eine Metapher finde? Oder anders gefragt, gibt es eine Methode des Definierens? Zurück zum Objekt: Der Ausdruck - ich zitiere LexiRom - wurde bisher neben dem grammatikalischen - (Satzglied, das von einem Verb als Ergänzung gefordert wird) und dem kaufmännischen Gebrauch (Grundstück, Gebäude: als Gegenstand eines Kaufvertrages) in erster Linie philosophisch verwendet: "allgemein, bes. in der Philosophie: Gegenstand des Erkennens, Denkens, Handelns; meist im Unterschied zum Subjekt".

Deinem ersten, eher sprachphilosophisch ausgerichteten Versuch verdanken wir das Beispiel Mehrfamilienhaus. Ich vermute, das Beispiel drängte sich in sprachlicher Hinsicht im Sinne des Gegenstandes als Kaufvertrag auf. Das Beispiel WC-Spülung stammt indirekt aus der OOP - wobei die Ingenieure gerade nicht an eigentlichen Definitionen interessiert sind, und in ihren Beschreibungen der gegenständliche Bezug erst aufgedeckt werden muss. Das ist die zweite Seite des Zurückgehaltenwerdens. Den Unterschied zwischen den beiden Beispielen sehe ich spontan darin, dass im ersten Fall strukturelle Parameter, im zweiten Fall neben den strukturellen auch Prozessparameter interessieren. Im Beispiel Mehrfamilienhaus würde ich Objekte (nicht im kaufmännischen Sinn) erst dort ins Spiel bringen, wo ich sie verwalten müsste. Dann würde aber nicht die Gebäudestruktur im Vordergrund stehen, sondern die (Verwaltungs)Prozessstruktur. Trotzdem scheint mir Deine Unterscheidung Objekt - Instanz in diesem Beispiel gut dokumentiert.
Die Unterscheidung Objekt - Instanz ist in der OOP allgegenwärtig doch habe ich bisher noch nicht wirklich begriffen, was der gegenständliche Bezug ist. Es kommt mir vor, wie wenn ich - um in Deinem Bild der Brücke zu bleiben - auf beiden Seiten, der sprachlichen und der gegenstandspraktischen Grund suchen würde, um Pflöcke für den Brückenschalg einzugeschlagen.
|ROLF:||Ich sehe nun zwei Fragestellungen, die miteinander zwar eng verknüpft sind, die ich aber trotzdem separat verfolgen will: Einerseits die Frage, wie man definiert und andrerseits die Frage, was Objekte sind.

Die Frage: "Was ist ein Objekt?" will als Antwort eine Definition. Wenn wir die Frage beantwortet haben, wissen wir, wie wir zu einer Definition gekommen sind. Wenn wir zuerst entscheiden, wie man definiert, können wir das Verfahren auf das "Objekt" anwenden und wissen dann, was ein Objekt ist. So sehe ich die wechselseitige Verknüpfung der beiden Fragen.
Ich wende mich jetzt der ersten Frage zu: Definitionen führen einen Oberbegriff und ein Kriterium ein. Ein Tiger ist in diesem Sinne eine Katze (Oberbegriff) mit gestreiftem Fell (Kriterium). Jetzt ist die Frage, welche Oberbegriffe weiterführen, respektive was "weiterführen" hier heissen könnte. Ich definiere Gegenstände (Objekte), um Ordnung in meine Erfahrung zu bringen. Das Grundprinzip ist die Klassifikation (Hierarchien) nach Verwandtschaften (Vererbung). Wenn ich Tiere und Pflanzen klassifiziert habe, weiss ich, dass Tiger katzenartiges Verhalten zeigen, und weil Katzen zu den Raubtieren gehören, und die Raubtiere zu den Säugetieren gehören, und die Säugetiere zu den Wirbeltieren gehören, weiss ich dass Tiger eine Wirbelsäule haben. Das ist, was Linne systematisches Wissen genannt hat. Ich würde das Ordnungswissen nennen, weil ich von systematischem Wissen mehr verlange, nämlich ein Wissen um die Funktionsweise eines Systems.
Deshalb erachte ich als "weiterführende" Begriffe, die ich beim Definieren suche, solche, die für Systeme stehen. Im exemplarischen Beispiel ist das Werkzeug ein potentielles System, weil es als Oberbegriff zu Automat, einem expliziten System, verwendet wird. Das Werkzeug ist funktional bestimmt, also aus einem Handlungszusammenhang heraus, es ist die oberste oder elementarste Stufe einer Definitionskette. Dass es ein System ist, zeigt sich nur in seinen Unterbegriffen, die in Definitionen nicht vorkommen. Daraus folgere ich, dass man vor jeder Definition sich entscheiden muss, ob man im Bereiche der Systeme definieren will, oder anders gesagt, ob man systemtheoretisch argumentieren will. Ich habe mich dafür entschieden, deshalb ist mir das Werkzeug als unentwickeltes System exemplarisch.
Tiger und Katzen sind natürlich auch Systeme, aber "natürliche", also solche, die ich nur erzeugen, aber nicht herstellen kann. Damit ist ein zweites Kriterium genannt: ich suche beim Definieren nach herstellbaren Systemen.
Schliesslich bewege ich mich beim Definieren immer in der Sprache, mache also - pragmatisch gesehen - Abbildungen von Referenten. Das Wort "Werkzeug" ist kein Werkzeug, the map ist not the territory. Meines Erachtens ist das der Ort der Uebung: sich bewusst halten, ob man von Abbildungen oder von Referenten der Abbildungen spricht. Im konventionelle Ingenieurswesen geht das relativ (!) leicht (obwohl Brecht fragen muss, ob wirklich die Könige das siebentorige Theben gebaut haben). In der Informatik ist die Unterscheidung zwischen Abbildung und Referent aber sehr subtil, weil die Referenten selbst sekundär lesbar, das abbilden oder beschreiben, was sie sind. Ein Programm beschreibt den Zustand des Automaten, auf welchem das Programm geladen ist.
 
Mein Vorschlag ist also, dass wir uns zuerst über das Definitionsverfahren einigen, und dann später unsere Argumente daran ausrichten oder prüfen.
|RÖBI:||Einverstanden. Nach Deiner Rede möchte ich aber den Ausdruck Definition durch Klassifikation ersetzen: Eine Klassifikation führt einen Oberbegriff und ein Kriterium ein. Wenn ich klassifiziere, ist die Unterscheidung Artefakt - Nicht-Artefakt aufgehoben: Ein Tiger ist in diesem Sinne eine Katze (Oberbegriff=Klasse) mit gestreiftem Fell (Kriterium=Unterklasse); Eine Maschine ist ein Werkzeug (Oberbegriff=Klasse), das durch nicht lebende Energie-Lieferanten angetrieben wird (Kriterium=Unterklasse).

Bisher haben wir mit dem Ausdruck Definition im Lexikon mehr verbunden als durch Klassifikation ersetzt wird. Die Differenz ist zum Teil im Ausdruck Erklärung aufgehoben, zum Teil kann der Ausdruck Erklärung erweitert werden und schliesslich kann ein Teil im Ausdruck Definition aufgehoben bleiben. Mein Vorschlag: Klassifikation (neu), Erklärung (verändert), Definition (verändert).
Der Ausdruck Objekt wird in dieser Redeweise implizit als Oberbegriff zu Artefakt und Nicht-Artefakt verwendet.
Ich kann jetzt sagen, dass im Definitionsverfahren weiterführende Begriffe systematische Erklärungen sind.
|ROLF:||Spontan wollte ich ja sagen, aber jetzt, wo ich nochmals hinschaue, missfällt mir zuerst Kriterium=Unterklasse und in der Folge der ganze Rest. Ein Kriterium ist keine Unterklasse. Ich nehme eine Schulklasse, beispielsweise die 4. Primarschulklasse im Schulhaus X der Gemeinde Y. Ein Kind zieht mit seinen Eltern in diese Gemeinde. Jetzt muss ich als Schulpräsident festlegen, ob es in diese 4. Klasse gehört oder nicht, dazu brauche ich ein Kriterium, beispielsweise das Alter des Kindes. Wenn das Kind zwischen 10 und 11 Jahren alt ist kommt es in diese Klasse, sonst nicht. Ich schlage vor, dass wir vor diesem exemplarischen Hintergrund nochmals unterscheiden, wofür wir die Ausdrücke Definition, Begriff, Kriterium und Klasse verwenden.

Vielleicht fällt Dir aber ein anderes Exemplar oder sackkonkretes Beispiel ein, das unser Denken in eine andere Richtung lenkt.
Ich glaube intuitiv, also vor jeder Reflexion, dass es sich um verschiedene "mentale" Operationen handelt, resp. um verschiedene Ebenen der Beschreibung.
|RÖBI:||So habe ich die Gleichsetzung Kriterium=Unterklasse nicht gemeint. Gemeint habe ich, dass das Kriterium zur Bildung der Unterklasse dient. Im Beispiel "ein Tiger ist eine Katze mit gestreiftem Fell" ist "Katze" die Klasse, "Tiger" die Unterklasse und "gestreiftes Fell" das Kriterium. Im zweiten Beispiel ist das Werkzeug die Klasse, die Maschine die Unterklasse und das Angetriebensein durch nicht lebende Energie-Lieferanten das Kriterium. Da ist nichts Neues in meinem Verständnis der Sache. Neu ist für mich, dass für dieses Definitions-Verfahren (falls wir dem weiterhin so sagen wollen) der Ausdruck Klassifikation passt. Im Beispiel des Schülers, der aufgrund seines Alters in die 4. Klasse kommt, ist die Schule als Ganzes die Klasse, die 4. Klasse die Unterklasse und das Alter des Schülers das Kriterium. Sag mir bitte nochmals, was Dir wirklich missfällt, bevor wir weiter unterscheiden.

|ROLF:||Ich kann natürlich nicht wissen, was Du wie gemeint hast - weisch weni meine? - mir hat die Textstelle
"Kriterium=Unterklasse" nicht gefallen. Auf der nächsten Ebene gefällt sie mir aber sehr gut, weil sie in meinen Augen exemplarisch ist für verkürztes Formulieren. Ich würde gerne explizit sagen, wie Klasse und Definition zueinander stehen.
Dein aktueller Vorschlag "Definitionen sind Beschreibungen der wesentlichen Merkmale von Objekten" missfällt mir, weil er als Formulierung keine Definition im alten Sinne oder keine Klassifikation enthält. Auch widerstrebt mir im Moment noch die Redeweise "Die aufwendigste Form der Definition ist die Erklärung". Ich kann sie nicht sinnvoll interpretieren, sie erscheint mir auch zu implizit. Vielleicht würde mir auch ein Beispiel helfen.

Dazu fällt mir übrigens - nur nebenbei - wieder ein, woher ich die ganze Geschichte habe. In der Einleitung zur Sinnlichen Erkenntnis schreibt Holzkamp über das Definieren von Begriffen mit Oberbegriff und Kriterium. Dort habe ich mit meinen Formulierungen angefangen. Ich glaube, das fällt mir jetzt ein, weil mich der Ausdruck "Klasse" - nicht so sehr Schul-Klasse - an Holzkamp erinnert.
Immer noch im spotanen weilend würde ich sagen, dass Klassifikation des Verfahren bezeichnet, das zu Klassen führt. Was ist eine Klasse? In Deiner letzten Antwort schreibst Du: "Im Beispiel 'ein Tiger ist eine Katze mit gestreiftem Fell' ist 'Katze' die Klasse". Das ist doch auch eine verkürzte Redeweise. Ich lese Katze=Klasse und ahne, dass Du das nicht so gemeint hast.
|RÖBI:||Und ich hatte so gehofft, Du würdest mir intuitiv nachempfinden, wie ich meine. Ich versuche es nochmals anders. Ich möchte dem Ausdruck Definition das Allgemeine, das er in der Formulierung "Definitionen sind Beschreibungen, die einen - inhaltlich gebundenen - Oberbegriff und ein Kriterium einführen, um Gegenstände zu klassifizieren" verloren hat, wieder geben. Wir definiern nicht, um Gegenstände zu klassifizieren. Wir definiern, um uns zu verständigen. Ich habe damals auch Holzkamp so gelesen: "... im Definieren werden vielmehr an 'im grossen und ganzen' bereits bekannten Gegebenheiten sprachlich bestimmte Züge herausgehoben, um so Verdeutlichungen, schärfere Abgrenzungen, Ordnungen, Klassifikationen zu ermöglichen". Wenn er nachher schreibt, dass es in Definitionen im eigentlichen Sinne: "... um möglichst präzise Bestimmung des genus proximum und der differentia specifica zu Klassifikationszwecken" geht, lese ich das so, dass eigentliche Definitionen Klassifikationen sind. Statt zwischen Definitionen und eigentlichen Definitionen zu unterscheiden ersetze ich eigentliche Definition durch Klassifikation. Eine Definition ist so etwas, wie eine Gleichung: auf der Einen Seite der Gleichung steht das zu Definierende (die im grossen und ganzen bekannte Gegebenheit) und auf der anderen Seite steht das Gleiche in anderen Worten. Nun gibt es verschiedene Formen für "das Gleiche" und die Klassifikation von ist (nur) eine davon. In der Erklärung sehe ich eine andere Form. Damit gewinne ich sprachliche Möglichkeiten und habe nichts verloren. Wenn ich "eine bereits bekannte Gegenbenheit" nicht sofort klassifiziere, sondern gemächlich definiere und dabei in Kauf nehme, dass ich zu Klassifikationen gelange, die mir als definitiv erscheinen, so erreiche ich vielleicht, was in meinem Verständnis Holzkamp erreicht hat: ein neues Verständnis für eine bereits bekannte Gegebenheit. Ob ich dem Klasse sage, ist eine definitorische Frage. Das Lexikon sehe ich als Beispiel. Viele Einträge genügen dem Kriterium Klassfikation zu sein nicht und trotzdem oder eben gerade deshalb macht es solchen Spass.

|ROLF:||Von Holzkamp habe ich sehr viel gelernt, wie von Maturana. Begrifflich sind beide schwach. Ich glaube, weil sie sich einbilden, von Menschen zu sprechen. Wir dagegen wollen von Objekten wie sie in der Programmierung vorkommen sprechen und haben deshalb einen Kontext, in welchem Begriffe adäquat sind. Gerade weil ich von H&M soviel gelernt habe, weiss ich, dass es dazu keine Begriffe braucht. Und unser Lexikon macht mir Spass, weil es Begriffe thematisiert, indem es zeigt, was Begriffe wären, und dass wir die meisten noch nicht haben.

Vielleicht ist es sinnvoll, die Begriffsarbeit im Lexikon zu machen und hier die Akzente anders zu legen. Bevor wir uns in der Definition der Definition verloren haben, wollten wir ja anhand unseres Projektes argumentieren. Nebenbei, es ist wahnsinnig, wie rasch ein Gespräck beliebig komliziert wird, wenn man es schreibt statt spricht.
Ich will also ein Neustart versuchen:
Unser Internet-Computer soll in etwa so funktionieren wie Dein Toolbook-Computer. Wenn ich ihn anstelle, will ich einen Browser (Objekt) sehen und im Browser will ich das Lexikon (Objekt) sehen. Das Lexikon enthält einen Index (Objekt) und beliebig viele Einträge (Objekt). Ein Eintrag ist ein Text (Objekt) mit einem mehr oder weniger festgelegten Format. Der Eintrag besteht aus Teil-Texten (Objekte). Ein Eintrag.Teiltext ist das Stichwort (Objekt). Die Buchstabenkette des Eintrag.Teiltext.Stichwort steht auch im Index. Im Index ist das Index.Stichwort ein Link auf den Eintrag.
Ich nehme hier ein Time-out: Glaubst Du, dass wir so zu einem Programm und zu einem Verständnis von Objekt kommen könnten?
|RÖBI:||Wo bleibt die Musse?

Zu einem Programm kommen wir nur, wenn wir es herstellen. Ich beginne damit. Es müsste ja eigentlich spielend leicht zu bewerkstelligen sein, da wir schon ein funktionierendes Beispiel haben. Die Objekte werden von selbst ins Spiel kommen. Ich werde darüber berichten, wenn sie mir begegnen.