Re: [rohrpost] In bash ist Wahrheit (war: Nachtrag zum bootlab)

[Florian Cramer <cantsin@zedat.fu-berlin.de>]

Danke an den anonymus für die interessante Rückmeldung!

> Das Wesen einer Maschine die Hardware? Das passt offensichtlich       
> nicht.  Eine kleine Umfrage unter Bekannten nach der differentia      
> specifica zwischen Macs und PCs bringt sicher nicht "G4/Pentium" aufs 
> Tablett, sondern "Ist schöner / hab ich auch im Büro".                

Klar, wenn Du die pragmatische und ästhetische Brille aufsetzt, und
nicht eine ontologische.

> Eben weil beim Sprechen über Computer-Wesen Ontologie-Emphase völlig 
> krude wäre, kann es nur um das gefühlte Wesen einer Bedienoberfläche 
> gehen. 

Einverstanden, wenn wir "gefühlt" noch um "gedacht" ergänzen. Es geht
nicht nur um Empfindung, sondern auch darum, daß man den Computer auf
intelligente oder sogar intellektuell elegante Weisen nutzen kann, die
Bedienoberfläche also dem schnellen Denken so wenig wie möglich im Weg
steht. Daß es dafür keine Pauschallösungen geben kann, unterschreibe ich
aber sofort.

> >regredieren heutige GUIs den Computer zu einem recht stupiden, nur
> >manuell bedienbaren Werkzeug.
>
> Im Gegensatz zu früheren Computern, wo man Lochkarten mit den Füssen  
> oder reinem Geist stanzte?                                            

Nein, diese Position (und auch die o.g. Ontologie) vertrete
ich nicht, wie aus meiner vorigen Antwort hoffentlich klar
geworden ist. Vielmehr: Im Gegensatz zu einem Login- oder
Hintergrund-Skript, das beim Rechnerstart automatisch ausgeführt wird
und in einem Rutsch erledigt, wozu man auf einem GUI zwei dutzend
Cursor-Feinpositionierungen und Mausklicks braucht. (Hier etwa: ssh-Keys
initialisieren, einen verschlüsselten Tunnel zum POP3-Server aufbauen,
alle E-Mail abholen und danach im 3-Minutentakt überprüfen und durch
Sortier- und Spamfilter schicken, diverse Nutzerprogramme mit neuen
Standardoptionen versehen und ggfs. starten...) Meine persönliche
Definition von Nutzerfreundlichkeit.

> Eigentlich sind die meisten Werkzeuge nur 
> manuell bedienbar. Aus gutem Grund.

Da war meine Wortwahl nicht ganz glücklich. Also probiere ich
es so: Ein Werkzeug ist dann gut, wenn es möglich wenig Handgriffe
erfordert bzw. redundante/stupide Handarbeit eliminiert. Computer sind
dafür bestens geeignet, es sei denn, sie stellen keine schlechten Interfaces in den Weg.

> >Der springende Punkt eines Computerinterfaces (zu denen ich auch
> >Programmiersprachen zähle) ist für mich deshalb nicht die Abstraktion
> >vom Maschinencode, sondern die Frage, ob es algorithmisch 
> >programmierbar
> >bzw. Turing-vollständig ist.
> 
> Unglücklicherweise entfesselt Turing-Vollständigkeit die ganze 
> Komplexitätshölle der theoretischen Informatik. Nicht nur, dass sich 
> nicht alles in endlicher Zeit machen lässt, von den Sachen, die sich in 
> endlicher Zeit machen lassen, sind nicht unbedingt viele gerade sehr 
> sinnvoll. 

