Benutzer: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>

Cyberplatonismus. VO 9 vom 10.12.2010

Überleitung (Fortsetzung)

siehe auch: Überleitung_(CP), Diskussion:Überleitung_(CP)

Philoumenos am Jakobsbrunnen

Ikonifizierte Darstellung

Update zu Bruder Philoumenos - Real Life Fotografie und Ikone

Zu dem von mir das letzte Mal hier diskutierten Bild, Kontrast, den ich aus Brünn mitgebracht habe, hat ein Kollege in der letzten Nacht einen Beitrag verfasst. Allerdings ist das nicht einfach ein Beitrag, sondern ein Eye Opener, eine unglaubliche zusätzliche Ergänzung, die ich Ihnen kurz vorstellen möchte - vor allem deswegen, weil es an wichtigen Stellen ergänzt und erweitert, was ich im Zusammenhang mit Herrn Chrysanthos dargestellt habe. Es sei mir auch gestattet darauf vorzugreifen, was ich heute und das nächste Mal thematisieren 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, die ich von Chrysanthos übernommen habe, den Anschein erweckt, dass es sich hier um zwei gleichformatige Bilder handelt, abstrahiert von sämtlichem Kontext. Ich habe mich an dieser Stelle zu einigen ein bisschen naseweisen Vermutungen verleiten lassen, ohne in den Kontext genauer hineinzuschauen. Auf den Zusammenhang zwischen Kübel und Amphore zu verweisen, war noch nicht naseweis, allerdings lässt sich aus einer genaueren Kenntnis der Geschichte nicht aufrecht erhalten, dass es sich im linken Bild um ein Treppengeländer handelt. Und dass dieses Treppengeländer das Kreuz symbolisiert, ist nachgerade unverteidigbar, wie Sie gleich sehen werden. Ein Mithörer unter den Anwesenden in dieser Lehrveranstaltung, der mit der Sache vertraut ist, hat uns darauf aufmerksam gemacht, was eigentlich der Kontext von dem Ganzen ist (nachzulesen unter Diskussion:Überleitung_(CP)).

Warum ist dieser Bruder Archimandrite Philoumenos ein Heiliger? Er ist ein orthodoxer Bruder, der ein Mitglied des Ordens für die Bewahrung des heiligen Grabes (Brotherhood of the Holy Sepulchre) ist. Philoumenos war an einer Stelle auf der West Bank stationiert, wo einst der Ort Sichem gelegen ist. Über diesen Ort Sichem findet sich zwei biblische Belege, in jedem Fall gibt es dort den berühmten Jakobsbrunnen. Der Jakobsbrunnen ist die Szenerie einer Begegnung Jesu mit einer samaritischen Frau im Neuen Testament - eine Szene, wo es darum geht, dass, so wie der Jakobsbrunnen Wasser spendet, Jesus selbst das lebendige Wasser ist. Diese Lokalität besteht seit dem vierten nachchristlichen Jahrhundert und der Orden, der hier genannt ist, wacht über diesen heiligen Ort. An Stelle der zerstörten Kirche wird eine neue Kirche erst im Jahre 2007 fertiggestellt. 1979 wird der Bruder Philoumenos offensichtlich von fanatischen Zionisten an diesem Ort erschlagen, in einem grauenvollen Ritual, das ihm sozusagen kreuzweise den Körper zerlegt hat. Das ist auch der Grund, warum Philoumenos heilig gesprochen worden ist.

Der Kollege Mi5er führt auf der Diskussionsseite eine ganz eindrucksvolle Dokumentation der Ereignisse an, eine Bildwelt in Gegenüberstellungen zwischen Fotos, Abbildungen und Ikonen. Daraus ergibt sich einiges, das ich nachlässigerweise entweder nicht gesagt oder gar nicht bedacht habe. Eine der Nachlässigkeiten bezieht sich auf die Konstellation auf dem linken Foto der Gegenüberstellung, die den Jakobsbrunnen und nicht ein Stiegenhaus darstellt. Besonders interessant ist die Kontextualisierung von dem, womit wir bisher operiert haben. Der Hinweis, der hier gemacht wird, ist, dass in diesem Foto die Real Life Fotografie schon viel deutlicher gesehen und bereits als eingebettet in einem Heiligenverständnis gezeigt wird. Es verhält sich daher nicht so, wie ich das dargestellt habe oder wie man es oberflächlich sehen könnte, dass eine Person aus dem normalen Leben dann nachträglich in den Heiligenbereich versetzt wird. Ich habe die Sache letztes Mal so dargestellt, als ob auch hunderte Fotos dieser Person nichts davon enthalten würden, dass diese ein Heiliger ist. Das Heilige wäre demnach eine Qualität, die sozusagen im Nachhinein darüber gestülpt wird.

Im Gegensatz dazu bewegen sich Personen schon im gewöhnlichen Leben so, dass sie unter anderem Ikonen werden können. Aus der katholischen Tradition heraus gesprochen gibt es bereits eine Vorstellung von Heiligtum, verkörpert durch fromme Personen, die sich in der Kirche schon entsprechend angelisch oder so wie in Heiligenbildern dargestellt verhalten - sozusagen Anverwandlungen an die Bilder der Heiligen, auch in ihrer aktuellen Körperhaltung. Das ist schon mal ein Hinweis darauf, dass es hier eine andere, eine untergründige oder nicht so untergründige Exchange Funktion von der Idealisierung in das Leben und vom Leben in die Idealisierung hinein gibt. Beide Seiten sind bereits aufeinander abgestimmt. Auf der Diskussionsseite zum Thema Überleitung haben Sie Ikonen, die ganz offensichtlich im Nachhinein ikonifizierte Darstellungen sind. Eine Ikonendarstellung zeigt den Heiligen Philoumenos - hier mit Brille abgebildet - wobei dessen Name in der Ikonenüberschrift angeführt ist. Der Text über die Entzifferung ist ausgesprochen gehaltvoll, und zugleich nobel genug mich nicht direkt zu attackieren, obwohl er das Recht dazu hätte. Vor allem ist es eine gute Interpretation dessen, warum Philoumenos ein Kreuz in der Hand hält.

Instantiierung der Heiligenhaftigkeit in einer Einzelperson

