Benutzer Diskussion:Fiede/WS10-Cypl-09-10 12 10

<root> <div class='right_side_navigation' style='width:156px;position:fixed;bottom:50px;background-color:#efefef;border-color:#bbbbbb;border-width:1pt;border-style:solid;padding:1px 2px;font-size:8pt;text-align:center;filter:alpha(opacity=90);-moz-opacity: 0.9;opacity: 0.9;'> <comment><!---------------------------------------------------------------------------------------------------------------> </comment> Übersicht<br /> Hauptseite<br /> Letzte Änderungen<br /> Alle Seiten

<hr />

Vo 01. 08.10.10<br /> Bildwelten (CP)<br /> Vo 02. 15.10.10<br /> Vo 03. 22.10.10<br /> Vo 04. 29.10.10<br /> Transkript 2<br /> Vo 05. 05.11.10<br /> Vo 06. 12.11.10<br /> Vo 07. 19.11.10<br /> Vo 08. 03.12.10<br /> Überleitung/D<br /> Vo 09. 10.12.10<br /> Objektorientierung/D<br /> Vo 10. 17.12.10<br /> Vo 11. 14.01.11<br /> Vo 12. 21.01.11<br /> Vo 13. 28.01.11<br />

<hr />

Hilfe<br /> Wiki Hilfe<br /> Infos zur Vorlage<br /> <comment><!---------------------------------------------------------------------------------------------------------------> </comment></div><ignore><includeonly></ignore><ignore></includeonly></ignore></root>

Ontologie (IT)

Ich habe auf meiner Seite einen Beitrag zu diesem Thema erstellt und möchte auch an dieser Stelle darauf verweisen, weil ich die Sache sehr interessant finde. Ontologien sind Erweiterungen des in der Vorlesung dargestellten Klassen/Objekt-Paradigmas. So wie eine Klasse das Konzept eines Dinges der wirklichen Welt repräsentiert, modelliert eine Ontologie in der Informationstechnologie einen Ausschnitt der Realität.
Weitere Informationen zum Thema Ontologien und dem Semantic Web finden sich hier.

Anmerkung zur Transkription

Ich habe bei der Erstellung der Wiki-Seite Veränderungen am genauen Wortlaut des Vortrags vorgenommen, um den Text besser lesbar zu machen. Dort, wo ich inhaltlich etwas verändert habe, ist das als Anmerkung auf der Seite gekennzeichnet. Ich habe auch die Wort-für-Wort Transkription der Vorlesung hier reinkopiert, also falls meine Eingriffe an manchen Stellen nicht korrekt sein sollten, können diese Stellen ganz schnell wieder durch das Original ersetzt werden!

Transkription VO 9 Cyberplatonismus 10.12.2010 (Original)

Überleitung (Fortsetzung)

Ich habe heute in der Früh das Wiki aufgemacht und habe geglaubt, es ist Weihnachten. Ich weiß nicht, ob Sie schon reingeschaut haben. Es bezieht sich jetzt nicht darauf, dass ein Kollege tatsächlich eine Cyberplatonismus Vorlesung rein gegeben hat, sondern es bezieht sich darauf, dass zu dem von mir das letzte Mal hier diskutierten Bild, Kontrast, den ich aufgegriffen habe, mitgebracht habe aus Brünn in der Nacht ein Kollege einen Beitrag geschrieben hat. Allerdings ist das nicht einfach ein Beitrag, sondern auf Englisch ist es ein Eye Opener, also es ist eine unglaubliche zusätzliche Ergänzung, die ich Ihnen kurz vorstellen möchte. Vor allem deswegen, weil es an wichtigen Stellen das ergänzt und erweitert, was ich im Zusammenhang mit Herrn Chrysanthos dargestellt habe. Und es ist mir auch gestattet vorzugreifen auf das, was ich heute und das nächste Mal machen werde, nämlich über objektorientierte Programmierung und die Rolle des verborgenen Platonismus in der objektorientierten Programmierung zu sprechen. Dann erinnere Sie noch daran, dass diese Gegenüberstellung der beiden Bilder [Link!], die ich übernommen habe von Chrysanthos, sozusagen den Anschein erweckt, dass das hier zwei gleichformatige Bilder sind, abstrahiert von sämtlichem Kontext. Das ist sozusagen dekontextualisiert und ich habe mich auch zu einigen ein bisschen naseweisen Vermutungen verleiten lassen, ohne in den Kontext genauer hineinzuschauen. Das war noch nicht naseweis zu sagen, dass der Kübel und die Amphore hier vorkommen, aber dass das ein Treppengeländer ist, kann ich nicht wirklich aufrecht erhalten und hätte ich nicht aufrecht erhalten können aus einer genaueren Kenntnis der Geschichte. Und dass dieses Treppengeländer das Kreuz symbolisiert, ist nachgerade unverteidigbar, wie Sie gleich sehen werden. Es gibt einen Mithörer unter den Anwesenden in dieser Lehrveranstaltung, der mit der Sache vertraut ist – anders als ich – mit dem, worum es da geht, und der hat uns alle (mich, Sie) darauf aufmerksam gemacht, was eigentlich der Kontext von dem Ganzen ist. Kurzum, Sie können das auf der Diskussionsseite zu dieser Seite lesen. Ich fasse das einmal kurz. Warum ist dieser Bruder Philoumenos ein Heiliger? Er ist ein orthodoxer Bruder, der ein Mitglied des Ordens für die Bewahrung des heiligen Grabes ist und der sozusagen stationiert war an einer Stelle auf der Westbank, und zwar an einer Stelle, wo einst der Ort Sichem gelegen ist. Und an diesem Ort Sichem gibt es zwei biblische Belege, dass der vorkommt, in jedem Fall gibt es dort den berühmten Jakobsbrunnen. Der Jakobsbrunnen ist die Szenerie einer Begegnung Jesu im Neuen Testament mit einer samaritischen Frau und das ist eine Szene, wo es darum geht, so wie der Jakobsbrunnen Wasser spendet, Jesus selbst das lebendige Wasser ist. Diese Lokalität ist in christlich-orthodoxer Hand seit dem vierten nachchristlichen Jahrhundert und der Orden, der hier genannt ist, wacht darauf, also betreut diese Lokalität. Und es gibt eine zerstörte Kirche und neue Kirche, die aufgebaut worden ist und fertig ist 2007. Was passiert ist, ich habe das jetzt weiter nicht recherchiert, aber ich nehme nicht an, dass hier sozusagen keine Oberflächlichkeit vorliegt, so wie es bei meiner Oberflächlichkeit war. Was passiert ist, 1979 ist der Bruder Philoumenos offensichtlich von fanatischen Zionisten erschlagen worden an dieser Stelle. Und nicht nur erschlagen worden, sondern auch noch mit einem Ritual, das ihm sozusagen kreuzweise den Körper zerlegt hat. Das ist der Grund, warum er heilig gesprochen worden ist. Und Sie haben jetzt hier von dem Kollegen, der firmiert unter dem Namen Mi5er, eine ganz eindrucksvolle Dokumentation der Ereignisse, der ganzen Bildwelt in Gegenüberstellungen zwischen Fotos, Abbildungen und Ikonen. Da kommt einiges dabei heraus, was ich sozusagen nachlässigerweise entweder nicht gesagt oder gar nicht bedacht habe. Hier haben Sie Amphoren, hier ist die alte Ruine der Kirche, hier – das ist die Geschichte, die Nachlässigkeit – da ist schon irgendwie ein Stiegenhaus dabei, aber die Konstellation ist nicht die eines Stiegenhauses, sondern die Konstellation auf dem Foto ist der Jakobsbrunnen. Und jetzt wird es sozusagen interessant, das ist jetzt die Kontextualisierung von dem, womit wir sozusagen operiert haben. Das ist ein Standard-Foto von Philoumenos und hier gibt es etwas – und das sagt er jetzt leider nicht – aber es schaut irgendwie so aus, als ob das noch zu seinen Lebzeiten, nein, das ist nicht zu seinen Lebzeiten, weil hier ist er glaube ich schon als Heiliger dargestellt. In jedem Fall, der Hinweis, der hier gemacht ist, ist, dass in diesem Foto die Real-Life-Fotografie schon viel deutlicher gesehen wird und gezeigt wird als eingebettet bereits in einem Heiligenverständnis, also die Sache ist nicht so, dass – so wie ich das dargestellt habe oder wie man es oberflächlich machen würde – dass es eine Person gibt, die lebt ein normales Leben und dann wird sie in den Heiligenbereich versetzt. So habe ich ja das das letzte Mal gesagt, sozusagen eine Überhöhung. Erinnern Sie sich, ich habe die Sache so dargestellt, als ob hunderte Fotos, die man machen könnte von dieser Person hier nichts enthalten davon, dass er Heiliger ist, dass das Heilige eine Qualität ist, die sozusagen darüber kommt und darüber gestülpt wird. Was Sie hier sehen, ist, dass das Ganze, wenn man es mal wirklich ansieht, wie es funktioniert, eine doppelte Straße ist, von beiden Richtungen her geht, das heißt, man bewegt sich schon im gewöhnlichen Leben so, dass man unter anderem eine Ikone werden kann. Also man hat eine Vorstellung von Heiligtum, das sind die aus der katholischen Tradition jetzt her gesprochen, sozusagen die frommen Personen, die in der Kirche sich schon so verhalten, entsprechend angelisch oder so wie die Heiligenbilder, die in der Kirche sind – sozusagen eine Anverwandlung an das Bild des Heiligen in der aktuellen Körperhaltung. Und das ist schon mal ein Hinweis darauf, dass es hier eine andere, eine untergründige oder nicht so untergründige Exchange-Funktion gibt von der Idealisierung in das Leben und vom Leben in die Idealisierung hinein. Die sind aufeinander abgestimmt. Hier haben Sie Ikonen, die ganz offensichtlich im Nachhinein dann ikonifizierte Darstellungen dessen, was da passiert ist. Und hier noch eine eindrucksvolle, wichtige Geschichte, hier haben Sie Philoumenos, das ist hier der Name, der hier mit Brillen sogar auf der Ikone vorkommt. Schauen Sie sich das mal genauer an, ich denke, das ist also durchaus Gelegenheit noch hier weiter zu diskutieren. Das sind Ikonendarstellungen vom heiligen Philoumenos. Gehen wir da weiter. Eine Sache, dieses mit der Entzifferung ist ein ausgesprochen gehaltvoller Text, der sozusagen auch nobel genug ist, mich nicht direkt zu attackieren, obwohl er das Recht dazu hätte. Vor allem ist es eine gute Interpretation dessen, warum der ein Kreuz in der Hand hat.

