[Squeak-ev] Semiotik: Grenzen der grafischen Programmierung mit
Squeak - EToys
stepken
stepken at web.de
Mon Mar 19 12:53:47 UTC 2007
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