Daran anknüpfend möchte ich das auch schon vorwegnehmend mit Absichten verbinden, die ich in der heutigen und nächsten Stunde verfolgen werde. Um ganz ungeniert mit zwei informationstechnischen Begriffen zu beginnen: Die Basiskategorien in der objektorientierten Programmierung sind Klassen und Objekte (Instantiierungen von Klassen). Klassen sind quasi schematische Vorgaben, die in abstrakter Form alles das beschreiben, was im Prinzip zu Objekten gehört, die aber selbst keine Objekte sind, sondern sogenannte Object Factories – das sind Modellvorstellungen (Patterns), die instantiiert werden, wodurch einzelne wirkliche Objekte entstehen. Das ist, stark verkürzt dargestellt, vergleichbar mit dem Folgenden: Sie haben die Idee des Pferdes, zu der gehört, dass ein Pferd ein Tier ist, vier Beine hat, dass es wiehert, einen Schwanz hat, usw. Neben dieser Idee des Pferdes gibt es dann wirkliche Pferde, die Realisierungen der Idee des Pferdes sind. Das ist totaler Vulgär-Platonismus, aber zugleich eine faire Beschreibung dessen, was als Grundlage für die objektorientierte Programmierung betrachtet werden kann. Im Programmieren soll man nicht mit bestimmten Verfahrensanweisungen dem Computer Befehle geben, diese auf eine raffinierte Weise ineinander schachteln und sequenzieren, sondern es ist sinnvoll, ein objektorientiertes Paradigma zu wählen und mit den zwei wichtigsten Basiskategorien Klasse und Objekt zu operieren. Objekte in der Software entsprechen Objekten der wirklichen Welt. Sie sind dadurch charakterisiert, dass sie eine Idee verwirklichen, noch einmal betont, auf einer ganz vulgären Ebene.

Nehmen wir zum Beispiel an, jemand braucht einen Tisch. Diese Person weiß noch nicht, wie der Tisch aussehen soll. Sie braucht einen Tisch, weil sie etwas haben möchte, worauf sie ihr Frühstück stellen kann, das heißt, etwas mit Platte, erhöht vom Boden, belastbar, usw. Sagt diese Person A nun zu einer anderen Person B „bitte bring mir einen Tisch“, dann geht A davon aus, dass B ihr einen Tisch bringt, wobei keine weiteren Angaben bezüglich Farbe, etc. gemacht werden. Durch unsere Kommunikationssituation weiß Person B, worum es geht, sie wird irgendwo Ausschau halten nach einem Tisch, geht beispielsweise in den nächsten Raum und findet dort aufgrund der Kenntnis, der Kompetenz, die sie hat, jenen Gegenstand, der ein Tisch ist und bringt diesen Tisch her. Worin besteht diese Kompetenz, die Person B in die Lage versetzt, den Tisch herzubringen? Sie weiß im Prinzip um die Haupteigenschaften eines Tisches und aufgrund dieser Kompetenz des Umgangs mit den Haupteigenschaften - was wir, wie gesagt ein bisschen banalisierend den Begriff, die Idee des Tisches nennen - ist es möglich, dass Person B im Nebenraum einen Einzeltisch, der dort steht, als ein Beispiel eines Tisches, eine Instanz eines Tisches erkennt und diese dann mitnimmt. Wie dieses Muster einer doppelten Funktionalität weiter verhandelt wird– nämlich dass wir auf der einen Seite ein Feature Set haben, nämlich Eigenschaften, die wir zusammenfassen als so etwas von der Art, und so etwas von der Art kommt in Einzeldingen vor -, werden wir uns noch genauer ansehen.

Warum ich diesen Punkt hier im Kommentar zu Philoumenos erwähne hat damit zu tun, 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 darauf verwiesen habe, dass es da die Heiligkeit gibt, und diese wird instantiiert in einem Menschen. Ich habe auch argumentiert, dass die Heiligkeit an dieser Stelle kein abstrakter unsichtbarer Begriff ist, sondern dass das Typus der Heiligkeit selbst eine bestimmte Gestalt, die Ikonengestalt hat, in der die Heiligenhaftigkeit greifbar ist. Diese Heiligenhaftigkeit wird sozusagen in einer einzelnen Person umgesetzt. Worum es da geht, wenn wir einer Person Heiligkeit zusprechen, kann man durchaus als eine objektorientierte Betrachtungsweise bezeichnen. Wenn wir einem Ding zusprechen, dass es ein Pferd ist, dann betrachten wir es als Einzelfall eines Begriffs. Der Begriff ist irgendwo in der Luft, und für die Philosophie ist das ein wichtiges Problem, wie in der Luft der Begriff ist - ganz im Gegensatz zur Softwareentwicklung, wo man von Anfang an ohnehin nur mit Konstruktionen operiert. Die Konstruktion, dass es einerseits ein Muster, Template oder Pattern gibt und andererseits dann eine Umsetzung dieses Templates in einzelne Bereiche, ist für die Softwareentwicklung weiter nicht problematisch. Daraus ergibt sich sogar der nette Effekt, dass wir in der objektorientierten Programmierung auf eine sehr ungenierte Art und Weise mit platonischen Motiven arbeiten können, weil das alles etwas ist, was wir uns sozusagen selber konstruieren. In einer mehr von der begrifflichen Problematik und der Frage geleiteten Überlegung, um was es sich da eigentlich handelt, wenn wir von Ideen und Begriffen reden, ist das hingegen nicht der Fall.

Muster und Umsetzung (Software Engineering vs. Philosophie)

In meiner Kette von Überlegungen, die ich Ihnen jetzt vorlege, werde ich darauf hinauskommen, dass ein bedeutender Unterschied besteht zwischen diesem platonisierenden Muster in der Softwareentwicklung und dem, was die Philosophie im Zusammenhang mit Begriffen und der Realisierung von Begriffen sagen möchte. Dieser besteht genau darin, dass es aus philosophischer Sicht einen Widerspruch, eine Interaktion bzw. einen Austausch zwischen den Mustern und den Umsetzungen gibt. Das ist genau jener Punkt, auf den ich hier aufmerksam gemacht worden bin. Die richtige Rede von der Heiligkeit sollte demnach nicht so vollzogen werden, dass man sagt, da hat sich der Geist Gottes auf die Person gesetzt und hat diese zum Heiligen gemacht (das wäre ein primitives Muster), sondern die richtige Rede ist jene, dass es einen Sitz im Leben und Abläufe in der Geschichte gibt, die einen Anstoß für das Auslösen der Frage- und Problemstellung geben. Die Heiligsprechung ist daher eine sehr greifbare Reaktion auf einen sehr brutalen Ablauf im echten Leben. Wenn man das berücksichtigt, dann läuft das auf eine weniger mechanische Betrachtungsweise hinaus, weniger mechanisch und auch weniger semiotisch. Ich habe es ja semiotisiert, semiologisch aufgefasst in Bezug auf die Beispiele der Naomi Campbell und Paris-Match, die ich das letzte Mal erwähnt habe.