Was ich jetzt anknüpfend daran noch sagen möchte, bevor ich dann weitergehe und das aber damit auch verbinde schon vorwegnehmend mit Absichten, die ich in der heutigen und nächsten Stunde verfolge, ist das Folgende: Um es mal mit einem ganz ungeniert informationstechnischen Begriff zu beginnen, die zwei Basiskategorien in der objektorientierten Programmierung, auf die wir dann auch übergehen werden, sind Klassen und Objekte (Instantiierungen). Klassen sind quasi schematische Vorgaben, die in abstrakter Form alles das beschreiben, was im Prinzip zu Objekten gehört, die aber keine Objekte sind, sondern sogenannte Object Factories. Das sind sozusagen Modellvorstellungen (Patterns), die instantiiert werden und durch das Instantiieren einzelne wirkliche Objekte produzieren. Das ist – ich sage es jetzt im Kurzverfahren – von der Idee her ist das so ähnlich wie: Sie haben die Idee des Pferdes, in die Idee des Pferdes gehört, dass es vier Beine hat, dass es ein Tier ist, dass es wiehert, dass es einen Schwanz hat, usw. Das ist aber die Idee des Pferdes. Und dann gibt es wirkliche Pferde, und die wirklichen Pferde sind Realisierungen der Idee des Pferdes. Das ist totaler Vulgär-Platonismus, aber in der objektorientierten Programmierung ist es so. Das ist sozusagen eine faire Beschreibung dessen, was die als Grundlage für das Programmieren einführen, nämlich – ich werde auf das auch gleich zu sprechen – im Programmieren soll man nicht mit bestimmten Verfahrensanweisungen dem Computer Befehle geben, dass er irgendwas macht, und diese Befehle auf eine raffinierte Weise ineinander schachteln und sequenzieren, sondern es ist sinnvoll beim Programmieren davon auszugehen, dass die zwei wichtigsten Basiskategorien eines programmierten Vorgehens Objekte sind. Und Objekte, das wird immer wieder gesagt, Objekte in der Software entsprechen Objekten in der wirklichen Welt, also ein Pferd oder ein Stuhl oder ein Tisch. Und wodurch ist ein Objekt charakterisiert, Objekte sind dadurch charakterisiert, dass sie eine Idee verwirklichen, also noch einmal – wir sind auf der ganz vulgären Ebene – jemand sagt, er braucht einen Tisch. Er weiß noch nicht, wie der Tisch ausschaut. Er braucht einen Tisch, warum braucht er einen Tisch? Weil er etwas braucht, worauf er sein Frühstück sozusagen hinstellt, und das heißt, er braucht etwas mit Platte und erhöht vom Boden und belastbar, usw. Und wenn er jetzt jemandem sagt „Bitte bring mir einen Tisch“, dann geht er davon aus, dass die Person ihm einen Tisch bringt, ohne dass ich der Person gesagt habe: „Ja bitte, aber das sollte ein Tisch sein, der diese und diese Farbe hat“. Wenn ich das der Person nicht sage, wenn ich nur sage, ich brauche einen Tisch, mir ist alles andere egal, dann weiß durch unsere Kommunikationssituation die andere Person, ok, sie schaut irgendwo, wo ein Tisch ist, sie geht in den nächsten Raum, findet dort aufgrund der Kenntnis, der Kompetenz, die sie hat, den Gegenstand, der ein Tisch ist und bringt den Tisch her. Worin besteht diese Kompetenz, die die Person in die Lage versetzt, den Tisch herzubringen? Sie weiß, worum es geht, sie weiß, Tisch bezieht sich – er sagt eben nicht: „Bring mit etwas mit vier Beinen“ und so weiter – sondern sie weiß, im Prinzip sind die Haupteigenschaften eines Tisches die Folgenden – und aufgrund dieser Kompetenz des Umgangs mit den Haupteigenschaften, was wir traditionell, wie gesagt ein bisschen banalisierend den Begriff, die Idee des Tisches nennen - ist es möglich, dass die Person im anderen Zimmer einen extra Einzeltisch, der dort steht, erkennt als ein Beispiel eines Tisches, als eine Instanz eines Tisches – und diese Instanz des Tisches dann da her bringt. Was ich Ihnen damit sagen wollte, ist, die doppelte Funktionalität, dass wir auf der einen Seite ein Feature-Set haben, Eigenschaften, die wir zusammenfassen als so etwas von der Art, und so etwas von der Art kommt in Einzeldingen vor. Das werden wir uns sozusagen noch ansehen, wie dieses Muster weiter verhandelt wird. Warum ich es jetzt hier im Kommentar zu Philoumenos sage, ist, dass eine oberflächlich von außen kommende Betrachtungsweise dieses Heiligenverhältnisses, des Verhältnisses der beiden Bilder zueinander von mir so geleitet worden ist, dass ich gesagt habe, ok, da gibt es die Heiligkeit und die Heiligkeit ist instantiiert in einem Menschen. Und die Heiligkeit ist an dieser Stelle, so habe ich auch argumentiert, die Heiligkeit ist kein abstrakter unsichtbarer Begriff, sondern das Typus der Heiligkeit hat selber eine bestimmte Gestalt, das ist diese Ikonengestalt, in der die Heiligenhaftigkeit greifbar ist. Und diese Heiligenhaftigkeit wird sozusagen umgesetzt in einer einzelnen Person. Man könnte es jetzt so sagen, was ich da gesagt habe ist eine ziemlich objektorientierte Betrachtungsweise, worum es da geht, wenn wir einer Person Heiligkeit zusprechen. Wenn wir einem Ding zusprechen, dass es ein Pferd ist, dann sagen wir, wir betrachten es als einen Einzelfall von einem Begriff. Der Begriff ist irgendwo in der Luft, das ist für die Philosophie ein wichtiges Problem, wie in der Luft der Begriff ist, aber für die Software-Entwicklung ist das nicht ein wichtiges Problem, weil in der Softwareentwicklung kann man sozusagen sowieso von Anfang an nur mit Konstruktionen operieren und die Konstruktion, dass es ein Muster gibt, ein Template, ein Pattern, auf der einen Seite und dann eine Umsetzung dieses Templates in einzelne Bereiche, diese Konstruktion ist für die Softwareentwicklung weiter nicht problematisch, und das gibt den netten Effekt, dass wir in der objektorientierten Programmierung, weil das alles etwas ist, was wir uns sozusagen selber konstruieren können, auf eine sehr ungenierte Art und Weise mit platonischen Motiven arbeiten können, was nicht der Fall ist in einer mehr von der begrifflichen Problematik und der Frage, um was es sich da eigentlich handelt, wenn wir von Ideen und Begriffen reden, geleiteten Überlegung.

Das letzte, was ich dazu jetzt noch sagen möchte, ist, ich werde hinauskommen in meiner Kette von Überlegungen, die ich Ihnen jetzt da vorlege, werde ich darauf hinauskommen, dass ein Unterschied zwischen diesem platonisierenden Muster in der Softwareentwicklung und dem, was die Philosophie sagen möchte im Zusammenhang mit Begriffen und der Realisierung von Begriffen, dass der wichtige Unterschied genau darin besteht, dass es aus philosophischer Sicht einen Widerspruch gibt, eine Interaktion gibt, einen Austausch gibt zwischen den Mustern und den Umsetzungen. Also genau das, worauf ich hier aufmerksam gemacht worden bin, dass die richtige Rede von der Heiligkeit nicht so vollzogen werden sollte, dass man sagt, da hat sich der Geist Gottes auf die Person gesetzt und hat sie zum Heiligen gemacht – das sind primitive Muster – sondern dass die richtige Rede die ist, dass es einen Sitz im Leben gibt, dass es Abläufe in der Geschichte gibt, die einen Anstoß geben für das Auslösen der Fragestellung der Problemstellung, was passiert da eigentlich und dass das Heiliggesprochen-werden eine sehr greifbare Reaktion auf einen sehr brutalen Ablauf im echten Leben ist. Wenn man das dazu sieht, dann kriegt man eine weniger mechanische Betrachtungsweise, und auch weniger mechanisch und weniger semiotisch, ich habe es ja semiotisiert, semiologisch aufgefasst dann mit der Naomi Campbell und dem Paris-Match Beispiel, als das, was ich das letzte Mal gesagt habe. So viel möchte ich heute dazu sagen.

