Wie sage ich es meinem Objekt? - Beck-to-Philosophie Hans N. Beck

Alan Kay, Ivan Sutherland und viele weitere Forscher in den 60iger und 70iger Jahren sahen in dem Computer die Chance, die geistig-konzeptuelle Arbeit des Menschen und seine Kreativität zu unterstützen. Dafür ersannen sie viele Vorschläge für ihrer Ansicht nach hilfreiche Computersysteme.

Bei beiden spielte das Konzept der Objekte eine wesentliche Rolle. War es bei Alan Kay mehr die Vorstellung, Objekte als recht unabhängige Dinge zu denken, die sich Nachrichten zusenden und darauf in ihrer eigenen Weise reagieren, präsentierte Ivan Sutherland mittels des von ihm entwickelten Systems Sketchpad die unmittelbare Interaktion mit Objekten am Bildschirm via Lichtgriffel.

Beiden ist der einfache und in gewisser Weise direkte Umgang mit Objekten gemein. Im System Smalltalk geschieht dies mittels einer sehr einfachen Programmiersprache — Smalltalk. Da das System Objekte für Graphik, Dateien und vieles mehr anbietet ist es sehr einfach, eine simple Simulation, eine Berechnung oder gar einen Editor zu schreiben. Der Anwender muss nur mittels der Sprache Smalltalk diese Objekte über Nachrichten vernetzen. Der gut bevölkerte “See” der Objekte im System bietet auch heute noch viele Möglichkeiten — die Erschaffung neuer Objekte inklusive.

Im Falle des Sketchpad von Ivan Sutherland war das Medium die graphische Repräsentation von Objekten wie Punkte und Linien, die auf dem Bildschirm erschienen. Daraus konnten geometrische Strukturen erstellt werden, indem diese Punkte und Linien mit dem Lichtgriffel angesprochen und zusammengefügt werden konnten. Diesen so erstellten Objekten konnte der Anwender Randbedingungen (“Constraints”) zuordnen, um deren Erfüllung diese Objekte sich selbst kümmerten. Solche geometrischen Objekte waren beliebig skalierbar und waren Bausteine für komplexere Strukturen.

Heutige Software stellt sich oft als eine überbordende Menge von Menüs und Optionen dar. Kontextmenüs und Modi zwingen den Anwender auf eine Logik, die die Autorinnen und Autoren eines Systems als sinnvoll erachteten. Mit Glück wurde dafür die zugrundeliegende Problematik bzw. das Themengebiet beachtet. Ein positives Beispiel sind Game-Engines, die heute alle mehr oder weniger derselben Logik folgen.

Natürlich ist die Diskussion bzgl. graphischer Benutzeroberflächen vs. Kommandozeile nicht neu — und ich kann mich an Zeiten erinnern, als viele Kolleginnen und Kollegen einen Emacs oder Vim jeglichen “modernen” Maus-und-Klick-Editoren den Vorzug gaben. Aber mir geht es hier nicht um Bedienungskomfort — es geht um die intentionale Kommunikation mit der Maschine.

Sprache, worauf schon der Philosoph Wittgenstein hinweist, ist ein wesentlicher, bedingender Faktor und Ausdruck für das Denken. Aus meiner Sicht ist Sprache nicht nur das gesprochene (oder geschriebene) Wort, es ist genauso die Idee, womit ich als erfahrungsbasiertes Wesen dem Computer, der nicht erfahrungsbasiert ist, klar machen will, was ich möchte oder brauche.

Wenn wir also annehmen, dass der Mensch mit Ideen und Konzepten in seinem Denken arbeitet, und diese sich durch die Sprache ausdrücken, so kann man vermuten, dass Objekte eine gute Schnittstelle für die Mensch-Maschine Kommunikation sind. Die Dinge, mit denen wir zu tun haben, gaben wir Namen, mit Prädikaten beschreiben wir sie, geben ihnen Qualitäten. Verben bezeichnen dann die Prozesse, deren Gegenstand die Objekte sind.

Also: Nomen und Verben sowie Prädikate erscheinen als ein sinnvolles Mittel, um Computer zu einem Werkzeug des Denkens und Schaffens zu machen. Die Intention dessen, was gedacht ist, lässt sich damit denk-nah ausdrücken. Konsequenter Weise braucht es dann einen effizienten Weg, Objekte anzuzeigen (sie als Ziel eines Verbs oder Prädikats zu identifizieren) und Verben bzw. Prädikate eindeutig anzugeben bzw. zuzuweisen.

Damit ist der Punkt erreicht zu fragen, wie ein Objekt als Ziel einer Intention angezeigt werden kann: per Text (wie in Smalltalk) oder als graphische Struktur (Sketchpad). In Ivan Sutherlands Sketchpad waren Objekte Dinge, die sehr nahe an dem sind, womit Ingenieure zu tun haben. Heute haben wir aber oft mit Darstellungen zu tun, die sehr abstrakt sind und eine Visualisierung von eigentlich nicht optisch erfahrbaren Dingen sind. Dies öffnet starke Interpretationsspielräume, und nicht selten werden in Softwaresystemen individuelle Interpretationen zugrundegelegt, die wiederum zu unterschiedlichen Erscheinungsbildern und Modi führen.

