Re: [rohrpost] Nachtrag zum bootlab

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

Am Freitag, 31. Januar 2003 um 17:33:17 Uhr (+0100) schrieb Stefan
Heidenreich:

[quoting Mercedes Bunz]

> >mit dieser "regression", macht man es sich da nicht zu einfach? die
> >annahme, dass man auf assembler code "näher dran" ist, ist doch mehr
> >als zweifelhaft.
>
> näher dran wohl: an den operationen des prozessors. was nicht heisst,
> dass dann der "wald-vor-lauter-bäumen-nicht-sehen"-Effekt (WVLBNS stat
> WYSIWYG) nicht auftritt.
>
> >lungert da nicht im hintergrund schon wieder so ein schimmelige
> >"wesenhaftigkeit" der maschine, die wir doch alle eigentlich los
> >werden wollen?
>
> da wir alle mit der "maschine" arbeiten, sehe ich - einfach gesagt -
> zwei möglichkeiten: entweder wir versuchen zu wissen, wie sie läuft,
> oder sie läuft uns davon. das hat mit "wesen" - also dem, was etwas
> ist - durchaus etwas zu tun, auch ohne die emphase der ontologie.

Ä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.  Ein
Essentialismus, in dessen Falle meiner Meinung nach Kittler und seine
Schule geraten sind.

Andererseits stimme ich zu, daß graphische Benutzeroberflächen - egal
ob Windows, MacOS 9/X, KDE oder Gnome -, regressiv sind.  Definiert
man Computer als Maschinen zur Automatisierung von Arbeitsabläufen
durch Programmierung, so regredieren heutige GUIs den Computer zu
einem recht stupiden, nur manuell bedienbaren Werkzeug.  Es gibt zwar
Scripting-Engines auch für die o.g. Systeme, aber sie sind einer
manuellen Bedienlogik nur extern aufgeschraubt, vergleichbar etwa mit
einem Arsenal von Aufschraub-Motoren für die einzelnen Werkzeuge eines
Taschenmessers.  Eine Unix-Shell hingegen ist bereits in sich ein
vollwertiger Programm-Interpreter (wie z.B. BASIC oder Perl), in der
Programmierung keine esoterische Geheimwissenschaft ist, sondern ganz
simpel das Abspeichern einer Reihe von Kommandos in eine Textdatei, die
man später wieder ausführen kann, um sich ihre wiederholte Eingabe zu
sparen.



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. Ob die Programmiersprache nun Assembler,
bourne shell, LISP oder meinetwegen auch BASIC heißt, ist dabei leztlich
egal, denn jede von ihnen ist ein Weg, der zum selben Ziel führt (es sei
denn, man programmiert zeit- und speicherkritische Anwendungen), und
jede von ihnen basiert letztlich auf denselben Strukturen: Variablen,
Operatoren, Schleifen, if/then-Bedingungen.

Über den sinnvollen Grad der Abstraktion von der Hardware - oder sogar
vom Software-Betriebssystem - kann man sich immer streiten. 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, aber das Intel-Monopol, eine
ablösungsreife Chip-Architektur und eine klobige PC-/Laptop-Monokultur
ewig zementieren. Eine Sprache wie C hingegen ist noch so hardwarenah,
daß sie oft "portabler Assembler" genannt wird, und erlaubt schnelle
und effiziente Compilate, die gleichzeitg plattformunabhängig sind. Für
Betriebssysteme wie Linux und NetBSD, die dank C auf aller möglichen
Hardware vom Intel-PC über PowerMac bis zum Mainframe und PDA laufen,
ist dies ein handfester Vorteil. Und gegenüber C bieten wiederum höher
abstrahierende Sprachen wie LISP bessere Absturzfestigkeit, vor allem
Resistenz gegen buffer overflows, die heute die häufigste Ursache von
Software-Sicherheitslücken sind.

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. Daraus einen Ikonoklasmus oder
Graphophobie abzuleiten, wäre aber voreilig: Wie Experimente mit
Flußdiagramm-artigen Programmierumgebungen zeigen, sind auch Interfaces
denkbar, in denen graphische Steuerung und Programmierbarkeit kein
Grundwiderspruch sind, und die ihre Benutzer nicht zu Anklick-Sklaven
entmündigen.

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. Ob ein Computer auf Quecksilbertanks, Röhren, Transistor-Chips oder
- wie im Bostoner Computermuseum - Besenstangen basiert, ist dabei zwar
(medien- und diskurshistorisch) nicht uninteressant, aber nicht von
essentieller Bedeutung.

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