Objektorientierung

Dann gehe ich über zur Objektorientierung. Da habe ich einen weiteren heute in der Früh hier rein gespielten Beitrag, mit dem ich vielleicht beginne. Das hier ist ein schönes Beispiel von Spaghetticode, wie man so sagt. Ich glaube, das ist im ersten Ansehen leicht und sofort zu erkennen. PW hat hier ein noch schöneres Beispiel hier zur Verfügung gestellt. Worum handelt es sich da? Das ist ein taktisches Gesamtkonzept der U.S.Army über den Krieg in Afghanistan. Und wie er hier zurecht sagt: "When we understand that slide, we’ll have won the war,” General McChrystal dryly remarked, one of his advisers recalled, as the room erupted in laughter. Also, worum es hier geht, ist jetzt hier nicht unser Thema. Warum verwende ich das hier als Beispiel? Probleme des Ablaufs in komplexen sozialen Situationen werden schematisiert auf eine Art und Weise, die, wenn es irgendwie in die Nähe der Realität kommt, unüberschaubar, unverständlich mehr oder weniger werden. Man kann sich sehr gut vorstellen, auf der Basis von dem, wie WikiLeaks zustande kommt. Irgendwo ist da ein kleines Loch, das kann sozusagen nicht anders gehen, als dass da irgendwo jemand sitzt, der alles das auf eine CD, DVD speichert in dieser Art und Weise.