Eine Benennung (eines Objektes) ist hier wesentlich direkter. Zwar ist das Phänomen bekannt, dass zwischen Dialekten oder unterschiedlichen Sprachen Dinge nicht immer denselben Namen tragen. Jedoch ist der Interpretationsspielraum kleiner, sofern einmal ein Bezeichner einem Ding zugeordnet und diese Zuordnung allgemein akzeptiert wurde. Die Szene des Walfischs in der Geschichte “Per Anhalter ins All” von Douglas Adams beschreibt dies wunderschön.

Derzeit entwickle ich ein Werkzeug, um GSN (Goal Structuring Notation) Bäume zu erstellen und ggf. auch durch Metriken zu bewerten. Ganz im Sinne obiger Diskussion war mein Gedanke, wäre es nicht besser, mit dem Computer über Knoten und Verbindungen zu “reden”, ohne den Umweg über zeigen und klicken? Knoten und Kanten sollen also durch ihre Bezeichnung identifiziert werden, eine einfache Sprache mit Verben und Prädikaten deren intendierte Manipulation beschreiben. (Nebenbemerkung: Sutherlands Ansatz wird für AR/VR sehr wichtig werden, an anderer Stelle dazu mehr.)

Beispielsweise ergibt die Sequenz

'nodeTypeGSN.txt' writeGraph 'ODDHazard.txt'

eine Dot-Datei, die dann mittels dem OpenSource Tool Graphviz einen GSN Baum in Form einer Grafikdatei erzeugen kann. Der Satz, um dies zu tun, wäre

createGraph ''

Als Ergebnis erhält man z.B. eine PNG Datei:

Die Datei ‘ODDHazard.txt’ ist eine stark vereinfachte Version der Dot Syntax, mit der die Struktur des Graphen definiert wird. Die Syntax erlaubt, Platzhalter für Bezeichner zu verwenden, um sie an geeigneter Stelle im Knotentext erscheinen zu lassen. Die Datei nodeTypesGSN.txt enthält die diversen Knotentypen und deren entsprechenden Formatanweisungen für Graphviz (eine Datei für Fehlerbäume existiert übrigens ebenfalls).

Die Markierung von Knoten des GSN-Baumes kann durch Sätze wie

markNode 'G112'
markNode 'G1212'

erfolgen, wo ‘G112’ und ‘G1212’ die entsprechenden Knoten angeben. Diese Markierung wird durch einen roten Kasten angezeigt, und kann Grundlage weiterer Aktionen sein: löschen von Knoten, verbinden etc..

In einem späteren Ausbau könnten dann Sätze hinzukommen der Art

findNodes 'G12x'
findNodesOfLevel 2
joinNodes 'G1212' 'G1213'
deleteSubtree 'G121'

Bei meiner weiteren Arbeit wird es also darum gehen:

was mache ich typischer Weise bei der Erstellung eines GSN Baums, und wie beschreibe ich das? Somit wird sich eine “Sprache” entwickeln, die dem Umgang mit GSN Bäumen maximal entspricht,
die Grafik zeigt Objekte und deren Bezeichnung an. Die Grafik dient nicht dem “Anfassen” von Objekten, aber ist eine Hilfe für die Bezeichnung.

Dabei muss ich mir immer selbst bewusst werden, welches überhaupt die wesentlichen Konzepte und Aktionen sind — und dies macht den Computer zu dem, was Alan Kay und Ivan Sutherland immer wollten: ein Unterstützer für Konstruktion und Idee.

Noch ein Wort zur Implementation: für den Prototyp wurde die Sprache J verwendet, eine Variante der array-basierten Programmiersprachen (wie APL). Später Versionen werden auch PROLOG mit einbeziehen.

Referenzen

Dan Ingalls Seminar zu OOP 1989: https://www.youtube.com/watch?v=Ao9W93OxQ7U&t=10s
Alan Kay’s Vortrag bei Qualcom 2013 zu “complex” vs. “complicated”: https://vimeo.com/82301919
Semiar mit Alan Kay zu OOP: https://www.youtube.com/watch ?v=QjJaFG63Hlo
Text zur Geschichte von Smalltalk: https://worrydream.com/EarlyHistoryOfSmalltalk/
Alan Kay at UCLA 2024: https://watch?v=dZQ7x0-MZcI
SketchPad: https://www.cl.cam.ac.uk /techreports /UCAM-CL-TR-574.pdf
Graphviz: https://graphviz.org
GSN — Goal Structuring Notation: https://scsc.uk/gsn?page=gsn%203nutshell