D'accord, auch Kittler schreibt dies in seinem Aufsatz "Hardware, das
unbekannte Wesen". Am Begriff der Turing-Vollständigkeit interessiert
mich aber nicht die Idee n-komplexer Berechnungen, sondern ganz
simpel und pragmatisch die Unterscheidung von Computersprachen bzw.
Softwareumgebungen, in denen man programmieren kann und solchen, mit
denen das nicht oder nur begrenzt geht; also BASIC/Pascal/C/Java/Unix
Shell/Perl/Python/LISP/Logo... versus z.B. HTML und eben die heute
üblichen GUIs. (Auch das Ur-Smalltalk-GUI von Alan Kay erzwang einen
medialen Bruch von der graphischen Oberfläche zur Texteingabe, wenn
man programmieren wollte. Die Vorstellung, daß Programmieren eine
esoterische Insider-Angelegenheit sei, enstand erst durch diese
künstliche Grenzziehung zwischen "Bedienung" und "Programmierung". Gegen
objektorientierte Programmierung könnte man noch eine Menge anderer
Dinge sagen - z.B. daß sie Software in "Dependency-Höllen" treibt und,
wie von Windows bekannt, instabil macht - so daß sich mir jedesmal die
Fußnägel aufrollen, wenn Kay von Medientheoretikern als "Vater des
modernen Computers" tituliert und mit Kunsthochschul-Preisen versehen
wird.)

> Und wenn man Computer als Werkzeuge begreift, frage ich mich, 
> warum es regressiv sein soll, aus dem weiten Raum des Machbaren das 
> Sinnvolle vorzuselektieren. 

Die Frage ist nur, wer selektiert, was "sinnvoll" ist, und wem dies
vorgeschrieben wird. 

Ein Beispiel für mitlesende Nicht-Unixer: In GUIs läßt man sich den
Inhalt eines Dateiverzeichnisses per Ordner-Fenster anzeigen, auf der
Unix-Kommandozeile mit dem Befehl "ls". Will man die Dateiliste nicht
nur auf dem Bildschirm betrachten, sondern auch ausdrucken, muß man in
einem GUI darauf hoffen, daß der Programmierer ein Druckmenü in den
Dateimanager eingebaut hat. Wenn nicht, hat man Pech gehabt (oder muß
Screenshots anfertigen und ausdrucken, was aber spätestens dann nervt,
wenn der Bildschirm zu klein ist, um alle Dateien anzuzeigen). In Unix
lautet der Druckbefehl "lpr".  Um die Dateiliste auszudrucken, muß
lediglich die Ausgabe von "ls" an "lpr" geschickt werden, und zwar
so: "ls | lpr". Alternativ kann man die Ausgabe auch in eine Textdatei
sichern: "ls > dateiliste.txt".

Will ich als Benutzer die Ausgabe von "ls" als HTML mit Hyperlinks für
jede Datei codieren, muß ich dafür nicht "ls" umprogrammieren und mit
einem HTML-"Feature" versehen, sondern lediglich seine Ausgabe durch 
einen Suchen-und-Ersetzen-Filter schicken: 
ls -1 | sed -e "s/.*/<a href=\"&\">&<\/a><br>/" > dateiliste.html

In einem GUI müßte der HTML-Export als Funktion extra einprogrammiert
werden, und um je mehr solcher "Features" es wüchse, desto
unübersichtlicher und resourcenhungriger würde es werden, wie von
Macintosh, Windows, KDE und Gnome hinlänglich bekannt.

> Genau darum geht es bei Werkzeugen: Ein 
> Ding zu haben, das eine Aufgabe erfüllen kann. Ein wirklich 

...und in der Kombination mit anderen Werkzeugen und sinnvollen
Kontrollstrukturen (wie Schleifen, Pipes etc.) multifunktional zu
werden.

> Allerdings, das freimütig zugegeben: WAS uns die heutigen 
> Point&Click-GUIs anbieten, wozu sie Werkzeuge sind, ist scheusslich: 
> Büro, Büro. Ordner und Mülleimer und Schreibtische und Dokumente und 
> all dieser graue lebensfeindliche Altherrenkram. Büroknechtschaft ist 
> angesagt, unsere GUI-Hersteller, ganz egal wie frei oder GPL, lassen 
> keinen Zweifel aufkommen. Desktopmetapher und kein Ende abzusehen. Wo 
> bleiben die guten Alternativen?

Wie wäre es mit einem System, mit dem die Nutzer auch ihre eigenen
Metaphern und Werkzeugkombinationen bilden könnten, egal ob in
Gestalt der Unix-Kommandozeile oder nach dem Modell graphischer
Programmierumgebungen wie z.B. den Musik-Kompositionssystemen MAX und
PD?