[4 Lines of Code] Das ist ein Einstiegspunkt, den ich gewählt habe, um Sie kurz zu konfrontieren mit einem Überblick über die Entwicklung von Programmiersprachen. Das ist wie gesagt auch nur wirklich komplett stichwortartig. Ich habe Ihnen hier zwei Skizzen hinein geklebt, die ich aus einem Blog „4 Lines of Code“ genommen habe. Nur damit wir ungefähr wissen, in welchem Bereich wir uns bewegen. Es gibt sozusagen den Beginn des Programmierens, Software Engineering ist der Basisausdruck, wo man technische Ingenieurswissenschaft verstanden hat als genauso wie man es mit den Maschinen macht, macht man es mit der Software. Das war eine Zeit, wo es riesige große Computer gegeben hat, noch vor dem Personal Computer und wo jeder große Computer nicht nur die entsprechenden Relais, Schaltungen, Elektronik, usw. gehabt hat, sondern jedes von diesen Beasts (großen Tieren) hat auch eine eigene Sprache gehabt – das war die Sprache, mit der man mit dieser großen Maschine kommuniziert hat, war praktisch genau angepasst, Maschinensprache, Assembler-Sprache hat das geheißen, genau angepasst an die Kapazitäten dieses Computers. Das ist deswegen – kleine Nebenbemerkung – von keiner kleinen Bedeutung, weil aus dieser Zeit die Schicht von Expertinnen und Experten, die gearbeitet haben an der Betreuung und an der Befütterung sozusagen dieser großen Maschinen der Auffassung gewesen sind, dass es vollkommen egal ist, wem man die Software gibt, weil die großen Computer Millionen Dollar gekostet haben. Kein Mensch konnte sich die leisten außer einige wenige Regierungs- und Verteidigungsinstanzen, und wenn du sozusagen eine solche Millioneninvestition nicht gehabt hast, dann war das vollkommen wurscht, ob du den Code gehabt hast oder nicht, den hast du sozusagen studieren, anschauen können, damit konntest du nichts machen. Nur mit der Maschine konntest du es machen. Von daher kommt die allgemeine Vorstellung, dass die Software etwas ist, das man einander geben kann, um auf gute Konzepte, Ideen zu kommen, weil man sie sowieso nicht zusätzlich verwenden kann. Und das hat sich erst im Laufe der Zeit geändert, in einer Situation, in der die Personal Computer es möglich gemacht haben, dass man mit einer Software hunderte, tausende, Millionen von diesen Maschinen betreiben kann – dasselbe Betriebssystem, wie man heutzutage sagen würde, ein MS-DOS, Windows oder Linux Betriebssystem, und da war dann plötzlich das große Geld am Horizont, weil man das jedem einzelnen verkaufen kann, weil jeder einzelne und jede einzelne eine Anwendung gehabt hat dafür – die ist bei ihr zu Hause gestanden, und hat gewartet auf das entsprechende Betriebssystem. Also das nur als kleine Klammerbemerkung. Ausgehend von solchen Softwaresprachen, die, um Ihnen zwei Beispiele zu sagen, also der Spaghetticode wird hier platziert in die Sechziger Jahre, ausgehend von diesen Ansätzen ist so in etwa in den Achtziger Jahren die objektorientierte Programmierung entstanden. Zum Spaghetticode zwei Definitionen, die ich Ihnen hier auch reinkopiert habe – Sequential Programming und Procedural Programming – wenn Sie sich das anschauen, ich gehe da jetzt nicht im Einzelnen dort hin. Wenn Sie sich die Beschreibungen und Diagramme anschauen, kommen Sie drauf, das sind frühe Versuche, in den ad hoc Ablauf, den man im Programmieren zunächst einmal verwendet hat, eine gewisse Ordnung zu bringen. Also, die frühe Problemstellung war die, man hat ein Problem, dieses Problem muss auf der Maschine so gerechnet werden, in diesem Sequential Programming Beispiel also zum Beispiel die Fläche des Kreises berechnen. Die Fläche des Kreises berechnet man mit einer gewissen Formel, in diese Formel gibt man Werte ein, dann wirft man die Maschine an, die Maschine hat das Resultat ausgerechnet, so ist es sozusagen eingestellt und damit ist der Auftrag der Maschine vorbei. Eine andere Maschine macht es aufgrund von anderen Befehlen. Was man allenfalls tun kann, ist, diese Art von Befehlen aneinander zu reihen und Schritt für Schritt abzuarbeiten. Wenn in dem Maße, in dem es dazu gekommen ist, dass das immer komplexer wird, bei diesen Dingen, in dem Maße, in dem man mal so gesagt hat, die Computer sind derartig mächtige Maschinen, dass wir ihnen eine große Anzahl von miteinander verbundenen Aufgaben geben können, dann ist das in die Richtung gegangen zunächst einmal, dass man diese Aufgaben also genau definiert hat. Wenn Sie hier sehen, sind das alles nachvollziehbare, sinnvolle Verbindungen zwischen verschiedenen Aufgaben, aber man wird ab einem gewissen Zeitpunkt den Wald vor lauter Bäumen nicht mehr sehen. Das ist ziemlich klar, das ist ungefähr so ähnlich wie im Wiki. Wikis sind, wenn sie ein bisschen gebraucht werden, verwendet werden, auf der natürlichen Ebene sind die typisch so etwas wie Spaghetticode, weil Sie haben irgendeinen Beitrag, jemand macht einen Beitrag zu dem Beitrag, jemand macht Diskussionsseite zu diesem Beitrag, auf dieser Diskussionsseite gibt es wieder einen Beitrag, dieser Beitrag bezieht sich zurück auf... - also das ist ein klassischer Fall von Spaghetticode, wenn man nicht eingreift und der Effekt wird Ihnen vermutlich im Philo-Wiki auch schon aufgefallen sein. Jemand, der nicht dabei war, wie das das erste Mal entstanden und geschrieben worden ist, kennt sich nach kurzer Zeit nicht mehr aus und ich selber kenne mich nach einiger Zeit nicht mehr aus, in dem, wie das alles zusammenhängt, weil niemand einen Plan gemacht hat, davon, wie das sinnvoll funktioniert, wie das für eine Kurzorientierung, für einen Schnellzugriff, für eine strukturierte Entwicklung gut organisiert werden kann. Im Zusammenhang mit Wiki bleibe ich dabei, dass das eine gute Sache ist oder sein kann, aber in der Softwareentwicklung ist relativ klar, dass das hier, wenn es sich so entwickelt, nicht wirklich zukunftsweisend ist. Und ich habe jetzt zwei – nachdem es da eine ganze Reihe von, das ganze Netz ist voll von Einleitungen und Erläuterungen und Tutorials für diese objektorientierte Programmierung. Das hängt damit zusammen, das in den Achtziger Jahren war eben auch das WWW auch so weit, dass das intensiv genutzt worden ist für Darstellung der Probleme und auch natürlich für Lehrmaterialien. Ich gebe Ihnen zwei Beispiele, die uns sozusagen da ein bisschen weiter die Entwicklung zeigen. Um es einfach mit Worten zu beschreiben, auch wenn Sie das mal hören und wenn Sie jemandem sagen, sie haben in Philosophie etwas über objektorientierte Programmierung gehört, dass Sie das zumindest identifizieren können, worum es da geht. Also prozedurale Sprachen sind so etwas wie Fortran oder auch C. C ist deswegen ausgesprochen wichtig, weil das die Sprache ist, in der Unix geschrieben worden ist. Unix ist ein Betriebssystem, das erstmals auf massive Art und Weise sozusagen das volle Internet integriert hat und für Maschinen geschrieben worden ist, die dann ein bisschen schon in den Mainstream hinein geraten sind, also die sich schon mehrere Leute kaufen konnten, und um diese Linie jetzt noch bis zum Ende zu führen: Linux ist deswegen derartig erfolgreich gewesen, weil es eine Unix-Implementierung für PCs war. Unix lief auf Großrechenanlagen und war gerade aus diesem Punkt auch frei zugänglich, aus dem Grund, den ich schon gesagt habe, weil die Software da nicht wichtig war. Was der Linus Thorvalds gemacht hat, war, dieses Unix-System umzuschreiben, also eine Version dieses Unix-Systems, das ein sehr leistungsfähiges, in C geschriebenes Betriebssystem gewesen ist, für IBM-Computer, also für die Prozessoren ab 386, die von Intel hergestellt worden sind, umzuschreiben, sodass man einen Computer gehabt hat, auf dem man normalerweise dann Windows 3.1 (DOS und darüber Windows 3.1) – das war der Normalcomputer, den man sich in der Achtziger, Neunziger Jahren dann schon leisten konnte. Und für diese Art von Computern hat Linus Thorvalds eine Unix-Version geschrieben, nicht nur er, sondern das war eine massive Internet-Aktion. Das hat geheißen, dass man einen von diesen Computern, den man unter Windows gehabt hat, der ständig abgestürzt ist, der ausgesprochen langsam war, ich kann mich gut erinnern daran, da hat man ein Unix-System rein getan. Das Unix-System ist verbunden gewesen mit einer sofortigen Verbindung ans Internet, mit einer sofortigen Zur-Verfügungstellung von Servern, mit einer sofortigen Zur-Verfügungstellung der ganzen Routinen und Instrumente, mit denen man neue Software installieren kann. Es war also einfach ein gigantischer Sprung, wenn auch nicht von der Benutzerfreundlichkeit (Usability), ziemlich haarig, sagen wir es einmal so. Aber das ist sozusagen die Richtung, die Entwicklung, die von C in den Bereich von Linux und dem, was wir heute haben, geht. Das war die Vorbemerkung dazu, dass wir hier C++ haben. C++ ist eine objektorientierte Weiterentwicklung von C, die sich besonders eignet für alles, was mit Graphik zu tun hat. Also C kommt auch aus einer Zeit, auch dieses Prozedurale kommt aus einer Zeit, wo man noch mit der Kommandozeile operiert hat. Wenn Sie in die Graphik gehen, und da kann ich Ihnen jetzt das schon ein bisschen deutlicher machen, welch eine Typus von Problemstellung die Softwareentwicklung da hat, wenn Sie in eine graphische Benutzeroberfläche gehen. Sie können sich vorstellen, da oben ist so eine Ikone für den Firefox, den Browser. Wenn Sie den Firefox selber haben, dann sehen Sie da das Folgende: Er hat ein Fenster aufgemacht, wir man heutzutage sagen würde. Dieses Fenster hat eine Adressleiste, dieses Fenster hat diese Buttons hier, es hat hier einen Menüeintrag - und wenn man so über die Sachen redet, wird schon ziemlich klar, dass das immer wieder kommt. Also wenn Sie fünf von diesen Firefox-Sachen aufmachen, und nicht nur wenn Sie Firefox aufmachen, sondern wenn Sie dafür auch noch ein Office-Paket aufmachen und irgendein kleines Spiel aufmachen, dann werden Sie erwarten, dass diese Fenster alle mehr oder weniger die selben Eigenschaften haben. Sie sollen zum Beispiel vergrößerbar und verkleinerbar sein, man soll sie wegklicken können, man erwartet eine Menüleiste – und an dieser Stelle haben Sie schon genau das von mir vorhin präjudierte Problem einer Klasse und einer Instanz. In dem Moment, in dem Sie eine graphische Oberfläche haben, sind Sie anders als in der Kommandozeile. In der Kommandozeile erzeugen Sie mit jedem Befehl, den Sie da eingeben, eine Reaktion des Computers. Diese Reaktion ist zum Beispiel abgestimmt auf die bestimmten Parameter, Schalter, die Sie der Befehlzeile mitgeben, d.h. Sie können sehr genau steuern, was dieses Programm im Einzelnen für sie macht, wenn Sie die benötigten zusätzlichen Eingaben beim Aufruf des Programmes von Vornherein mit eingeben. Um Ihnen ein spezielles Beispiel zu sagen, nehmen wir an, Sie haben ein Soundfile, das ist komprimiert im APE-Format und Sie wollen das APE-Format in ein MP3-Format transferieren, dann können Sie einen Transcoder aufrufen auf der Kommandozeile. Diesem Transcoding-Programm sagen Sie, wie heißt das Programm, mit dem Sie arbeiten wollen, wie soll das Programm heißen, das Sie sozusagen als Resultat haben wollen und welche Konversion wollen Sie durchführen. Dann sagen Sie das dem Programm, das ist ein Input, das Programm läuft, am Ende steht das MP3-File und das Programm hat das für Sie gemacht ohne weitere schöne Visuals sozusagen. Das ist nicht etwas, was die meisten Benutzer heutzutage machen, was man heutzutage macht, man ruft einmal ein Programm auf, man schaut einmal, welches Programm kann das, dann ruft man das Programm auf – damit ist noch überhaupt nichts geschehen im Zusammenhang mit dem Transcodieren, sondern damit haben Sie ein neues Fenster geöffnet. D.h. an dieser Stelle hat sich das Programm, das Sie aufrufen, hat sich einmal ans Betriebssystem gewendet und hat dort gesagt, ich brauche ein Fenster, damit ich weiterlaufen kann und das Betriebssystem hat dieses Fenster zur Verfügung gestellt, aufgrund von etwas, was sozusagen eine Klasse von Fenstern ist. Aus der Klasse von Fenstern, was die Abstraktbeschreibung von dem ist, was zu einem Fenster so dazu gehört, wird ein Ding produziert und dieses eine Fenster, dass dann das Fenster auf ihrem Desktop ist, wird von dem Programm mit Inhalt gefüllt. Das ist der Grund, warum C++ als objektorientierte Programmierung im Zusammenhang mit graphischer Benutzeroberfläche aktuell geworden ist. Und hier haben Sie den Beginn, wie das schon so ist bei historischen Rückblicken aus der Sicht einer neuen technischen Entwicklung, die liefern dann immer eine Basis-Anfangs-Motivierung dafür, warum es interessant ist, dass es sie gibt, warum das wichtig ist. Hier ist eine ganz schöne Aufzeichnung der Fragen, die zur objektorientierten Programmierung geführt haben: http://www.cpp-home.com/archives/206.htm How to represent real-life entities of problems in system-design? How to design systems with open interfaces? How to ensure reusability and extensibility of modules? How to develop modules that are tolerant to any change in future? How to improve software productivity and decrease software cost? Gehen wir das mal ansatzweise durch. Was ich Ihnen vorher auch schon angedeutet habe, es geht nicht mehr einfach darum, nur Befehlssequenzen zu haben, sondern es sollen real life objects innerhalb eines Systemdesigns repräsentiert werden. Und real life objects sind nun mal nicht Folgen von Befehlsabläufen, sondern sind Objects. Man muss sich sozusagen fragen, worin in diesem softwaremäßigen Zusammenhang jetzt dann Objekte bestehen. Diese Objekte andererseits stehen nun vor der Frage, wie verhalten sie sich zu anderen Objekten. Nehmen wir einmal an in meinem Beispiel von den Fenstern, sie rufen ein Programm auf, dieses Programm erscheint in einem Fenster. Dann gibt es ein zweites Programm, das hätten sie auch ganz gerne, sie wollen nämlich nicht nur das Philo-Wiki aufrufen, sondern sie wollen auch noch ihre Musik dabei hören, d.h. sie rufen den Windows Media Player auf oder etwas Ähnliches. Das ist natürlich ein zweites Programm und das Fenster für dieses Programm ist ein zweites Objekt. Im einen Programm ist der HTML-Browser, im anderen Programm läuft ihr Audio-Programm. Wie verhalten sich die jetzt zueinander? Es gibt eine Art und Weise, wie sie sich nicht zueinander verhalten sollten, dürften, nämlich so, dass wenn das eine Programm abstürzt, der ganze Computer abstürzt. Das ist etwas, das immer wieder vorkommt, aber das genau ist unerwünscht. Es kann sozusagen immer wieder mal passieren, dass im Rahmen eines laufenden Programms etwas schief geht, und das was mit dieser Sammlung von Objekten passiert in einen Zustand gerät, in dem man weiter nichts mehr machen kann. Was total pfui ist, ist, dass diese Fehlerhaftigkeit des einen Programms sich auf alle anderen ausbreitet und damit das ganze System ausschaltet. Anders gesagt, diese Objekte, die da erzeugt werden, sollen für sich stehen. Was Sie wollen, ist, wenn das Programm nicht mehr funktioniert, geht man in eine Ebene darüber, auf den Desktop und schießt das Programm ab oder so was ähnliches. In jedem Fall können Sie den Computer noch weiter verwenden, weil die Sache, wie man sagt, in genauem Sinn sollte man das noch eindringlicher erläutern, aber der wichtige Begriff in diesem Zusammenhang ist Kapselung. Das was in dem Programm funktioniert als Ensemble von Daten und Abläufen, gehört in dieses Programm und hat keine Auswirkung auf andere Programme, es sei denn, Sie definieren in das Programm hinein, welche Beziehungen das haben kann und sie definieren auch natürlich gewisse Sicherheitsvorkehrungen, was passiert, wenn dieser Austausch nicht funktioniert. Also, Ihr Browser, ich habe das mit dem separaten Audio-Player gesagt, aber ein schöner Fall, wo Sie natürlich wollen, dass eine solche Interaktion stattfindet, ist, dass, wenn Sie ein Movie anschauen wollen im Browser, dann wollen Sie ganz gern noch einen Ton haben. Die Browser stellen keinen Ton zur Verfügung, sondern die Browser brauchen ein Plugin, um den Ton abzuspielen. Und ein Plugin für einen Browser ist nun genau so etwas, ein Programm, das einerseits für sich selber funktioniert, das aber andockt an einer vom Browser vorhergesehenen Stelle, in der die Informationen, die über den Browser kommen, weitergeleitet werden in dieses Plugin, um Ihnen eine Interaktion zwischen diesen beiden Objekten auf Ihrem Desktop zu gestatten. Gehen wir da mal ein bisschen durch... Hier kommen die entsprechenden acht Basiskategorien für das objektorientierte Programmieren zum Ausdruck (8 Basic Concepts of OO): Objects Classes Data abstraction Inheritance Dynamic binding Data encapsulation Polymorphism Message passing

