Mikael Kindborg und Kevin McGee haben sich auf recht einfach verständliche und vergnügliche Weise mit der Mächtigkeit der grafischen Programmierung mittels der Logik - Kacheln in EToys auseinandergesetzt, und die Grenzen dieser Art der Programmierung erläutert. Thema: "Graphical rewrite rules, Semiotics"
Visual Programming with Analogical Representations: Inspirations from a Semiotic Analysis of Comics Mikael Kindborg and Kevin McGee Department of Computer and Information Science Linköping University, SE-58183 Linköping, Sweden {mikki, kevmc}@ida.liu.se http://www.ida.liu.se/~mikki/comics/JVLC_Kindborg_McGee_Paper_October_2006.p...
Interessanterweise zeigen sich hier auch die Grenzen der Kombination UML 2.0, JAVA, JBOSS, Eclipse, also des überall fälschlicherweise für äußerst "produktiv" gehaltenen Werkzeuges 'Rational Rose', nun IBM. Die Idee: Eine Heerschar von Programmierern schubsen lange Zeit grafisch nur Logiken auf dem Bildschirm zurecht, woraufhin dann Rose ein Code - Rohgerüst mit unzähligen Klassen, SQL - Strukturen ... auswirft, welche dann nur noch "händisch" ergänzt werden brauchen. JBOSS kümmert sich um die Verkapselung der Progrämmchen und Daten in Containern, welche dann auf der Suche nach freier CPU- Zeit durch das SUN-Netzwerk flitzen: "The net ist the computer!" IBM hat dieses Problem mit der Unvereinbarkeit von riesigen Datenmengen mit dem Design hinter JBOSS schon lange erkannt, bietet spezielle Maintraimes an, welche dann die typischen Performance - Dezifixe duch die Architektur auffangen. Problem - JAVA skaliert nicht so, wie gewünscht, jedenfalls nur unter bestimmten Voraussetzungen. Das gescheiterte Projekt FISCUS sollte allen eine Warnung sein.
'Things should be made simple, but not simpler!' - der Spruch von Einstein gilt auch für die grafische Programmierung. Natürlich sollte Programmierung so einfach gemacht werden, wie möglich, weswegen grafische Programmierung sicherlich zum 'state of the art' gehört. Squeak vereinigt auf wunderbare Weise diese beiden Welten. Man kann zwischen Kacheln und Programmcode hin - und herschalten, bzw. einige Skripte nur händisch in Smalltalk programmieren. Variblen aus EToys können einfach auch ausgelesen und mit Smalltalk Code verändert werden, Ausgaben von OO-Datenbankqueries erscheinen ganz einfach wieder in den Textfenstern, welche man sich aus dem Objektbaukasten an eine Stelle gezogen hat. Tippt man in ein Fenster eine Zahl ein, so landet diese unverzüglich in der OO-Datenbank, und zwar verändert sich der Zahlenwert in der OO-Datenbank während des Tippens kontinuierlich. Weil jeder Buchstabe, jede Ziffer ein eigenes Objekt ist, kann man sogar wie selbstverständlich zu mehreren an Texten schreiben. Völlige Transparenz also - keine Caches, keine Puffer, kein "OK-Button", der die Daten gesammelt aus der Maske in die Datenbank überträgt. Alles überflüssig. Auch kein 'kümmern' um Speicherverwaltung mehr. Das vereinfacht sehr die Programmierung. Ich lese immer wieder, daß viele bei Squeak nach Werkzeugen zur Programmierung einer GUI fragen. Von JAVA, .NET, KDE (Linux) her kommend hat sich bei Entscheidern ein völlig veraltetes geistiges Modell tief in die Hirne gebrannt. Man sucht nach einem 'GUI-Builder' der XML - Code mit einem Anschluß an die Event-Handler erzeugt. So würde beim Verschieben oder öffnen eines Fensters intern der XML - Baum modifiziert. Damit hat man erreicht, daß die GUI unabhängig vom eigentlichen Programm wird, womit Net-Computing dann wirklich beginnen kann. Interessanterweise wird gerade damit ein Konzept wieder neu erfunden, welches schon UNIX mit X-Windows seit ewigen Zeiten beherrschte, und den auch Squeak schon von Anfang an erfüllte.
Squeak hingegen ist da noch viel weiter im Design. Alles, was sichtbar ist, ist Objekt, (Text, Text, der Linien folgt, ...) ist drehbar, bewegbar, anfassbar, programmierbar, und diese Objekte lassen sich auch über Netzwerk verschieben. Nicht nur, daß man Menü's während der Bedienung sich dauernd drehen lassen kann, oder man den Schwierigkeitsgrad von Tetris erhöht, indem man das Fenster sich dauernd drehen läßt, oder das Menü wie ein Herz pochen läßt. Alles, was denkbar ist, kann gemacht werden, und diese Vielfalt ist so groß, daß man als erfahrener JAVA, C++, C#, DEPHI Programmierer ob dieser erschlagenen Vielfalt nur noch ins Staunen kommt, und in Squeak verzweifelt wieder nach den 'Primitives' der MFC sucht - nur es gibt sie nicht. Ganz Squeak mit Morphic ist GUI, in sich selber geschrieben. Nun - hier ist sogar Microsoft noch lange nicht angekommen. .NET ist nicht vollständig in .NET geschrieben, und schon garnicht Quellcode - offen.
Squeak läuft nicht nur in der neuesten OPLC als Plugin im Browser, sondern Squeak *ist* sowohl Programmier - Umgebung als auch GUI - Builder, als auch Debugger, als auch Anwendungsprogramm selber - es gibt keine Trennung. Bei der Microsoft - Architektur ist alles sauber getrennt, und durch Interfaces miteinander verbunden. Allein schon die Einarbeitung nur in die MAPI dauert schon länger (eigene Erfahrung), als die Einarbeitung in Squeak und das Erlernen von Smalltalk zusammen. Squeak ist natürlich auch Ersatz für Flash, bzw. sogar für Shockwave, und darüber hinaus noch viel einfacher zu programmieren. Man kann auch Flash 3 in Squeak ablaufen lassen, und mit Squeak sogar .swf generieren.
Risiken der Programmierung in Smalltalk mit Squeak? Smalltalk ist seit den 80er Jahren unverändert, riesige Bibliotheken (auch SOAP, ... Manipulation von XML-Bäumen, Interfaces aller Art) existieren, man stolpert über sie, wenn man sich z.B. Squeak und die Routinen im Image mal genauer anschaut ... Import eines XML - Baumes in eine OO-Datenbank? Hmmmm. Trivial. Anzapfen eines Datenstromes aus einer Datenbank, einem Webserver, einem FTP-Server, SOAP/RPC-Server? So trivial, daß noch nicht einmal ein Menü-Button in irgendeinem Anwender - Programm dafür existiert. Das ist *das* Manko in Squeak. Microsoft ist da viel geschickter. Allein schon zur Bedienung der SQL - Datenbank hat Microsoft ein irrsinniges Werkzeug geschrieben, wo dem Anwender suggeriert wird, damit beherrsche er nun alles. Nix ist. Schon bei etwas komplizierteren Queries kommt man nicht drumherum, sein eigenes Hirn zu quälen, man muss dann doch wieder die Grundlagen der relationalen Datenbankprogrammierung erlernen. Und wenn auch nur ein einziges Feld vom Typ her verändert werden muß, fliegen den Programmieren wieder Unmengen von Code um die Ohren. Hierin liegt das Geheimnis der effizienten Programmierung von großen Projekten mit Smalltalk begründet. Eine Untersuchung von IBM der 70er Jahren (Programmiersprache C, auch mit C++ zu vergleichen) hat ergeben, daß ein Programmierer je Tag nur ganze 5!!! Programmzeilen beiträgt, die dann auch im endgültigen Code verbleiben. Bei Smalltalk ist dies ein vielfaches höher. Refactoring wird stark vereinfacht. Natürlich unterstützt Squeak auch Unit-Testing. Unit-Tests kommen ja aus der Smalltalk - Umgebung, sie wurden für Smalltalk erfunden....
Ich denke, daß solche Dinge auch mal kommuniziert werden müssen. Angesichts der vielen kollektiven Irrtümer in der Entscheiderwelt sollten Smalltalk - Enthusiasten sich mal zusammen tun, und Fakten zusammentragen. Ergänzungen, Kritik zu meinen (vielleicht etwas verqueren) Ansichten always welcome....
Wünsche viel Spaß mit Squeak
Guido Stepken