> >Zuviel Abstraktion (Beispiel Java) führt zu absurd lahmer, 
> >speicherfressender
> >Bloatware, zuwenig (Assembler) zu nichtportablem, CPU-proprietärem
> >Code. Wäre alle heutige PC-Software in x86-Assembler geschrieben,
> >würde sie zwar schneller laufen.
> 
> Veto. Nicht mal das. Wenn sie je fertig würden, wären sie so 
> bugverseucht, dass sie nur sehr kurz schneller laufen würden.

Es sei denn, es handelt sich um _sehr_ überschaubare Programmgrößen. Zu
einem gewissen Grad gilt, was Du beschreibst, ja schon für den
Mainstream von in C und C++ geschriebener Software.

> Es gibt die Abstraktion von der Hardware nur beim Erzeugen des Codes, 
> nie bei der Ausführung. 

Einspruch. Ein GUI-Programm z.B. malt auf dem Window-Server
(Windows: GDI, MacOS X: Quartz, Linux: X11), der von der Hardware
der Graphikkarte abstrahiert, indem er sich als virtuelle
Einheits-Graphikkarte verhält. Das ganze Betriebssystem ist eine
Abstraktionsebene von der Hardware, die der Software einheitliche (und
somit vom individuellen abstrahierte) Input-/Output-Kanäle zur Verfügung
stellt. Sobald der Code ausgeführt wird, passiert er alle Schichten des
Betriebssystems und seiner aufgesattelten Software-Layer und wird nach
unzähligen Umcodierungen schließlich an die Hardware durchgereicht. Nur
dies erlaubt es ja, z.B. eine Audiodatei auf jeder vom Betriebssystem
unterstützten Soundkarte auszugeben, und zwar egal, mit welchen Chips
sie arbeitet.

Im Falle einer JVM abstrahiert die Laufzeitumgebung nicht nur von der
Hardware, sondern auch vom individuellen Betriebssystem und vom GUI,
so daß z.B.  Graphikausgaben erst auf das Graphik-Interface der JVM
(also Swing/AWT) geschickt werden, dann von JVM in die Routinen für den
Graphik-Abstraktionslayer des drunterliegenden Betriebssystems und erst
dann in die Hardwarebefehle der Graphikkarte übersetzt werden.


> den APIs. Aber das nur nebenbei. Abstraktion ist ohnehin kein Argument, 
> weil GUIs keine Abstraktion von der Hardware sind, sondern ein 
> Ausschnitt aus deren Funktionalität.

Das hängt davon ab, ob man als GUI nur die Bedienoberfläche
betrachtet oder auch das graphische Subsystem. Legt man zweitere
Definition zugrunde, so abstrahieren alle mir bekannten GUIs von der
Graphikausgabe und in den meisten Fällen (MacOS und Windows) auch
von der Druckerausgabe, so daß Programme keine Hardware-spezifischen
Graphik- und Druckroutinen mehr enthalten müssen. Für viele Anwendungen
(Desktop Publishing z.B.) ist diese Abstraktion auch sehr nützlich.

> >Die Regression heutiger Interfaces zeigt sich nicht in der Abstraktion
> >der Software von der Hardware, sondern vielmehr darin, daß das
> >Benutzerinterface die Sprache des Computers auf ein vorsprachliches
> >Zeigen auf Objekte reduziert.
> 
> Nur mit Zeigen ist kein Computer zu bedienen. Deswegen neigen die 
> Dinger dazu, Tastaturen zu haben und Beschriftungen an den 
> Ordnersymbolen, also Elemente, die so sprachlich sind, dass sie auf 
> Buchstaben basieren. Aber selbst wenn da keine Buchstaben wären: 
> Vorsprachlich sind GUIs nicht. Sie sprechen eben, anders als die pure 
> Mathematik turingvollständiger formaler Sprachen, nicht alle Sprachen 
> gleichzeitig, sondern nur ihre eigene, graphische.

