Florian Cramer on Sat, 1 Feb 2003 16:00:20 +0100 (CET) |
[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]
Re: [rohrpost] Nachtrag zum bootlab |
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/