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.
- Um zu verstehen, was hier abläuft:
- Connected to phaidon.philo.at.
- Escape character is '^]'.
- 220 phaidon.philo.at ESMTP Postfix
- HELO
- 501 Syntax: HELO hostname
- HELO politeia.philo.at
- 250 phaidon.philo.at
- muss man die Textfolge als Syntaxverstoss gemäß dem SMTP-Protokoll auffassen.
- 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.
- Der Unterschied ist an den Begriffen "Fehleranfälligkeit" und "Fehlermeldung" abzulesen. Eine Fehlermeldung ist per definitionem eine Mitteilung, während "Fehler" oder "Fehleranfälligkeit" auch Eigenschaften von Artefakten sein können. Die Sache mit "Technik ist kein technisches Phänomen" kommt aus der Heidegger-Tradition (die ich nur wiedergebe) und wirft ihre eigenen Probleme auf. --anna 12:57, 5. Nov 2005 (CET)
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.
- Im ersten Durchgang der Lektüre scheint es sich bei philosophischen Zugangsweisen zu einem technischen Thema um eine Themenverfehlung zu handeln. Einer an sich klaren Programmiersprache, steht ein ausgetüfteltes philosophisches Konzept gegenüber. Die Erklärung ist somit auch nahe liegend: Warum einfach wenn es kompliziert auch geht. Was eine Ablehnung und Schubladisierung nahelegt als: gut gemeint - Thema verfehlt.
- Das Problem liegt doch auf dem Desktop! Geht man den Text allerdings von hinten nach vorne durch, bemerkt man, dass es sich lediglich um ein "Ingenieursopfer" handelt, welches dazu dient, den eigenen Reihen die Leviten zu lesen. Das Kompetenzoutsourcing, auch im wissenschaftlichen Alltag scheinbar unumgänglich, macht aus den ehemaligen Patriarchen(m/w) des Verständnisses, erklärungs
bedürftigeabhängige "Admiratorinnen(m/w)" mirakulöser Phänomene, die, ungeachtet ihrer sonstigen Systemadministrationskompetenzen, vor einfachsten "Protokollismen" kapitulieren.
- Ein anderer Versuch: Um Tanzen zu lernen, muss man nicht erst gehen lernen, würde mensch doch wohlmeinend zugestehen. Dass Tanzen Kompetenz im aufrechten Gang voraussetzt allerdings ebenso. Ähnliches scheint mir hier vorzuliegen: Ein primär utilitaristisches Verständnis einer Fehlermeldung, wird die Kluft zwischen Innen und Außen weiter vergrößern. Sicherlich kann eine einfache Erklärung in speziellen Fällen mehr bringen als ein üppiger Systementwurf. Bei aller Notwendigkeit solcher Rasuren - Der Weg der Abkürzung führt im vorliegenden Fall in eine Sackgasse.
- Die wohlmeinende Erklärung schließt, wie oben schon erwähnt, ein Normensystem mit ein, das es gilt zu hinterfragen - denn Unwissenheit schützt bekanntlich nicht vor Spam und anderen Ausgeburten einfacher Postübertragungsprotokolle. Alternativ dazu könnte man auch sagen: "Ich tanze nicht" (Zit.: Lukas Resetarits)- lieber mokiert man sich jedoch in gekrönter Blätterweise über die mangelde Integrationsfähigkeit terrestrischer Elektronenzustände...
--Koe 11:45, 7. Nov 2005 (CET)
Die Diagnose ist völlig zutreffend: von Ingenieuren ist die Rede, es geht aber um die Kolleginnen (m/w) der Geisteswissenschaften. --anna 15:44, 7. Nov 2005 (CET)