Objektorientierung

siehe auch: Objektorientierung_(CP)

Spaghetticode

Dann gehe ich über zur Objektorientierung und beginne vielleicht mit dem folgenden Beitrag: Hier ist ein schönes Beispiel von Spaghetticode zu sehen. Ich glaube, das ist im ersten Ansehen leicht und sofort zu erkennen. Der Kollege PW hat dann ein noch eindrucksvolleres Beispiel zur Verfügung gestellt. Dabei handelt es sich um ein taktisches Gesamtkonzept der U.S.Army über den Krieg in Afghanistan. Und wie von General McChrystal zurecht angeführt wird: „When we understand that slide, we’ll have won the war.“ Worum es sich dabei inhaltlich handelt, ist hier nicht unser Thema. Warum verwende ich aber Spaghetticode 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 und mehr oder weniger unverständlich werden. Auf der Basis dessen kann man sich sehr gut vorstellen, wie WikiLeaks zustande kommt. Es scheint unvermeidbar zu sein, dass sich da irgendwo eine undichte Stelle ergibt, wo jemand sitzt, der dann in der Lage ist, Daten abzuziehen.

Die beiden Beispiele zum Spaghetti-Code zeigen zwar recht deutlich Komplexität und Unüberschaubarkeit, sind aber nicht ganz glücklich gewählt, da es sich beim ersten Beispiel um ein Entity Relationship Diagramm handelt, das ähnlich einem Klassendiagramm sehr schnell einen hohen Grad an Komplexität aufweisen kann, aber trotzdem die Basis für ein strukturiertes Vorgehen in der objektorientierten Softwareentwicklung bildet (siehe dazu auch diese Anmerkungen). -- Fiede 23:58, 27. Dez. 2010 (UTC)

Historische Entwicklung von Programmiersprachen