Ich gehe zum Java-Tutorial. C++ ist die Basissprache für Betriebssysteme mit graphischer Oberfläche. Java ist ebenfalls eine objektorientierte Programmiersprache, die aber ein bisschen eine andere Funktion hat. Die ist dazu auch entwickelt, im Netz verteilt und unabhängig von bestimmten einzelnen Betriebssystemen zu operieren. Das heißt, mit Java können Sie ein und das selbe Programm auf Macintosh, Windows oder Unix laufen lassen. Sie brauchen nur in diesem jeweiligen Betriebssystem eine Java Engine. Diese Java Tutorials sind aber sehr schön geschrieben und instruktiv. Hier haben Sie What Is an Object? Gehen wir das vielleicht einmal durch, die ersten drei Absätze, damit Sie in etwa das verstetigen, was ich Ihnen gesagt habe. Objekte sind wesentlich, um objektorientierte Technologie zu verstehen. Schauen Sie um sich, und Sie finden viele Beispiele von Objekten in der wirklichen Welt, ihren Hund, Schreibtisch, Fernseher, Fahrrad, usw. Objekte in der wirklichen Welt haben zwei Charakteristika, sie haben alle einen Zustand (state) und ein Verhalten (behavior). Hunde haben einen Zustand (Name, Farbe, Rasse, hungrig) und sie haben ein Verhalten (bellen, holen gerade irgendetwas, wackeln mit dem Schwanz). Fahrräder haben einen Zustand, der gegenwärtige Gang, in dem sie sind, die Frequenz, mit der sie die Pedale treten, die gegenwärtige Geschwindigkeit und sie haben auch ein Verhalten, nämlich Gangschaltung, Wechseln der Pedalfrequenz und zum Beispiel Bremsen. Indem man den Zustand und das Verhalten von Objekten der wirklichen Welt identifiziert, kann man auf eine sehr gute Art und Weise anfangen, ins objektorientierte Programmieren reinzugehen. Im C++ Tutorial steht für State und Behavior Data und Functions – das ist die frühere Ausdrucksweise diesbezüglich. Ein Objekt hat bestimmte Daten, die mit ihm verbunden sind, also das Datum, welche Farbe hat der Hund oder das Datum, welche Rasse ist der Hund, wie heißt der Hund, das sind sozusagen Informationen, die mit einem Hund verbunden sind – und dann gibt es die Functions, das sind hier die Methoden und die Methoden geben an, was von der Information, die in diesem Objekt steht, manipulierbar ist von Zugriffen und Objekten von außen. Wir sind jetzt hier noch bei den Objekten, aber Sie können sich vorstellen, die Klasse eines Fahrrads oder die Klasse eines Hundes besteht jetzt darin, dass in dieser Klasse festgelegt wird, welche Art von Daten in den Einzelobjekten, die dieser Klasse zugehören, vorkommen. Die Klasse des Hundes sieht vor, dass alle einzelnen Hunde einen Namen, eine Farbe, eine Rasse und einen Zustand (entweder hungrig oder nicht hungrig) haben. Sie sehen von vornherein vor, dass das richtige Weltobjekt Hund, das Sie an dieser Stelle programmieren wollen, dass das einen Zustand hat, dass es hungrig oder nicht hungrig sein kann. In dem Modell selber ist nicht festgelegt, was von den beiden, aber der wirkliche Hund, wenn er nie hungrig ist, ist ja kein wirklicher Hund – d.h. es muss vorgesehen sein die Möglichkeit, hungrig zu sein für den wirklichen Hund. Und es muss vorgesehen sein für den wirklichen Hund, dass er, sagen wir einmal, mit dem Schwanz wackelt. Die Hunde, die wir haben wollen, die können mit dem Schwanz wackeln, auch wenn sie nicht immer mit dem Schwanz wackeln wollen. Hier sehen Sie – ich greife wieder voraus auf das, was ich jetzt schon einmal gesagt habe - ein wichtiges Feature von dieser Art von Konstruktion, das sich nicht ganz deckt, mit dem, was in der Philosophie über Begriffe und Ideen gesagt wird. In der Philosophie wollen wir quasi diskutieren darüber, welche Features in einem Begriff sind wesentlich und welche sind nicht wesentlich – also diese Frage der Wesentlichkeit spielt da eine große Rolle. In der Software-Konstruktion von Klassen von Hunden kann man sagen, was in der Klasse definiert ist, ist wesentlich. Wenn der Hund den Schwanz wedeln kann, dann gehört das wesentlich zum Hund dazu, weil es vorgesehen ist in seiner Konstruktion. Das ist nicht so anders als das was traditionellerweise gesagt worden ist von Gott, der früher wieder – entschuldigen Sie die Vereinfachung - „Die Templates der Dinge sind im Geist Gottes“. Ich habe das im vergangenen Studienjahr in der Vorlesung „Eine Idee haben“ ein bisschen ausgeführt. Das ist sozusagen durchaus hochscholastische Orthodoxie, dass die platonischen Ideen, in denen zusammengefasst ist, worum es bei einem Ding im Wesentlichen geht, in der christlichen Tradition in den Geist Gottes hinein gerutscht sind. Gott hat die Welt in seinen Ideen so und so geplant, und hat die Hunde vorgesehen als Tiere, die bellen. Das ist sozusagen die Garantie in der göttlichen Idee, dass Hunde ein bestimmtes Wesen haben. Man müsste jetzt Gott fragen, ob das Wackeln des Schwanzes mit geplant war oder ob das ein Nebeneffekt war, in jedem Fall aber ist sozusagen diese Konzeption, diese Konstruktion, dass zum Beispiel natürliche Wesen einen Kern von Wesenseigenschaften haben, die garantiert sind durch die Schöpfung, durch die göttliche Idee und die sich in all diesen Wesen finden. Wenn Sie beginnen wollen, darüber zu schmunzeln, dann stellen Sie das Schmunzeln gleich wieder ein – eine Vorstellung wie Menschenrechte ist zum Beispiel eine direkte Konsequenz aus diesen Überlegungen. Menschen haben von Natur aus Rechte. Wenn Sie sich vorstellen, was da dahinter steht, da steht genau diese Idee dahinter, dass Menschen als Menschen auf die Welt kommen, als Wesen, die ein bestimmtes Outfit haben und ein Anrecht auf eine bestimmte Behandlung, auf eine bestimmte Sicht. Menschen sind nun eben keine Dinge, und zwar wesentlich nicht Dinge – und das gehört quasi zum Menschen dazu. Jeder Mensch hat per Konstruktion eine unsterbliche Seele zum Beispiel, oder eine unantastbare Würde oder so etwas Ähnliches. Diese Idee können Sie da durchaus mit hinein sehen in diesen Zusammenhang. Wenn Sie jetzt hier weiter gehen an diesen einen Absatz: Software Objekte sind begrifflich ähnlich wie Objekte der wirklichen Welt, auch sie bestehen aus Zuständen und entsprechendem Verhalten. Ein Objekt speichert seine Zustände in Feldern, das sind Variablen in verschiedenen Programmiersprachen und teilt mit, sein Verhalten durch Methoden, d.h. das sind die Anknüpfungspunkte von außen. Für dieses Objekt sind Verhaltensweisen definiert wie zum Beispiel das Bellen oder das Mit-dem-Schwanz-wackeln, und diese Verhaltensweisen werden nach außen mitgeteilt, sodass Menschen darauf reagieren können, wenn wir beim Hund bleiben. Menschen können reagieren darauf, dass der Hund mit dem Schwanz wackelt. Methoden operieren an dem internen Zustand eines Objektes und dienen als der primäre Mechanismus zur Kommunikation zwischen Objekten, indem man den inneren Zustand verbirgt und alle Interaktionen notwendigerweise durch die Methoden eines Objektes durchführen lässt, installiert man die sogenannte Data Encapsulation (Datenkapselung), was ein fundamentales Prinzip der objektorientierten Programmierung ist. D.h. Sie müssen nicht wissen, wie es im Hund vor sich geht, wenn er mit dem Schwanz wackelt. Sie reagieren auf das Schwanz-wackeln und müssen keine chemische Analyse (oder Ähnliches) über den internen Zustand dieses Hundes machen. Wenn er hungrig ist, brauchen Sie keine Kenntnis davon, wie es in seinem Verdauungstrakt ausschaut, sondern die Zeichen des Hungrigseins sind seine Methode, Sie darauf aufmerksam zu machen, dass Sie mit ihm in gewisser Weise interagieren sollten.

