[Squeak-ev] Semiotik: Grenzen der grafischen Programmierung mit Squeak - EToys

[stepken]

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.pdf

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