...die aber - in ihrer heutigen Mainstream-Form - restringiert ist,
weil sie keine anständigen syntaktischen Verknüpfungen kennt.  (Ok, ich
korrigiere "vorsprachlich" zu "babysprachlich", was ich auch so gemeint,
aber nicht präzise genug ausgedrückt hatte.) Das Problem ist, daß diese
vermeintliche Vereinfachung in Wirklichkeit zu Komplexitätswucherungen
führt. Weil es keine fähige Syntax gibt, mit der man wenige Wörter
(bzw.: Desktop-Objekte) für alle möglichen Anwendungsfälle kombinieren
kann, muß man für jeden Anwendungsfall ein neues Wort (bzw. Objekt)
erfinden.

Dieses Dilemma des objektorientierten Interfaces wurde schon vor
fast 300 Jahren von Jonathan Swift erfaßt und im Lagado-Kapitel von
"Gulliver's Travels" wie folgt beschrieben:

   Viele der Gelehrtesten und Weisesten sind jedoch
   Anhänger des neuen Projekts, sich mittels Dingen zu äußern; das
   bringt nur die eine Unbequemlichkeit mit sich, daß jemand, dessen
   Angelegenheiten sehr umfangreich und von verschiedener Art sind, ein
   entsprechend größeres Bündel von Dingen auf dem Rücken tragen muß,
   falls er es sich nicht leisten kann, daß ein oder zwei starke Diener
   ihn begleiten. Ich habe oft gesehen, wie zwei dieser Weisen unter
   der Last ihrer Bündel fast zusammenbrachen, wie bei uns die
   Hausierer. Wenn sie sich auf der Straße begegneten, legten sie ihre
   Lasten nieder, öffneten ihre Säcke und unterhielten sich eine Stunde
   lang; dann packten sie ihre Utensilien wieder ein, halfen einander,
   ihre Bürden wieder auf den Rücken zu nehmen, und verabschiedeten
   sich.

   Für kurze Gespräche aber kann man das Zubehör, um sich hinlänglich
   auszustatten, in den Taschen und unter den Armen tragen, und zu
   Hause kann man nicht in Verlegenheit kommen. Deshalb ist auch das
   Zimmer, wo Leute zusammenkommen, die diese Kunst ausüben, voll von
   allen griffbereit daliegenden Dingen, die erforderlich sind, um
   Material für diese Art künstliche Unterhaltung zu liefern.
   [...]

> Das Klicki-Bunti-Argument war mir nie einsichtig. Wir sind optische 
> Tiere, keine aufrecht gehenden Taschenrechner. Schon eine simple Sache 
> wie das Verschieben eines Verzeichnisses können wir, egal wie sehr wir 
> unseren Unixprompt mögen, nicht anders denken denn als ein 
> "Verschieben", ein räumliches Bewegen von A nach B. 

...weswegen sie ja auch auf dem Unixprompt "mv" für "move" heißt (man
sie als eingefleischter Unixer aber dennoch mit dem Umbenennen von
inodes assoziiert). Gegen Buntheit und Klicken ist nichts zu sagen,
nur gegen Syntax-Verkrüppelungen in ihrem Namen. 

Warum sollte ein Interface jemanden daran hindern, die räumliche
Vorstellung vom Verschieben z.B. mit der des Suchens logisch zu
verknüpfen, etwa durch ein Verschieben aller Dateien, die größer sind
als 1 Megabyte und in den letzten 24 Stunden verändert wurden, in einen
Ordner "xy":

mv `find -mtime 1 -size +1000k` xy/

> Den Turingmaschinenfreund möchte ich sehen, der beim Verschieben
> eines Verzeichnisses darauf besteht, ausschliesslich an
> Dateizuordnungstabellen zu denken.

S.o. - Der Turingmaschinenfreund könnte aber auf die Idee kommen,
die o.g. Aktion wiederholt in bestimmten Intervallen und unter
bestimmten Bedingungen auszuführen, und dafür braucht er algorithmische
Kontrollstrukturen, vulgo eine Programmiersprache. (Auch wenn man sie
nicht so nennt und sie nicht als Schriftsprache auf dem Bildschirm
erscheint.)

> Die interessante Frage ist doch: Muss man, um mit Computern zu
> arbeiten, /sehen/, dass algorithmisch Instruktionen ausgeführt werden,
> um nicht regressiv zu sein?