Ich gehe dann noch kurz auf die nächste Seite für die Klassen, nur um Ihnen ansatzweise ein bisschen die Angst zu nehmen vor dieser Art von Konstrukten. Ich denke, dass was ich Ihnen bisher gesagt habe, hat noch nicht wirklich die Auffassungsgabe überfordert. Der erste Schritt, um sich klarzumachen, wie sowas in Java zum Beispiel aussieht, im Zusammenhang mit dem Fahrrad ist das und das überfordert die Auffassungsgabe genauso wenig, würde ich sagen. Das ist einfach die Definition einer Klasse in Java, die Klasse Bicycle, ausgehend von dem, was ich Ihnen gesagt habe, int steht einfach für internal states - cadence, speed, gear - das Softwarekonstrukt Fahrrad hat einen Gang, eine Geschwindigkeit und eine Frequenz, mit der es getreten wird. Das sind interne Zustände, die das Fahrrad für sich behält und nicht an die Öffentlichkeit mitteilt sozusagen, sie können auf das nicht direkt zugreifen. Was Sie können ist, durch Methoden auf diese internen States zugreifen, um diese internen States zu ändern aufgrund einer Change-Funktion. Hier haben Sie die entsprechenden Change-Funktionen, das ist changeCadence, changeGear, speedUp, applyBrakes – sozusagen ein Anfangs-Tutorial und entsprechend verständlich. Nehmen wir ChangeGear (da ist es sozusagen am Einfachsten): Sagen wir, das ist ein 5-Gang-Fahrrad, das Fahrrad ist im ersten Gang, Sie geben ein, gear = 3 und der Wert der Funktion changeGear ergibt, dass der interne neue Wert gleich ist dem neuen Wert, sozusagen komplett banal. Wenn diese Methode korrekt durchgeführt ist, steht dann in dem Programm hier statt 1 3 und das Fahrrad ist im 3. Gang und Sie haben damit modelliert, was passiert, wenn Sie mit dem Fahrrad die Gangschaltung betätigen. Also so viel für Dummies wie mich zum Beispiel auch. Hier haben Sie, das ist ein Zeichen einer Programmiersprache, sie müssen immer genau definieren in welchem Bereich bestimmte Variablen gültig sind, wo das dann aufhört, die Klammern separieren die jeweiligen Einzelmethoden voneinander, der Strichpunkt separiert die Angaben der einzelnen States zueinander. Genauer gehe ich nicht ein auf diese Sachen, das wäre in Wirklichkeit ein anderes Projekt. Es gibt ein paar Leute vielleicht, merke ich beim Mitlesen der Wiki-Kommentare, die sich damit viel besser auskennen als ich, die lade ich herzlich ein, das zu korrigieren, mir ein bisschen zu helfen und das auch noch ein bisschen weiter zu entwickeln. Zweitens kriegen Sie ja vielleicht auch manchmal so ein bisschen eine Lust, sich mit dieser Sache zu beschäftigen. Damit will ich es mit diesem absolut oberflächlichen Blick auf die Objektorientierung erstmals bewenden lassen, allerdings habe ich noch etwas in Planung.

Platon platonisch