Ich möchte Sie nun kurz und stichwortartig mit einem Überblick über die Entwicklung von Programmiersprachen konfrontieren. Ich habe Ihnen hier (Objektorientierung_(CP)#historischer Überblick) zwei Skizzen hinein geklebt, die ich aus einem Blog [4 Lines of Code] genommen habe. Am Beginn des Programmierens hat man Software Engineering (das ist hier der Basisausdruck) als technische Ingenieurswissenschaft verstanden, in deren Mittelpunkt allerdings nicht mehr Maschinen, sondern Software stand. Es war die Zeit riesiger Computer, noch vor dem Personal Computer, wo in jeden dieser großen Computer nicht nur die entsprechenden Relais, Schaltungen, Elektronik, usw. integriert waren, sondern jedes von diesen Beasts auch eine eigene Sprache gehabt hat, mittels der man mit dieser Maschine kommuniziert hat. Jede dieser Assemblersprachen, welche die Maschinensprache einer Computerarchitektur in einer für den Menschen lesbaren Form repräsentiert, war genau an die Kapazitäten des jeweiligen Computers angepasst.

Eine kleine Nebenbemerkung: Aus dieser Zeit stammt auch die allgemeine Vorstellung, dass Software etwas ist, das man weitergeben kann, um auf gute Konzepte und Ideen zu kommen, da man die Software sowieso nicht verwenden kann. Mit Ausnahme einiger weniger Regierungs- und Verteidigungsinstanzen konnte sich diese Computer niemand leisten und demnach auch die Software nicht einsetzen. Das hat sich erst im Laufe der Zeit geändert, in einer Situation, in der die Personal Computer den Siegeszug angetreten haben und schließlich Millionen von Maschinen mit einer bestimmten Software betrieben werden konnten. Dadurch, dass man Betriebssysteme wie MS-DOS, Windows oder Linux und natürlich auch andere Software jeder/m Einzelnen verkaufen konnte, tauchte dann plötzlich das große Geld am Horizont auf. Also das nur als kleine Klammerbemerkung.

Der Spaghetticode wird hier in die Sechziger Jahre platziert und ist untrennbar verbunden mit den imperativen Programmierparadigmen, wie dem Sequential Programming und dem Procedural Programming, wenngleich auch nicht darauf beschränkt, wie wir bereits gesehen haben. Ausgehend von diesen Ansätzen ist so in etwa in den Achtziger Jahren die objektorientierte Programmierung entstanden. Wenn Sie sich die Beschreibungen und Diagramme anschauen, werden Sie sehen, dass es sich dabei um frühe Versuche handelt, in den Ad-hoc Ablauf, den man im Programmieren zunächst einmal verwendet hat, eine gewisse Ordnung zu bringen. Die frühen Anwendungsgebiete der Programmierung bezogen sich auf einfache Problemstellungen, zumeist mathematische Aufgaben, die von einem Computer gerechnet werden sollten. In einem Sequential Programming Beispiel geht es etwa darum die Fläche eines Kreises zu berechnen. Als Input-Parameter wird der Radius des entsprechenden Kreises eingegeben, dieser Wert wird in die Formel zur Kreisberechnung eingesetzt und die Maschine wirft dann das Resultat, die berechnete Fläche aus. Diese Vorgehensweise wird im Computer durch eine Reihe von Befehlen abgebildet, die Schritt für Schritt abgearbeitet werden.

Mit der Situation, dass die Komplexität der Aufgabenstellungen kontinuierlich zugenommen hat, ist man zunächst einmal so umgegangen, dass man diese Aufgaben genau definiert und in nacheinander auszuführende Einzelschritte zerteilt hat. Durch die einerseits zwar nachvollziehbare, sinnvolle Verbindung zwischen verschiedenen Aufgaben, stand man ab einem gewissen Zeitpunkt aber vor dem Problem, den Wald vor lauter Bäumen nicht mehr zu sehen. Das ist ungefähr so ähnlich wie im Wiki. Wikis sind, wenn sie ein bisschen gebraucht werden, auf der natürlichen Ebene typisch so etwas wie Spaghetticode. Sie schreiben einen Beitrag, jemand verfasst einen weiteren Beitrag zu diesem Beitrag, dieser löst eine Diskussion auf der Diskussionsseite zu diesem Beitrag aus, die wiederum auf diesen Beitrag zurück verweist und sich auch auf weitere früher verfasste Beiträge bezieht, usw. Dabei heraus kommt ein klassischer Fall von Spaghetticode, sofern nicht eingriffen wird und dieser Effekt wird Ihnen vermutlich im Philo-Wiki auch schon aufgefallen sein. Jemand, der nicht von Beginn an dabei gewesen ist, und daher nicht verfolgen konnte, wie sich die Diskussion und die Beiträge im Wiki über die Zeit entwickelt haben, hat es sehr schwer, sich einen Überblick zu verschaffen, vor allem in Hinblick darauf, wie das alles zusammenhängt. Bezogen auf das Wiki bleibe ich dabei, dass das eine gute Sache ist oder sein kann, aber in der Softwareentwicklung ist relativ klar, dass eine solche Vorgehensweise nicht wirklich zukunftsweisend ist.

Im Netz können Sie eine Vielzahl von Einleitungen, Erläuterungen und Tutorials über die objektorientierte Programmierung finden. Das hängt auch damit zusammen, dass das WWW ab den Achtziger Jahren bereits so weit war, dass es sowohl für die Darstellung der Probleme als auch für die Bereitstellung von Lehrmaterialien intensiv genutzt werden konnte. Ich werde Ihnen zwei Beispiele geben (C++ und Java), die uns die Entwicklung ein bisschen weiter zeigen sollen. Falls Sie also bestimmte Begriffe aus der Objektorientierung in Zukunft mal hören oder wenn Sie jemandem erzählen, dass Sie in Philosophie etwas über objektorientierte Programmierung gehört haben, sollten Sie zumindest in der Lage sein, identifizieren zu können, worum es da geht. Zu den Vorgängern objektorientierter Sprachen zählen die prozeduralen Programmiersprachen, die den Ansatz verfolgen, Programme in kleinere Teilaufgaben aufzuspalten, die Prozeduren genannt werden. Beispiele dafür sind Fortran, Pascal oder C. C ist deswegen ausgesprochen wichtig, weil es die Programmiersprache 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 schon ein bisschen in den Mainstream hinein geraten sind, die sich also bereits mehrere Leute kaufen konnten.

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 ursprünglich nur auf Großrechenanlagen und war gerade aus diesem Grund frei zugänglich, wie ich bereits angesprochen habe, weil die Limitierung der Weitergabe von Software zu dieser Zeit noch kein Thema war. Linus Thorvalds hat dieses Unix-System umgeschrieben, also eine leistungsfähige, in C geschriebene Version von Unix entwickelt. Der Normalcomputer, den man sich in den Neunziger Jahren dann schon leisten konnte, lief unter DOS und Windows 3.1. Und für diese Art von Computern hat Linus Thorvalds eine Unix-Version geschrieben, natürlich nicht nur er, sondern das war eine massive Internet-Aktion mit breiter Beteiligung. Das hat bedeutet, dass man nun auf einem solchen Computer, auf dem gewöhnlich Windows gelaufen ist, der ständig abgestürzt ist und ausgesprochen langsam war, ein Unix Betriebssystem installieren konnte. Linux, das so entstandene erste freie Betriebssystem, ermöglichte eine sofortige Verbindung ans Internet, eine unmittelbare Bereitstellung von Servern sowie aller Routinen und Instrumente, mit denen man neue Software installieren konnte. Das war ein gigantischer Sprung, wenngleich auch nicht in Hinblick auf die Benutzerfreundlichkeit, die Usability kann als ziemlich haarig bezeichnet werden. Diese Entwicklung war aber in jedem Fall richtungsweisend bis in die heutige Zeit. Das war die Vorbemerkung zu C, C++ ist dann die objektorientierte Weiterentwicklung von C, die sich sowohl für die maschinennahe Programmierung als auch für eine Programmierung auf hohem Abstraktionsniveau eignet.

Anmerkung: Typische Anwendungsfelder von C++ liegen in der Systemprogrammierung (Betriebssysteme, Treiber, etc.), aus dem Bereich der Anwendungsprogrammierung wurde C++ mit dem Aufkommen der Sprachen Java und C# zum Teil zurück gedrängt. Die besondere Eignung für Graphik-Programmierung ergibt sich daraus, dass in C/C++ maschinennah programmiert werden kann. Für die Implementierung graphischer Benutzeroberflächen wird C/C++ nicht mehr so häufig eingesetzt, speziell im Web-Umfeld dominieren heute Script-Sprachen. -- Fiede 19:06, 13. Dez. 2010 (UTC)

Wenn Sie auf die Ikone für den Browser Firefox klicken, dann sehen Sie das Folgende: Es wird ein Fenster aufgemacht, das eine Adressleiste, einige Buttons und einen Menüeintrag hat. Wenn Sie fünf Seiten im Firefox öffnen, nebenbei noch eine Anwendung aus dem Office-Paket und irgendein kleines Spiel, 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, etc. An dieser Stelle können Sie bereits das von mir vorhin erwähnte Konzept einer Klasse und deren Instanzen erkennen. In dem Moment, in dem Sie eine graphische Oberfläche haben, sind Sie anders unterwegs als auf der Kommandozeile. Auf der Kommandozeile erzeugen Sie mit jedem Befehl, den Sie da eingeben, eine Reaktion des Computers. Diese Reaktion ist zum Beispiel abgestimmt auf bestimmte Parameter, die Sie der Befehlszeile mitgeben. Das heißt, 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 Programms von Vornherein mit angeben.

Um Ihnen ein spezielles Beispiel zu nennen, nehmen wir an, Sie haben ein Soundfile, das im APE-Format komprimiert ist und Sie wollen diese Datei in ein MP3-Format umwandeln. Sie können dazu einen Transcoder auf der Kommandozeile aufrufen, indem Sie den Namen des Programms eintippen, und als Parameter die Dateinamen und -pfade der Quell- und Zieldatei angeben sowie, welche Art von Konversion durchgeführt werden soll. Diesen Input bestätigen Sie mit Enter, das Programm läuft und erzeugt das MP3-File, ohne weitere schöne Visuals. Die meisten Benutzer würden heutzutage anders vorgehen, einmal ein Programm starten, womit noch nicht viel im Zusammenhang mit dem Transcodieren geschehen ist, sondern Sie haben damit einmal nur ein neues Fenster geöffnet. Das heißt, an dieser Stelle hat sich das Programm, das Sie aufgerufen haben einmal ans Betriebssystem gewendet und gesagt, ich brauche ein Fenster, damit ich weiterlaufen kann. Das Betriebssystem hat dieses Fenster zur Verfügung gestellt, auf Basis von im Programm verfügbaren Klassen von Graphikelementen, aus denen dieses Fenster zusammengesetzt ist. Die Klassen sind die abstrakten Beschreibungen von dem, was zu einem Fenster so dazu gehört. Es wird ein Ding produziert und dieses eine Fenster, dass dann das Fenster auf ihrem Desktop ist, wird von dem Programm mit Inhalt gefüllt. 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.

Anmerkung: Es ist anzunehmen, dass auch ein Programm mit graphischem User Interface beim Starten bereits einige Initialisierungen vornimmt. Eventuell werden bereits Parameter gesetzt, die im Fall der Verwendung der Kommandozeile erst noch zusätzlich eingetippt werden müssten. Bezogen auf das Beispiel des Transcodierens eines Soundfiles: Im einen Fall (graphisches User Interface) starten Sie das Programm, ein Fenster öffnet sich und Sie können dann, üblicherweise unter Menüpunkten wie Optionen oder Eigenschaften, oder in einem speziellen Wizard für das Transcoding, Parametrisierungen für die Konvertierung vornehmen. Im anderen Fall (Kommandozeile) übergeben Sie dem Programm diese Parameter direkt beim Programmaufruf. Variante 2 ist natürlich für den Benutzer transparenter, abgesehen davon sind aber die selben Dinge zu tun, wenn auch in einer unterschiedlichen zeitlichen Abfolge. --Fiede 13:46, 13. Dez. 2010 (UTC)

Objektorientierte Konzepte

Hier ist eine ganz nette Auflistung der Fragen, die zur objektorientierten Programmierung geführt haben:

  * 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?

Ich habe Ihnen vorher schon angedeutet, dass es nicht mehr um Befehlssequenzen geht, sondern es sollen Real Life Objects innerhalb eines Systemdesigns repräsentiert werden, die eben nicht Folgen von Befehlsabläufen sind. Worin bestehen solche Objekte in einem softwaremäßigen Zusammenhang und wie verhalten sie sich zu anderen Objekten? Nehmen wir einmal an, Sie starten einen Browser und rufen das Philo-Wiki auf, das in einem Fenster erscheint. Dann möchten Sie auch noch Musik beim Lesen des Wiki hören, das heißt, Sie starten beispielsweise den Windows Media Player. Im einen Fenster haben Sie nun den Browser, in einem anderen Fenster läuft ihr Audio-Programm. Die graphische Oberfläche beider Programme besteht jeweils aus einer Sammlung von Objekten graphischer Elemente. Wie verhalten sich diese jetzt zueinander? Es gibt eine Art und Weise, wie sie sich nicht zueinander verhalten dürfen, nämlich so, dass, wenn das eine Programm abstürzt, der ganze Computer abstürzt. Es kann sozusagen immer wieder mal passieren, dass im Rahmen eines laufenden Programms etwas schief geht, und dieses in einen Zustand gerät, in dem man weiter nichts mehr machen kann. Vermieden werden sollte jedenfalls, dass die Fehlerhaftigkeit eines Programms Auswirkungen auf andere Programme hat und damit das ganze System lahmlegt. Wenn ein Programm nicht mehr funktioniert, dann beenden Sie einfach den zugehörigen Prozess, im Optimalfall ohne dadurch die Ausführung anderer Programme zu beeinflussen.

Anders gesagt, diese Objekte, die da erzeugt werden, sollen für sich stehen. Diese Sache ist hier natürlich stark vereinfacht dargestellt und sollte noch eindringlicher erläutert werden, aber der wichtige Begriff in diesem Zusammenhang ist Kapselung. Ein Programm kann als Ensemble von Daten und Abläufen betrachtet werden, und alles das gehört in dieses Programm und sollte keine Auswirkung auf andere Programme haben, es sei denn, Sie definieren bestimmte Beziehungen zu anderen Komponenten zusammen mit Sicherheitsvorkehrungen für diese Abhängigkeiten. Ich habe vorhin das Beispiel gebracht mit dem separaten Audio-Player. Ein schöner Fall, wo Sie natürlich wollen, dass eine solche Interaktion stattfindet, ist, wenn Sie im Browser ein Movie anschauen wollen. Dann möchten Sie ganz gern auch einen Ton hören. Browser stellen aber keinen Ton zur Verfügung, sondern es wird ein Plugin benötigt um den Ton abzuspielen. Ein Browser-Plugin ist nun 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.

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 jetzt zum Java Tutorial über. Während C++ primär für Systemprogrammierung eingesetzt wird, findet Java - ebenfalls eine objektorientierte Programmiersprache – in der Anwendungsprogrammierung verstärkt ihren Einsatz. Dadurch, dass Java-Programme in Bytecode übersetzt werden, sind diese plattformunabhängig, das heißt, mit Java können Sie ein und das selbe Programm auf einem Macintosh, unter Windows oder Unix laufen lassen. Sie benötigen dazu nur im jeweiligen Betriebssystem eine Java Laufzeitumgebung.

Die Java Tutorials sind sehr schön geschrieben und instruktiv.

Objekte

(Java Tutorial: What Is an Object?)
Objekte sind wesentlich, um objektorientierte Technologie zu verstehen. Schauen Sie um sich, und Sie finden unzählige Beispiele von Objekten 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 (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, in das objektorientierte Programmieren einzusteigen. Die im C++ Tutorial angeführten Begriffe Data und Function entsprechen den hier verwendeten Begriffen State und Behavior. Ein Objekt hat bestimmte Daten, die mit ihm verbunden sind, also das Datum, welche Farbe ein Hund hat oder welcher Rasse er angehört. Dann gibt es die Funktionen (in Java: Methoden, Behavior), die angeben, welche Daten des Objektes in welcher Form durch Zugriffe von außen - durch andere Objekte - manipulierbar sind.

Wir sind momentan noch bei den Objekten, aber Sie können sich vorstellen, dass die Klasse eines Fahrrads oder die Klasse eines Hundes darin besteht, dass in einer solchen 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, einen Zustand hat, der hungrig oder nicht hungrig sein kann. Im Modell selber ist nicht festgelegt, welcher der beiden Zustände in den Einzelinstanzen eingenommen wird, es sieht lediglich die Möglichkeit für die tatsächlichen Ausprägungen der Klasse Hund vor, hungrig oder nicht hungrig zu sein. Außerdem muss für den wirklichen Hund vorgesehen sein, dass er mit dem Schwanz wackeln kann. Jene Hunde, die wir haben möchten, müssen diese Fähigkeit besitzen, auch wenn sie nicht immer mit dem Schwanz wackeln wollen.

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. Dabei wird eine Parallele sichtbar zu dem, was traditionellerweise von Gott gesagt worden ist und – entschuldigen Sie die Vereinfachung – im folgenden Satz zum Ausdruck gebracht wird: „Die Templates der Dinge sind im Geist Gottes“. Ich habe das im vergangenen Studienjahr in der Vorlesung Eine Idee haben ein bisschen ausgeführt. Es ist 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 als Tiere vorgesehen, die bellen. Die Garantie in der göttlichen Idee ist, dass Hunde ein bestimmtes Wesen haben. Man müsste Gott jetzt fragen, ob das Wackeln des Schwanzes mit geplant war oder ob es sich um einen Nebeneffekt handelt. In jedem Fall aber ist es charakteristisch für diese Art von Konzeption oder Konstruktion, dass zum Beispiel natürliche Wesen einen Kern von Wesenseigenschaften besitzen, die durch die Schöpfung und die göttliche Idee garantiert sind, und die sich in all diesen Wesen finden.

Wenn Sie nun beginnen wollen, darüber zu schmunzeln, dann stellen Sie das Schmunzeln gleich wieder ein. Eine Vorstellung wie die der Menschenrechte ist nämlich beispielsweise eine unmittelbare Konsequenz aus diesen Überlegungen. Menschen haben von Natur aus Rechte. Dahinter steht genau diese Idee, dass Menschen als Menschen auf die Welt kommen, als Wesen, die ein bestimmtes Outfit haben und ein Anrecht auf eine bestimmte Behandlung. Menschen sind nun eben keine Dinge, und zwar wesentlich nicht Dinge, und das gehört quasi zum Menschen mit dazu. Jeder Mensch hat per Konstruktion beispielsweise eine unsterbliche Seele, eine unantastbare Würde oder etwas Ähnliches. Diesen Gedanken sollten Sie da durchaus mit hinein nehmen in diesen Zusammenhang.

Zurück zu den Objekten: Software-Objekte sind begrifflich ähnlich wie Objekte der wirklichen Welt, auch sie bestehen aus Zuständen und einem entsprechendem Verhalten. Ein Objekt speichert seine Zustände in Feldern (Variablen) und teilt sein Verhalten durch Methoden mit, die gleichzeitig die Anknüpfungspunkte von außen sind. Wenn wir beim Beispiel des Hundes bleiben: Für ein solches Objekt sind Verhaltensweisen definiert wie etwa das Bellen oder das Mit-dem-Schwanz-wackeln, und diese Verhaltensweisen werden nach außen mitgeteilt, sodass Menschen darauf reagieren können. Methoden operieren an dem internen Zustand eines Objektes und dienen als primärer Mechanismus zur Kommunikation zwischen Objekten. Indem der interne Zustand der Objekte verborgen bleibt und alle Interaktionen notwendigerweise durch die Methoden eines Objektes durchgeführt werden, wird das Konzept der Kapselung (Data Encapsulation) realisiert, ein fundamentales Prinzip der objektorientierten Programmierung. Es ist somit nicht erforderlich zu wissen, was in einem Hund vor sich geht, wenn er mit dem Schwanz wackelt. Der Mensch reagiert auf das Schwanz-wackeln und muss keine chemische Analyse oder Ähnliches über den internen Zustand dieses Hundes durchführen. Wenn der Hund hungrig ist, brauchen Sie keine Kenntnis davon, wie es in seinem Verdauungstrakt ausschaut, sondern die Zeichen des Hungrig-seins sind seine Methode, Sie darauf aufmerksam zu machen, dass Sie mit ihm in gewisser Weise interagieren sollten.

Klassen

(Java Tutorial: What Is a Class?)
Ich hoffe, Ihnen damit ansatzweise ein bisschen die Angst vor dieser Art von Konstrukten zu nehmen. Die Klasse Bicycle ist eine mögliche Implementierung eines Fahrrades in Java. Sie enthält die States cadence, speed und gear. Das Softwarekonstrukt Fahrrad hat somit einen Gang (speed), eine Geschwindigkeit (speed) und eine Frequenz, mit der es getreten wird (cadence). Dabei handelt es sich um interne Zustände, die das Fahrrad für sich behält und nicht an die Öffentlichkeit mitteilt, sofern diese mit dem Sichtbarkeitsattribut private versehen sind:
private int gear = 1;

Anmerkung: int repräsentiert den Datentyp und definiert, dass die Variable gear mit ganzzahligen Werten belegt werden kann. Andere Datentypen in Java sind etwa byte, boolean oder char (sogenannte primitive Datentypen), die hier an Stelle von int stehen könnten. States können aber auch selbst Objekte sein, das heißt, Datentypen wie Object, Integer, String oder auch Bicycle wären an Stelle von int ebenfalls zulässig. -- Fiede 19:03, 13. Dez. 2010 (UTC)

Etwas anschaulicher vielleicht: int als Datentyp definiert, daß gear immer auf eine Zahl eingestellt sein muß (und zwar eine ganze Zahl, die meisten Ontologien unterscheiden zwischen Ganzzahlen und Kommazahlen). Ein anderer wichtiger Datentyp wäre string. Ein string ist eine Zeichenkette, also ein Stück Text. Die Bedeutung von Datentypen liegt darin, daß man damit unterschiedliche Dinge anstellen kann, z.B. kann man zwei Zahlen miteinander multiplizieren, was bei zwei Texten keinen Sinn machen würden, dafür kann man in einem Text nach einem bestimmten Wort suchen. --H.A.L. 09:07, 17. Dez. 2010 (UTC)

Es kann nun eine neue Instanz der Klasse Bicycle erzeugt werden (zum Beispiel ein 5-Gang-Fahrrad):
Bicycle mein5GangFahrrad = new Bicycle();
Dadurch wird im Zuge der Initialisierung der Wert der Variable gear auf 1 gesetzt, das heißt, das Fahrrad befindet sich zu Beginn im ersten Gang. Auf die States von mein5GangFahrrad kann nicht direkt zugegriffen werden, sondern nur durch Verwendung der Methoden changeCadence, changeGear, speedUp und applyBrakes besteht die Möglichkeit die internen States zu ändern. Sie können nun in den dritten Gang schalten, indem Sie von außerhalb des Objekts die Methode changeGear aufrufen:
mein5GangFahrrad.changeGear(3);
Damit haben Sie modelliert, was passiert, wenn die Gangschaltung des Fahrrads betätigt wird. Damit will ich es mit diesem absolut oberflächlichen Blick auf die Objektorientierung erstmals bewenden lassen, habe aber noch eine Sache in Planung. Ich möchte auch noch darauf hinweisen, dass Sie herzlich dazu eingeladen sind, hier Korrekturen vorzunehmen und das Ganze noch ein bisschen weiter zu entwickeln, da ich beim Mitlesen der Wiki-Kommentare bemerkt habe, dass es ein paar Leute gibt, die sich mit dieser Thematik viel besser auskennen als ich.

Platon platonisch

siehe auch: Platon_platonisch_(CP)

Interaktive Text-Adventures

Womit ich mich noch ein bisschen auseinander setzen möchte, steht mit Tätigkeiten von mir und von Studenten von mir in den letzten Jahren in Zusammenhang. Wenn man von objektorientierter Programmierung und Platon redet, dann ist es eigentlich nicht möglich, Sie nicht auf dieses Thema aufmerksam zu machen. Worum handelt es sich? Wir haben im Studienjahr 2008/09 ein Projektseminar: Platons Staat Interaktiv gemacht, mit dem Ziel uns mit Platons Politeia zu beschäftigen. Dabei wollten wir zumindest aus Teilen von Platons Politeia ein interaktives Text-Adventure gestalten, das mit einer objektorientierten Sprache geschrieben ist. So weit zur allgemeinen Kurzfassung. Ich zeige Ihnen einmal die Re:Public Release-Seite, so weit sind wir dann bis zum Ende des Seminars gekommen. Die Entwicklung des Projekts selbst können Sie auch im Wiki nachverfolgen, wenn Sie wollen und Zeit haben. Es ist durchaus vom Wiki her Spaghetticode-mäßig durchgeführt worden. Da haben wir uns überhaupt nicht leicht getan. Zur Umsetzung von Platons Staat Interaktiv haben wir die objektorientierte Programmiersprache Inform 7 verwendet.

Wenn Sie sich an die Sache ein bisschen heran arbeiten wollen, dann finden Sie an der folgenden Stelle die Manuals zu Inform. Falls Sie sich nur ein bisschen umschauen wollen, um zu sehen worum es da geht, dann finden Sie das Spiel Re:Public online. Es handelt sich dabei um ein Google Service, das es gestattet, online interaktive Text-Adventures darzustellen.

Was sind interaktive Text-Adventures?

Text-Adventures präsentieren das eigentliche Spielgeschehen in rein textueller Form und benutzen Grafiken und Soundeffekte entweder gar nicht oder als zusätzliche illustrative Elemente. Die Kommunikation zwischen Spieler und Spiel findet über einen Text-Parser statt. Anweisungen werden dabei in natürlicher Sprache über die Tastatur eingegeben oder aus vorhandenen Textbausteinen zusammengesetzt und anschließend vom Computer interpretiert. Man sucht sich also mit Hilfe von Kommandos wie 'Rede mit Wirt' oder 'Nimm Schwert' seinen Weg durch die fiktive Welt. [1]

Interaktive Text-Adventures stammen aus der Frühzeit des Umgangs mit Computern, genauer gesagt aus jener Zeit, in der die Kommandozeile noch das Wichtige war. Wenn Sie sich erinnern, das ist jene 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. Für mich hat die Kommandozeile eine besondere Attraktivität gehabt, eine gewisse sentimentale Neigung ist noch immer vorhanden, weil da ein Bruch dazwischen liegt. Auf der Kommandozeile konnte man noch einigermaßen nachvollziehen, was man tut, wenn man mit seinen Fingern da hinein tippt, im Gegensatz dazu überliefert man sich dem Ablauf eines Feuerwerks von Gadgets, die in einer graphischen Benutzeroberfläche auf einen zukommen. Ich habe Sie schon kurz auf das Verhältnis der Betriebssysteme DOS und Windows 3.1 hingewiesen. Man musste zuerst DOS starten, um dann einen schwarzen Schirm mit einem blinkenden Cursor zu bekommen. Erst dann konnte man Windows starten und die graphische Oberfläche wurde sozusagen auf DOS aufsetzend geladen. Wenn diese Oberfläche abgestürzt ist, kam man wieder zu DOS zurück – das war die Frühzeit. Ab einem gewissen Zeitpunkt gab es das nicht mehr, sondern das Betriebssystem Windows ist automatisch als graphisches Programm nach dem Start des Computers geladen worden. Unter Microsoft Windows haben Sie keinen Ausweg, Sie sind an dieser Stelle sozusagen im Käfig des graphischen Betriebssystems. Unter Linux kann man mittels einer einfachen Tastenkombination zur Konmmandozeile wechseln, ganz zu schweigen davon, dass Sie in der graphischen Benutzeroberfläche auch kommandozeilen-operiert arbeiten können. Die graphische Welt unter einem Unix-Betriebssystem ist separiert vom Betriebssystem selbst, da ist also dieser Bruch noch drinnen. So weit zu einer kurzen Illustration, warum ich eine gewisse sentimentale Neigung zur Kommandozeile habe.

Anmerkung: Auch unter Windows gibt es ein Command Line Tool, unter XP können Sie dieses beispielsweise folgendermaßen starten: Start -> Ausführen, und Eingabe von cmd. Trotzdem bleibt es natürlich dabei, dass die beiden Betriebssysteme Linux und Windows in dieser Hinsicht sehr verschieden sind. --Fiede 13:46, 13. Dez. 2010 (UTC)

Re:Public - Philosophy and Interactive Fiction

Interaktive Text-Adventures schauen jetzt so aus, dass Sie eine Kommandozeile bekommen, in der Sie etwas eingeben können und das Programm antwortet auf Ihren Input auf irgendeine Art und Weise. Bei unserem Spiel ist Danubia Park Entrance 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):

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 Ä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) auf bestimmte Inputs Textbeschreibungen ausspucken. Sie können sich ein relativ komplexes Spiel vorstellen, wo das im Hintergrund ein bisschen so aussehen könnte wie diese Afghanistan-Skizze, wo aber auf geordnete Art und Weise, was immer da auch eingegeben wird, mit einem Computer-Output beantwortet wird (mit einem Junk von Text). Als Spieler von interaktiven Adventures weiß ich, dass mir eine Anzahl von Kommandos zur Verfügung steht. Eines der Kommandos ist examine (abgekürzt mit x), das in diesem Kontext angewendet wird, um sich irgendein Ding genauer anzuschauen. Ich sehe mir natürlich nur an, wovon mir gesagt wird, dass es das gibt.

