Thesen zur Hermeneutik einer Fehlermeldung (Christian Swertz)

Ich habe hier mögliche Nachfragen zu Herbert Hrachovecs Argumenten im Interesse eines Diskussionsanlasses formuliert:

Die Leitfrage zur Analyse einer Fehlermeldung lautet: "Welche Gedanken sind diesen Erfahrungen gewachsen?". Erfahrungen meinen dabei die Störanfälligkeit und Fehlbedienungen von Computern. Unter dieser Perspektive wird dann die Leistungfähigkeit phänomenologischer, metaphysischer, analytischer und hermeneutischer Methoden zur Analyse der gemachten Erfahrungen diskutiert. Die vorgestellten Methoden werden dann darauf untersucht, welchen Beitrag sie zum Verständnis der Fehlermeldung des Mailtransportprogramms (MTA) liefern können.

Meine Vermutung ist nun, dass hier ein Verstehen versucht wird, wo eine Erklärung dem Gegenstand angemessen ist. Diese Vermutung wird durch den Hinweis aus dem Text: "Natürlich hilft zum Verständnis streng normierter Vorgänge am ehesten formales Training." gestützt. Es handelt sich bei der Fehlermeldung um einen rein formalen Vorgang, der tatsächlich letztlich und vollständig erklärt werden kann, ohne dass irgend ein unaufklärbarer Rest bleibt. Allerdings wird dies deutlicher, wenn nicht wie im Text die Beschreibung des Protokolls im RFC, sondern das Protokoll selbst, also etwa der C++ Code aus KMail, analysiert wird. Anders als die Beschreibuntg Postels, die Vagheiten und Ungenauigkeiten enthält, ist der C++ Code - und in diesem Code ist die Ursache der Fehlermeldung formuliert, nicht in der Prosa Postels, die ein Computer ja eben nicht abarbeiten kann - den Bedingungen für Algorithmen entsprechend eindeutig. Daher ist die Annahme: "Die Kenntnis der Übertragungsprotokolle im internationalen Datenverkehr unterscheidet sich qualitativ nicht von Altphilologie." nicht ohne weiteres nachvollziehbar, da lateinische oder griechische Texte Vagheiten und Ungenauigkeiten enthalten, so wie das notwendig bei jeder natürlichen Sprache (und den meisten Fachsprachen) der Fall ist. Computersprachen dagegen sind eindeutig: Ein "print($err)->stdout;" hat eine völlig eindeutige Bedeutung. Da hier nichts zu verstehen ist, sind hermeneutische oder phänomenologische Methoden wenig aussichtsreich.

Ein wichtiger Punkt, aber ich widerspreche. Eine Fehlermeldung kann kein rein formaler Vorgang sein. Der Ausdruck enthält bereits den Bezug zu einem Normsystem und "abnormalem" Verhalten. Die Ausführung von Code durch die Maschine liegt tatsächlich auf einem anderen Niveau und hat nichts mit Fehlern zu tun: es läuft oder läuft nicht. Wenn ein RAM-Chip defekt ist, spricht man nicht von einem Programmfehler. Können wir uns darauf einigen: Die Abarbeitung von Codesequenzen kann auf Schwierigkeiten stoßen, die es nahelegen, eine Code-Ausgabe einzuprogrammieren, die für Betrachterinnen als Fehlermeldung deutbar ist.

Prinzipieller: Die Sichtweise, welche Datenströme als "Protokoll" ins Auge fasst, gehorcht anderen Regeln, als C++ Sequenzen. Zum Beispiel ist es angezeigt, die Zeilenfolge

220 phaidon.philo.at ESMTP Postfix

HELO politeia.philo.at

250 phaidon.philo.at

als Signale unterschiedlicher Maschinen zu interpretieren, obwohl sie das nicht sein müssen. Dabei geht es um die Berechtigung, formal definierte Sequenzen als "eMail" zu bezeichnen.

--anna 18:27, 4. Nov 2005 (CET)

Hiervon, und das wäre die zweite Vermutung, ist nun die Fehleranfälligkeit der Computertechnologie zu trennen. Aber auch in diesem Fall gilt, dass die Fehleranfälligkeit der Computertechnologie selbst kein ein interpretationsbedürftiges Phänomen ist, sondern durch den Umstand erklärt ist (ich hoffe ich erinnere das folgende richtig), dass die Überprüfung eines Algorithmus auf die Frage, ob es tatsächlich ein Algorithmus ist ein NP-hartes Problem ist, also nicht wieder mit einem Algorithmus gelöst werden kann. Anders gesagt: Computerprogramme können Computerprogramme nicht letztlich auf Fehlerfreiheit prüfen (syntaktische Prüfungen sind natürlich möglich). Darum werden Computerprogramme (fast) immer Fehler enthalten.

Die hier vermutete Verwechslung wird an folgender Passage besonders deutlich: "Befangen in der Zweckrationalität und den unbestreitbaren Erfolgen mechanisierter Prozeduren sind Ingenieure (und mehr noch: ihre philosophischen Fürsprecher) für historische und soziale Zusammenhänge blind. Daß die Technik selbst kein technisches Phänomen sei besagt: Sie kann nicht über die Zusammenhänge Auskunft geben, in denen ihr Zweck-Nutzen-Kalkül notgedrungen selber eingebettet ist. Sofern sie das versucht, stehen ihr nur dieselben - technischen - Mittel zur Verfügung." Hier scheinen Ingenieure mit Technik verwechselt zu werden. Denn Ingenieure können als menschliche Wesen kaum blind für historische und soziale Zusammenhänge sein und insbesondere durchaus Auskunft über diese Zusammenhänge geben (wie das z.B. beim FIFF) nachzulesen ist. Technik dagegen kann solche Auskünft nicht geben. Allerdings fehlt der Technik auch jedes Zweck-Nutzen-Kalkül. Technik verfolgt keine Zwecke - das machen nur Menschen, die allerdings ihre Zwecke durchaus in Technik (etwa in Büchern oder Wikis) ausdrücken können. Und das ist Interpretationsbedürftig.

---

zurück zu Ausbildungsformen der Wissensgesellschaft