Nein, aber man muß die Algorithmen zumindest als Option auch selber
bauen dürfen, anstatt nur vorgefertigte Algorithmen als Blackbox
"nutzen" zu dürfen. Und dafür sollte im Interface keine künstliche
Schranke eingebaut sein. Das Interface selbst sollte den Bau von
Algorithmen ermöglichen, und zwar so, daß "Programmierung" eine
quasi natürliche Erweiterung der "Bedienung" ist. Mit klassischer
Schriftsprache, die nunmal syntaktisch besonders ausgefeilt ist und
Abläufe gut abstrahieren kann, geht dies - siehe Unix oder z.B.
LISP-Maschinen - zwar besonders einfach, effizient und elegant; aber das
schließt ja andere Ansätze nicht aus.

Mit der LOGO-Programmiersprache gibt es z.B. ein gutes Konzept,
und in alten Homecomputer-Zeiten war selbst BASIC keine Hürde für
Computerlaien. Ich erinnere mich gut an Computerabteilungen von
Kaufhäusern in den 1980er Jahren, in denen nachmittags Kinder
herumhingen und die ausgestellten C64, Atari 800XL, ZX Spectrum (wie
sie jetzt gerade in jodis Berliner Ausstellung zu sehen sind) und
MSX-Computer per BASIC bunte Graphiken generieren ließen. Diese Kinder
waren keinen Deut gebildeter, klüger oder sozial privilegierter als
jene, die heute in denselben Abteilungen Konsolenspiele spielen.

Das Problem ist, daß heutige Mainstream-Benutzerinterfaces keine simplen
Programmiermöglichkeiten bieten. Es gibt nur in sich abgeschlossene
Programmierumgebungen, die einem beim Maßschneidern und Verbessern der
Betriebssystemumgebung, mit der man täglich arbeitet, wenig oder gar
nicht helfen.

> Ist es nicht weit interessanter, Sachen zu beschreiben, die keine 
> Algorithmen sind, und trotzdem kommt am Ende ausführbare Software 
> heraus? Wie kriegt man Übersetzer hin, die die Art, wie Menschen 
> Probleme lösen, in Computercode übersetzen, anstatt einfach von den 
> Menschen zu verlangen, in Perl (oder bash) zu denken? Zugegeben, keine 
> besonders originellen Fragen.

Ich halte sie für nicht wirklich lösbar. Formale Sprachen unterscheiden
sich nun einmal von nichtformalen Sprachen wie Deutsch. Ich finde es
nicht hilfreich, dies zu kaschieren und den Computer pseudo-menschlich
agieren zu lassen (wie etwa Eliza oder ein programmgewordenes Ärgernis
wie Microsoft Word, das mir hartnäckig unterstellt, ich wolle "Fontäne"
statt "Fontane" schreiben). Was aber nicht heißt, daß man formale
Sprachen nicht so konstruieren kann, daß sie für Menschen gut verwendbar
sind. 

(Und wer glaubt, Assembler sei die "Sprache der Maschine", ist sowieso
gründlich auf dem Holzweg. Es ist nur eine arbiträre Programmiersprache,
die die Ingenieure des jeweiligen Chipherstellers entworfen und mit
der Hardware verdrahtet haben. x86-Assembler z.B. korrespondiert mit
der internen Architektur heutiger Intel- und AMD-Chips schon seit
langem nicht mehr und ist bloß eine Abstraktionsschicht, die die Chips
kompatibel zu ihren Vorgängern macht).

Gruß,

-F
-- 
http://userpage.fu-berlin.de/~cantsin/homepage/
http://www.complit.fu-berlin.de/institut/lehrpersonal/cramer.html
GnuPG/PGP public key ID 3200C7BA, finger cantsin@mail.zedat.fu-berlin.de
-------------------------------------------------------
rohrpost - deutschsprachige Liste zur Kultur digitaler Medien und Netze
Archiv: http://www.nettime.org/rohrpost http://post.openoffice.de/pipermail/rohrpost/
Ent/Subskribieren: http://post.openoffice.de/cgi-bin/mailman/listinfo/rohrpost/