Die Situation ist jetzt die, dass ich mich in diesem Spiel in einer bestimmten Position befinde und die Kommandos auf eine bestimmte Art und Weise anwenden kann. Die Logik, die dahinter steht, wenn ich diese Kommandos auf bestimmte Bestandteile des Textes und des Spieles anwende, sollte eine Logik sein, die an der wirklichen Welt orientiert ist. Wenn beschrieben wird, dass es ein Ding gibt, dann kann ich mir dieses genauer ansehen. Gibt es das Ding aber nicht, dann soll zum Beispiel nicht Fehler 27 ausgegeben werden, sondern eine Antwort, die darauf angelegt ist, dass in der Logik meines Schau-Dir-an (examine) schon enthalten ist, dass ich mir ein Objekt anschauen wollte. Die Eingabe von x entrance (examine entrance) verweist darauf, dass ich davon ausgehe, ein Objekt in der Welt zu haben, das ein Eingang ist, den ich genauer beschrieben haben möchte. Wenn es dieses Objekt in dieser Welt nicht gibt, dann bekomme ich als Antwort „You can't see any such thing.“ und nicht irgendeine Fehlermeldung. Das impliziert, dass das Programm weiß, dass ich etwas ansehen wollte und mir jetzt die Beschreibung eines Dings erwartet habe, dieses Ding aber nicht da ist. Dabei handelt es sich um Strukturen, die in dem Programm bereits enthalten sind und die Bewegung innerhalb der simulierten Welt steuern - wie beispielsweise auch eine Art von Geographie, die Möglichkeit, nach Osten, Westen, usw. zu gehen.