Das ist jetzt das, womit ich mich schon noch ein bisschen auseinandersetzen möchte, auch sozusagen passt es gut zu Weihnachten als der Zeit der Spiele und des ein bisschen Herumprobierens. Und allein schon deswegen muss ich mir das leisten, weil es mit Tätigkeiten von mir und von Studenten von mir seit einigen Jahren doch ganz eng zusammenhängt, und weil, wenn man von objektorientierter Programmierung und Platon redet, es eigentlich nicht möglich ist, Sie nicht auf ein paar von diesen Dingen aufmerksam zu machen. Worum handelt es sich? Wir haben im Studienjahr 2008/09 ein Projektseminar gemacht, das hat als Ziel gehabt, sich mit Platons Politeia zu beschäftigen und zwar im Zusammenhang damit, dass wir aus Teilen zumindest von Platons Politeia ein interaktives Text-Adventure gestalten wollten, das mit einer objektorientierten Sprache geschrieben ist. Das ist die allgemeine Kurzfassung. Ich gebe Ihnen einmal die Release-Seite davon, das ist das, womit wir dann bis zum Ende gekommen sind, das Projekt selber können Sie im Wiki auch alles nachverfolgen, wenn Sie wollen und Zeit haben, es ist sozusagen durchaus Spaghetticode-mäßig vom Wiki her durchgeführt worden. Da haben wir uns überhaupt nicht leicht getan. Die wichtige Sache, die ich Ihnen zeigen will, ist die folgende: Was ist interaktives Text-Adventure, so beginne ich vielleicht einmal. Wenn Sie sich an die Sache ein bisschen heran arbeiten wollen, steht (die Basisinformation) auf dieser Seite alles (http://inform7.com/learn/manuals/). Wenn Sie nichts von dem haben wollen, sondern sich nur ein bisschen umschauen, worum es da geht, dann haben Sie das Spiel hier online. Es ist ein Google-Service, das es gestattet, online interaktive Text-Adventures darzustellen. Was sind interaktive Text-Adventures? Das kommt aus der Frühzeit des Umgangs mit Computern und zwar ganz ausgesprochen aus der Zeit, in der die Kommandozeile noch das Wichtige war. Wenn Sie sich erinnern, das ist die Zeit, wo die Männer noch die wirklichen Männer waren und die Frauen die wirklichen Frauen, und Programmierer waren die, die mit der Kommandozeile operieren konnten und aus dieser Zeit kommt das noch. Das hat für mich eine besondere Attraktivität gehabt, weil ich schon ein bisschen eine sentimentale Neigung zur Kommandozeile habe, nicht deswegen, weil ich so gut Programmieren konnte, sondern deswegen, weil sozusagen der Bruch dazwischen, dass man noch einigermaßen nachvollziehen kann, was man tut, wenn man mit seinen Fingern da hinein tippt, und dem, dass man sich überliefert dem Ablauf eines Feuerwerks von Gadgets, die in der graphischen Benutzeroberfläche alle auf Sie zukommen – weil dieser Bruch für mich doch sehr wichtig ist und ich noch in der Generation bin, angefangen zu haben, bevor es ganz unvermeidlich schien, dass es nämlich eine graphische Oberfläche gibt. Um Sie nur an einer kurzen Stelle darauf hinzuweisen, ich habe auf DOS und Windows 3.1 hingewiesen, in dem Verhältnis von DOS und Windows 3.1 ist noch drinnen gewesen, Sie müssen zuerst DOS starten, dann kriegen Sie einen schwarzen Schirm und sowas, was blinkt, und dann müssen Sie Windows starten und dann kommt drüber die Windows-Oberfläche und wenn die abstürzt, können Sie wieder zu DOS – das war die Frühzeit. Ab einem gewissen Zeitpunkt gab es das nicht mehr, sondern es ist Windows von Vornherein als graphisches Programm gestartet worden, unter Microsoft Windows haben Sie keinen Ausweg, Sie müssen Ihre graphische Sache hochfahren und das so behandeln, wie das Microsoft will. Sie sind an dieser Stelle sozusagen im Käfig des graphischen Betriebssystems. In jedem Fall haben Sie eine einfache Tastenkombination unter Linux – ganz zu schweigen, dass Sie hier drinnen in der graphischen Benutzeroberfläche auch kommandozeilen-operiert arbeiten können. Die graphische Welt unter einem Unix-Betriebssystem ist separiert von einem Betriebssystem selber, da ist also dieser Bruch noch drinnen. Das war jetzt nur zur Illustration, warum ich eine gewisse sentimentale Neigung zur Kommandozeile habe.

Interaktive Text-Adventures schauen jetzt so aus, dass Sie eine Kommandozeile bekommen und in dieser Kommandozeile geben Sie etwas ein. Und das Programm, mit dem Sie da jetzt operieren, antwortet auf Ihren Input bei der Kommandozeile auf irgendeine Art und Weise. Bei unserem Spiel ist der Einstiegspunkt: „Danubia Park Entrance: This is the spot where it all begins. You can search for adventure in all directions. Or return to the real world. You can go outside to the real world or east to Snow White's Scary Adventures.“ Danubia Park Entrance ist sozusagen der Prater, den wir da programmiert haben. Schauen wir uns einmal Schneewittchen an, indem wir nach Osten gehen >east. Sie sehen dann den Text: „Snow White's Scary Adventures: Of course you remember the story of the charming little princess saved from the evil deeds of her wicked step-mother, the queen, by a group of seven adorable dwarfs living in the seven mountains. And you recall the queen disguising herself as an old peddler woman, visiting Snow White in the woods. She was pulling her laces so tight that Snow-White could not breathe and almost died. What a moving story, but you know the outcome and you'd like to try something different. You can go west to Danubia Park Entrance, east to the Seven Dwarves Mine, north to Winnie the Pooh's 'Playful Spot', northeast to the candy floss stand or inside Snow White's Scary Adventures.“ Das Spiel kommt ohne jede zusätzliche Belästigung aus, indem Sie beispielsweise Software installieren müssten oder so Ähnliches. Was Sie aus diesem Beispiel entnehmen können, ist jetzt das Folgende: Das sind einfach Texte, Textbeschreibungen und es gibt genügend Programme für interaktive Fiktion, die mit Hilfe von Spaghetticode Ihnen ganz einfach auf bestimmte Inputs Textbeschreibungen ausspucken. Sie geben etwas ein und eine Textbeschreibung wird ausgespuckt. Sie können sich ein relativ komplexes Spiel vorstellen, wo das ein bisschen so ausschaut wie diese Afghanistan-Skizze, wo auf geordnete Art und Weise, was immer da reingegeben werden kann, beantwortet wird mit einem Computer-Output, was sozusagen einfach nur ein Junk von Text ist. Der nächste Schritt ist aber der, und wollen wir einmal folgendes probieren: hier wird gesagt, ich kann das und das und das machen, ich weiß aber als ein Spieler von interaktiven Adventures, dass mir eine Anzahl von Kommandos zur Verfügung steht. Eines der Kommandos ist examine (abgekürzt mit x), und examine wird in diesem Kontext angewendet, um sich irgendein Ding genauer anzuschauen. Was ich mir anschaue ist natürlich, wovon mir gesagt wird, dass es das gibt. Die Situation ist jetzt die, dass ich in dem Spiel in einer bestimmten Position bin und die Kommandos dieses Spiels auf eine bestimmte Art und Weise anwenden kann, und die Logik, die dahinter ist, wenn ich diese Kommandos auf bestimmte Bestandteile des Textes und des Spieles anwende, dieses Logik sollte jetzt, wenn es sich nicht in den Spaghetticode total verliert, sollte eine Logik sein, die nach der wirklichen Welt orientiert ist. Wenn da beschrieben wird, dass es ein Ding gibt, dann schaue ich mir das Ding an, das beschrieben wird, und wenn es das Ding nicht gibt, dann soll zum Beispiel nicht gesagt werden Fehler 27, sondern dann soll eine Antwort kommen, die darauf angelegt ist, dass ich in der Logik meines Schau-Dir-an (examine), schon drin stehen habe, ich will mir ein Objekt anschauen. Also, examine entrance heißt, ich gehe aus davon, dass ich in der Welt ein Objekt habe, und dieses Objekt ist ein Eingang und diesen Eingang will ich genauer beschrieben wissen. Wenn es dieses Objekt nicht gibt in der Welt, dann kriege ich eine Antwort, nicht irgendeine Fehlermeldung, sondern als Antwort kriege ich hier „you can't see such a thing“ - und das impliziert, dass das Programm schon weiß, ich habe etwas anschauen wollen, ich erwarte jetzt die Beschreibung eines Dinges und dieses Ding ist aber nicht da. Das sind jetzt Strukturen, die in dem Programm schon drinnen sind und die die Bewegung innerhalb der simulierten Welt – die da drinnen ist – steuern. Etwas, was ebenfalls in dem Programm drinnen ist, ist die Geographie, die Möglichkeit, nach Osten, Westen, usw. zu gehen.

Was ich Ihnen damit andeutungsweise nur im ersten Gusto sozusagen sagen wollte, dass im Hintergrund von diesem Spiel, das wir gemacht haben, eine Programmiersprache steht, die in diesem Fall Inform 7 heißt. Worum es jetzt geht – und das nächste Mal gehe ich ein bisschen in die Details, um Ihnen das zu zeigen – ist, dass Inform 7 eine Programmiersprache ist, die es Ihnen möglich macht, Standard-Englisch zu verwenden, um die Implikationen der wirklichen Welt, die Sie in unserer Englischen Sprache haben, diese Implikationen in der Spielwelt, in der simulierten Welt, ganz einfach automatisch umzusetzen. Um es auf die banalste Art und Weise zu sagen, Sie haben das Java-Code Fragment gesehen über das Bicycle – Sie können in Inform hinschreiben: „Bicycle is a kind of thing. Bicylce has gears and speed.“. Das schreiben Sie einfach in normalem Englisch hin, die Inform-Umgebung kompiliert das im Hintergrund zu einer digitalen Welt und gibt Ihnen sozusagen die Möglichkeit, aufgrund Ihrer objektorientierten Formulierungen eine Welt von Objekten und Ihren Interaktionen zu gestalten zum Zweck eines Spiels, mit dem Sie sich beschäftigen können. Ich zeige Ihnen das auf die einfachste Art und Weise. Etwas was das Programm einfach dadurch zuwege bringt, dass Sie sagen, „Danubia park entrance is a room“, das ist ein Name und das ist eine Beschreibung, room ist an der Stelle eine Klasse. Im Programm ist für interaktive Fiktion bereits vorgesehen, es gibt ein Template für einen Raum, Räume haben bestimmte Eigenschaften, Sie können diese Klasse Raum aufrufen, um zu sagen, eine Instanz von dieser Klasse ist Danubia Entrance, das brauchen Sie nur mehr sozusagen zu bestellen. Was das Programm macht ist, es erzeugt einen Raum mit bestimmten Eigenschaften, zum Beispiel eine der Eigenschaften, die ein Raum in der Regel hat ist, ein Raum kann beleuchet oder nicht beleuchtet sein, d.h. sie sehen in dem Raum nichts oder sie sehen etwas. Normalerweise ist der Raum beleuchtet, Räume haben es wesentlich an sich, dass sie sozusagen beleuchtet sind und in dem Moment, in dem Sie einen solchen Raum bestellt haben – Danubia Park Entrance – erzeugt er Ihnen eine bestimmte Softwarekonstruktion, die in der Landkarte, die für dieses Spiel gemacht wird, hier zugleich am Anfang steht (Danubia Park Entrance – Room where play begins). Und in diesem Raum bist du selbst als diese Person und dieser Danubia Park Entrance ist nun verbunden in der Logik dieses Spiels mit anderen Räumen, die Sie definiert haben, Sie haben Snow White's Scary Adventures, das ist das, was Sie hier definieren, „Snow White's Scary Adventures is an Entrance“, also entrance ist ebenfalls eine vorgegebene Klasse in diesem Spiel – das werde ich Ihnen das nächste Mal noch etwas näher sagen – sie haben sozusagen alles, was Sie brauchen, um schöne Spiele spielen zu können softwaremäßig schon mal vorgegeben. Und diese Entrance zu dem Snowwhite wird automatisch in der Landkarte hinzugefügt. Ich werde das nächste Mal nicht mit dem Spiel beginnen, das vergleichsweise komplex ist. Um die simplen Sachen Ihnen zu zeigen, werde ich mich beziehen auf das Modell, das Andreas Kirchner gemacht hat von einem Buch. Da kann man es dann vielleicht ein bisschen durchsichtiger sehen, wie so etwas funktioniert. Die Sachen, die ich gesagt habe über den Tisch, was der Tisch so alles hat, werden Sie da wiederfinden als die Frage, was braucht man eigentlich für ein Buch, welche Eigenschaften wollen wir für ein Buch genau definiert haben und da können wir uns an diesem speziellen Fall auch genau ansehen, wie so etwas aussieht. Das ist sozusagen ein in Inform modelliertes Buchmodell.

Terminologie im Vergleich

Die Terminologie hat mich immer ein bißchen verwirrt, weil anscheinend in verschiedenen Sprachen unterschiedliche Bezeichnungen für die selben Konzepte üblich sind. Ich habe einmal versucht, die Entsprechungen nach dem Java-Tutorial tabellarisch aufzustellen:

objektorientierte Sprachen	andere Sprachen	Inform7	Erläuterung	Beispiel
class	–	kind	(Begriff, Typus, Kategorie)	"bicycle" (Fahrrad)
object	–	object	(Gegenstand, Objekt)	"my bike" (mein Fahrrad)
field/variable	variable	property?	(Eigenschaft)	"gear" (Gang), "speed" (Geschwindigkeit)
value	value	value(?)	"state" (Zustand)	(Gang =) 5, (Geschwindigkeit (in km/h) =) 18
method	function	activity?	"behavior" (Verhalten), Tätigkeit	"change gears" (Gang (um)schalten), "speed up" (Beschleunigen)
	procedure

Wobei ich mich zunächst auf die Bezeichnungen konzentriert habe, die im Java-Tutorial vorkommen. Was micht beschäftigt hat, als ich die Tabelle angelegt hatte: Gibt es einen Unterschied zwischen "method" und "function" und zwischen "field" und "variable" oder ist das einfach eine Terminologiefrage? --H.A.L. 18:35, 17. Dez. 2010 (UTC)

Der Begriff der Funktion ist der Mathematik entlehnt, und verlangt, dass es einen Rückgabewert gibt. Eine Prozedur (hier nicht genannt) muss nicht notwendigerweise einen Rückgabewert haben, sie führt einfach eine Reihe von Befehlen aus. In Java ist beides unter dem Konzept der Methode vereint, die einen Rückgabewert haben kann, aber nicht muss (-> void). Eine Methode versteht man im OO-Paradigma als Manipulation ihres zugehörigen Objekts, d.h. i.A. verändert (oder liest) sie den Status des Objekts. [Ich hab die Tabelle ein bisschen umgeschrieben und 2 Spalten zusammengelegt, ich hoffe, das ist okay.]--Realgeizt 23:49, 25. Dez. 2010 (UTC)

• Das ist schon mal wichtig: Ich hatte die ganze Zeit gedacht, daß die anderen Sprachen, von denen das Java-Tutorial spricht, andere objektorientierte Sprachen sind. Deshalb hatte ich die erste Spalte "Java" genannt. Wichtig festzuhalten, daß das ungefähr die Terminologie der objektorientierten Sprachen allgemein ist.
• Ich habe festgehalten, daß "function" und "procedure" nicht dasselbe ist, daß aber "method" beides umfaßt / ersetzt. Wegen solcher Feinheiten habe ich die Tabelle angelegt.
• Unter "field/variable" stand "Gang umschalten", aber das ist ja eine Methode.
• Die Tabelle war nicht zuletzt als Kommentar zum Java-Tutorial gedacht, deshalb waren mir die dort verwendeten Ausdrücke wichtig.

• In der Einführung in Objekte taucht die Formulierung "Change gears" auf (siehe Diagramm dort), im Code-Beispiel heißt es dann "setGear(int newValue)". Ich hab mich mal an die umgangssprachlichen Schreibungen gehalten.

• Ich wollte eigentlich den philosophischen Diskurs als eine zusätzliche Entsprechung dazunehmen. Das ist aber hinfällig aufgrund der Pointe, daß das Begriff-Gegenstand-Verhältnis eben nicht genauso funktioniert wie das zwischen Objekt und Klasse.
• Das Java-Tutorial nennt konsequent die field-Zeile vor der method-Zeile. Was auch irgendwo Sinn macht, denn ich brauche ja erst eine Gear-Variable, bevor ich sie ändern kann.
• Ansonsten sagt mir mein Stilgefühl, daß man üblicherweise die Erläuterung vor dem Beispiel bringt. --H.A.L. 13:47, 18. Jan. 2011 (UTC)

"wesentlich"

Diese Art von Konstruktion in der Softwareentwicklung deckt sich nicht ganz mit dem, was in der Philosophie über Begriffe und Ideen gesagt wird. In der Philosophie wollen wir darüber diskutieren, welche Features in einem Begriff wesentlich und welche nicht wesentlich sind. Diese Frage der Wesentlichkeit spielt in der Philosophie eine große Rolle. In der Softwarekonstruktion von Klassen von Hunden kann man hingegen sagen, dass alles was in einer Klasse definiert ist, auch wesentlich ist. Wenn der Hund mit dem Schwanz wedeln kann, dann gehört das wesentlich zum Hund dazu, weil es in seiner Konstruktion eben so vorgesehen ist.

Meine erste Reaktion darauf war: Ja, aber in der Software wird von vornherein nur das implementiert, was wesentlich ist. Und zwar wesentlich in Bezug darauf, was ich mit der Software anfangen will. Wenn ich das Fahrrad programmiere, um damit durch eine Stadtsimulation zu fahren, ist vielleicht das Wichtigste, daß aus dem Gang und der Trittfrequenz die Geschwindigkeit berechnet wird. Wenn ich aber Grand Theft Bicycle programmiere und das Fahrrad dazu da ist, gestohlen zu werden, dann sind vielleicht der Preis und die Seriennummer am wichtigsten.

Dabei fällt aber zunächst auf, daß ich von vornherein von den "wichtigsten" Eigenschaften geredet habe. In der Stadtsimulation wären "lenken" und "Geschwindigkeit regeln" das, worum es bei einem Fahrrad im Kern geht, aber in einem detaillierten Programm hätte es außerdem ein Licht und eine Klingel und so weiter. - Auch im wirklichen Leben baut man Fahrräder, um sich damit fortzubewegen, und trotzdem werden sie so konstruiert, daß man damit auch Geräusche machen kann. - Das liegt natürlich daran, daß ein Fahrrad ein Werkzeug ist. - Wie fragt man also nach dem "Wesen" von etwas, das nicht zu einem bestimmten Zweck gemacht wird?

Warum gibt es Hunde? (Warum hat Gott die Klasse "Hund" spezifiziert?) - Warum gibt es den Begriff Hund? (Warum haben wir die Klasse spezifiziert?) - Wenn wir nach einem Begriff fragen, können wir fragen: Warum ist uns ein Set von Features so wichtig, daß wir dafür ein eigenes Wort verwenden?

Desmond Morris definiert in seinem Buch "der nackte Affe" den Menschen als einen weitgehend haarlosen Primaten. Er führt dazu aus, daß es in einer ganzen Reihe von Subklassen der Säugetiere einzelne Arten ohne Fell gibt, wie zum Beispiel bei den Sandgräbern innerhalb der Nagetiere den Nacktmull. Und da bei den Primaten nur eine einzige haarlose Art bekannt ist, braucht man sie nicht näher zu spezifizieren. Damit will Morris demonstrieren, daß der Mensch einer gewöhnlichen zoologischen Untersuchung zugänglich ist. Ein Philosoph kann darauf entgegnen: Damit hast du zwar den Menschen eindeutig definiert, aber diese Bestimmung sagt mir nicht, warum über Menschen so viel mehr nachgedacht wird als über Nacktmulle. Was den Menschen eindeutig von allen Objekten unterscheidet, die keine Menschen sind, ist noch nicht unbedingt das, was Menschen so besonders macht.

(Wobei aber natürlich Morris' Definition schon insofern nicht "wesentlich" ist, als er nicht ausschließt, daß wir einmal einen nackten Primaten entdecken, den wir nicht als Mensch klassifizieren.)

Vielleicht ist der Unterschied zwischen der Konstruktion von Software und von Begriffen nur, daß wir als Programmiererinnen selbst Gott sind, während wir uns als Philosophen mit einer Welt herumschlagen müssen, die wir nicht durchschauen. In einer Softwarekomponente implementieren wir ein Feature nur, nachdem wir es für relevant erklärt haben. (Wenn wir entsprechend darüber nachdenken. Wenn wir eher drauflosprogrammieren, kann es passieren, daß wir eine Eigenschaft schreiben und dann feststellen, daß wir sie gar nicht brauchen.)

Noch ein Nachtrag: Wir haben um der Anschaulichkeit willen nur Klassen besprochen, die handgreifliche Dinge simulieren, wie Fahrräder oder Bücher. Das kann unsere Vorstellungen beeinflussen. Von einem simulierten Fahrrad kann ich sagen, daß ihm gewisse Eigenschaften "fehlen", die ein richtiges Fahrrad hat. Nicht jede Softwarekomponente simuliert aber etwas anderes. Eine Softwarekomponente ist zunächst ("wesentlich") nur ein Tool, das einen bestimmten Zweck erfüllt. Das heißt, daß ein Objekt nicht unbedingt in diesem Sinn mit einem "richtigen" Objekt vergleichbar ist, von der es Eigenschaften übernimmt.

--H.A.L. 20:29, 17. Dez. 2010 (UTC)

noch ein Nachtrag

(Hier versuche ich hauptsächlich, das, was ich in Objekt und Klasse, Gegenstand und Begriff (CP) und der Diskussion dazu aufgenommen habe, in meine Perspektive an dieser Stelle zu übersetzen.)

Nachdem ich Objekt und Klasse, Gegenstand und Begriff (CP) gelesen hatte, war mir viel klarer, wovon hier die Rede ist. Um das dort Gesagte auf meine Notiz anzuwenden: Zunächst ist auf der Begriff-Gegenstand-Seite nicht nur die Zuordnung eines Gegenstands zum Begriff fraglich, sondern auch der Begriff selbst. Wir fragen uns ständig auch, was ein Hund eigentlich ist, das heißt, welche Kriterien ausschlaggebend sind, einen Gegenstand dem Begriff „Hund“ zuzuordnen. Insofern fragen wir uns, welche Kriterien für einen Begriff „wesentlich“ sind. In einem Softwareobjekt gibt es keine wesentlichen oder unwesentlichen Eigenschaften. Eigenschaften sind einfach implementiert.

In der Softwareentwicklung überkreuzen sich beide Perspektiven. Der Computer fragt nicht nach wesentlichen oder unwesentlichen Eigenschaften. Allerdings ist eine Softwarekomponente von Menschen implementiert, und jede Eigenschaft, die sie hat, wurde (hoffentlich) implementiert, weil sie wichtig ist.

Über die Softwareentwicklung wurde im Anschluß an den Aufsatz bereits diskutiert. Eine Feststellung dabei ist, daß ein Implementationsprozeß einhergeht mit einem Erkenntnisprozeß über das zu implementierende Ding. Wenn ich einen Hund implementiere, muß ich mich fragen, was an einem Hund wesentlich ist. Das ist aber nicht ganz genau. Ich muß mich fragen, was an einem Hund wesentlich in Bezug auf meine Simulation ist.

Ich dachte zunächst, daß das nur auf Softwarekomponenten zutrifft, die Gegenstände der Außenwelt simulieren, aber das Prinzip läßt sich wohl zumindest sinngemäß auf jede Art Softwareobjekt übertragen; will sagen, daß ein Erkenntnisprozeß auch stattfindet, wenn die Software nichts simulieren soll. Wenn ich ein Tool programmiere, das eine Aufgabe erfüllen soll, muß ich mir klar werden darüber, wie ein (hypothetisches) Objekt beschaffen ist, das das tut, was die Komponente tun soll. Die Implementierung einer simulierenden Komponente beinhaltet einen Erkenntnisprozeß über den Gegenstand in der Außenwelt; das Modellieren einer Softwarekomponente ohne Vorbild beinhaltet sozusagen einen Erkenntnisprozeß über den Gegenstand in meinem Kopf.

--H.A.L. 23:55, 22. Jan. 2011 (UTC)