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

[wintermute@tessierashpool.net]

Guten Tag, liebe Liste.

> Ähnlich wie Mercedes sehe ich hier die Gefahr eines Platonismus mit
> umgekehrten Vorzeichen, in dem die Hardware Essenz ist und die Software
> mit ihren Abstraktionsschichten verderbter Abglanz dieser Essenz.

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". Und Linux-PCs haben ganz 
andere Wesen als WinXP-PCs. Linuxkisten sind aufsässige Bastarde, 
Windowsrechner hinterfotzige Schleimer.

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. Und deswegen hängt das Was-es-ist-ein-mac-zu-sein nicht davon 
ab, ob ein G4 oder ein Pentium oder ein kleiner Geist in der Kiste 
steckt und rechnet, oder ob ein Unix oder Windowskernel darunter läuft. 
Das gefühlte (also einzige) Wesen einer Maschine ist ihre 
Benutzeroberfläche und damit ihre tatsächliche Nutzung.

> 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? Eigentlich sind die meisten Werkzeuge nur 
manuell bedienbar. Aus gutem Grund.

> 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. Und wenn man Computer als Werkzeuge begreift, frage ich mich, 
warum es regressiv sein soll, aus dem weiten Raum des Machbaren das 
Sinnvolle vorzuselektieren. Genau darum geht es bei Werkzeugen: Ein 
Ding zu haben, das eine Aufgabe erfüllen kann. Ein wirklich 
universelles Werkzeug ist keines, weil es die Welt ist, aka "das 
Machbare". Werkzeuge haben immer eine inhärente Richtung, eine Antwort 
auf ein Wozu.
So sind die eben :-)

Dass Computer sehr universelle Werkzeuge sind, weil zumindest in ihnen 
alles machbar ist, was überhaupt machbar ist, ist ein schlechter Grund, 
um über Point&Click-GUIs die Nase zu rümpfen. Denn die sind da, um 
Werkzeug zu sein, also um bestimmte Dinge nicht zu können und andere 
schneller und besser. Ist doch wunderbar.

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?

> 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 gibt die Abstraktion von der Hardware nur beim Erzeugen des Codes, 
nie bei der Ausführung. Und dass Java in VMs läuft und es keine guten 
Nativecompiler gibt, ist Politik, keine Notwendigkeit aus der JLS oder 
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.

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

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. Den 
Turingmaschinenfreund möchte ich sehen, der beim Verschieben eines 
Verzeichnisses darauf besteht, ausschliesslich an 
Dateizuordnungstabellen zu denken.

> Keine echte (d.h. Turing-vollständige) Programmiersprache bzw. 
> -umgebung
> kann vom Prinzip des Computers so stark abstrahieren, daß dabei das
> Grundverständnis einer Maschine, die algorithmische Instruktionen
> ausführt und somit formale Sprachen "spricht", verlorengehen könnte. 
> Und
> nur auf dieses strukturelle Verständnis kommt es meiner Meinung nach
> an.

Wir sprechen von Turingvollständigkeit, also vom Begriff der 
Berechenbarkeit. Wenig überraschend, dass nur berechenbar ist, was man 
berechnen (aka durch algorithmisches Ausführen von Instruktionen 
ermitteln) kann. Natürlich können formale Beschreibungssprachen für 
Instruktionen davon nicht abstrahieren.

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

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.

Und deswegen gibt es ja auch schon gute Lösungen. Mac Human Interface 
Guidelines für die einen, Anti-Mac für die andern. Aber trotzdem: Nie 
und nimmer turingvollständig auf Ebene null.
Nun: Bedienen ist Programmieren, d'accord. Für alltägliche Probleme wie 
das Manipulieren von Daten haben wir schnelle Lösungen: Betriebssysteme 
mit GUIs - das ist alles andere als eine "Versklavung". Es kommt uns 
bloss ein bisschen eng vor, weil's ausgerechnet ein Büro sein muss, und 
weil Microsoft unter Verbesserung der Bedienqualität versteht, das alte 
Büro bunt anzumalen. Und bunt Anmalen macht aus einem Plattenbau keine 
schöne Wohnstatt und aus einem Büro keine angenehme Metapher.


mfg, rv
-------------------------------------------------------
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/