Inform 7

Im Hintergrund dieses Spiels steht eine objektorientierte Programmiersprache, die in diesem Fall Inform 7 heißt. Das nächste Mal werde ich ein bisschen in die Details gehen, um Ihnen das genauer zu zeigen. Inform 7 ist eine Programmiersprache, die es Ihnen möglich macht Standard-Englisch zu verwenden, um die Implikationen der wirklichen Welt, die Sie in unserer englischen Sprache haben, in der simulierten Welt (Spielwelt) ganz einfach automatisch umzusetzen. Wenn Sie sich an das Java Code Fragment über das Bicycle erinnern, in Inform könnten Sie das einfach so formulieren: „Bicycle is a kind of thing. Bicylce has gears and speed.“. Das schreiben Sie in normalem Englisch hin, die Inform-Umgebung kompiliert diese Eingabe dann im Hintergrund zu einer digitalen Welt und gibt Ihnen so die Möglichkeit, aufgrund Ihrer objektorientierten Formulierungen eine Welt von Objekten und ihren Interaktionen zu gestalten. Mit der Formulierung „Danubia Park Entrance is a room“ erzeugen Sie zum Beispiel das Objekt Danubia Park Entrance, room ist an dieser Stelle eine Klasse. Im Programm für interaktive Fiktion gibt es bereits eine Anzahl vordefinierter Templates, zum Beispiel die Klasse für einen Raum. Räume haben somit bereits bestimmte vordefinierte Eigenschaften. Wenn Sie nun eine Instanz von dieser Klasse (zum Beispiel Danubia Park Entrance) erzeugen wollen, brauchen Sie diese sozusagen nur mehr zu bestellen. Das Programm erzeugt dann einen Raum mit bestimmten Eigenschaften, die Räume in der Regel haben - ein Raum kann beleuchtet oder nicht beleuchtet sein, das heißt, sie sehen in dem Raum etwas oder sie sehen nichts. Räume haben es somit wesentlich an sich, dass sie beleuchtet sein können. In dem Moment, in dem Sie den Raum Danubia Park Entrance bestellt haben, wird eine bestimmte Softwarekonstruktion erzeugt, die in der Landkarte, die für dieses Spiel gemacht wird, hier zugleich am Anfang steht (Danubia Park Entrance – room where play begins). In diesem Raum befinden Sie sich am Beginn des Spiels selbst als Person und dieser Danubia Park Entrance kann jetzt in der Logik dieses Spiels mit anderen Räumen verbunden werden. Sie haben sozusagen alles, was Sie brauchen, um schöne Spiele spielen zu können, softwaremäßig schon mal vorgegeben.

Ich werde das nächste Mal nicht mit dem Spiel beginnen, das vergleichsweise komplex ist. Um Ihnen zuerst einfachere Sachen zu zeigen, werde ich mich auf ein Modell beziehen, das Andreas Kirchner von einem Buch entworfen hat - ein in Inform modelliertes Buchmodell. An diesem Beispiel wird es dann vielleicht ein bisschen transparenter, wie so etwas funktioniert. Die Frage nach der Definition der Eigenschaften, die Sie schon aus meinen Ausführungen über den Tisch kennen wird sich auch im Zusammenhang mit diesem Modell eines Buches stellen.