2010-01-28 digital life Software und Komitees Wie es sein sollte Gute, weitverbreitete Software wird oft standardisiert. Die bekanntesten Beispiele sind ANSI bzw. ISO C und POSIX. Standardisierung ist gut für die Portabilität. Sie verhindet unnötige Inkompatibilitäten. Sie bündelt die Anstrengungen der Community, denn sie definiert die Richtung. Ich finde Standardisierung gut ... aber ... Ich will darauf eingehen, wie gut die Standards sind, und was oft schief läuft. (Das Thema der Unabhängigkeit der Standardisierungsorganisa- tionen, das vor allem bei Microsofts Office Open XML Dokumentfor- mat aufkam, will ich außen vor lassen.) Ein Standard sollte nie definieren wie etwas zukünftig gemacht werden sollte. Er sollte definieren, wie man es bisher macht. Es muss um existierendes Verhalten gehen, das dokumentiert wird, nicht um neues Verhalten das festgelegt wird. Der C-Standard ist dafür ein gutes und ein schlechtes Beispiel. Er dokumentiert das Verhalten das sich im Laufe der Jahre entwickelt hat. C war fertig (darüber lässt sich streiten) als es standardisiert wurde und im Standard ist fast ausschließlich beschrieben wie C zu dem Zeitpunkt war. Das schlechteste im Standard sind mit Sicherheit die Trigraphs. Sie sind etwas das vom Standardisierungskomitee oben drauf gep- fropft wurde. Ich habe nie von jemandem gehört der je einen Tri- graph verwendet hätte, und menschenlesbar sind die Dinger sowieso nicht. Es mag ja ganz nett gewesen sein, dass jemand an die Problematik gedacht hat, doch das Mittel Trigraph ist schlichtweg unpraktika- bel. Sowas kann nur von Theoretikern kommen. Ein Praxisversuch hätte die Unnützigkeit der Trigraphs gezeigt. Die Folgen ihrer Einführung sind jedoch weitreichend. Jeder C- Programmierer muss nun sehr vorsichtig sein, wenn er zwei Fragezeichen hintereinander im Code hat. Dagegen ist ihr Nutzen heutzutage null. Ein anderes Beispiel: Common Lisp. (Leider weiß ich das meiste nur vom Hören-Sagen und aus Büchern. Ich hoffe ich erzähle nichts Falsches.) Lisp gab es in vielerlei Gestalten, die sich zum Teil stark un- terschieden. Common Lisp war der Versuch *ein* Lisp zu definieren. Das Ziel wurde erreicht, doch das wichtigste blieb auf der Strecke: Die pure, direkte Eleganz. Die einzelnen Lisp-Dialekte waren put, direkt, eleganz, aus einem Guss, praxiserprobt und gut so wie sie waren. Dann kam das Stan- dardisierungskomitee, warf alles in einen Topf, ergänzte, rührte um, und heraus kam Common Lisp. Leider fühlt sich Common Lisp nicht mehr so an wie die Lisp- Dialekte aus denen es entstand. Es ist wie eine Porsche, einen Ferrari, eine Corvette, und einen Jaguar zu nehmen und zu einem einzigen Sportwagen zu machen. Heraus kommt halt kein Fahrzeug das sich anfühlt wie jeder einzelne, aber zugleich. Was herauskommt ist eine Grausuppe, ein fetter Van der ein Sportwagen sein will. Er ist voll gefedert, natürlich, doch man wundert sich warum man die Straße unter dem Sitz nicht mehr spürt. Er ist nicht mehr pur, denn er besteht nicht mehr nur aus einem. Er ist nicht mehr direkt, denn er wurde komfortabler gemacht. Und er ist auch nicht mehr elegant -- ihm fehlt der Charakter. Gancarz schreibt in ``The Unix Philosophy'' ebenso Tragisches über die Standardisierung von X. Am Anfang war es ein flottes, sportliches, direktes Windowing-System. Nach der Standardi- sierung war X fett, träge, bloated. Standardisierungskomitees sollten deshalb keine Software *de- finieren*, weil sie andere Ziele verfolgen. Bei ihnen geht es darum Recht zu haben, es geht darum einen eignen Vorschlag im Standard zu sehen, es geht darum zu formen ... und alles abgeschottet in einem praxisfernen Raum am Tisch. Manchmal läuft es gar nicht so schlecht, wie am Beispiel von C. Da ist immer dann so, wenn der Standard existierendes Verhalten beschreibt. So sollte es sein. Trotzdem ist es möglich, neues Verhalten zu ``standardisieren'', wenn man es richtig macht. Die IETF macht es richtig. Schon der Name ``Request For Comments'' (RFC) zeigt das Vorgehen auf: Jemand macht einen Vorschlag und dieser wird öffentlich disku- tiert. Das führt, in grober Übereinkunft, zu einem vorläufigen Ergebnis. Dann jedoch zeigt die Praxis, ob sich der Vorschlag bewährt, wo Fehler liegen, und was geändert werden sollte. Erst die Akzeptanz durch die Praxis qualifiziert den Vorschlag als Standard. Letztendlich wird wieder existierendes Verhalten dokumentiert, doch es lassen sich Anstöße für neues Verhalten bewusst geben. Standardisierung ist ein sehr heikles Thema; vor allem ist es auch ein sehr politisches. Da für ein Standardisierungskomitee gegebenermaßen *nicht* die Qualität des Ergebnisses an erster Stelle steht -- so sollte es sein, doch es ist leider nicht so -- muss sein Einfluss auf die Qualität des Ergebnisses möglichst beschränkt werden. Die Qualität sollte von denen bestimmt wer- den, denen es an erster Stelle um die Qualität geht. Das Komitee sollte nur existierende und genutzte Software beobachten und ihr Verhalten dokumentieren. Der Knackpunkt ist dann was spezi- fiziert wird und was unspezifiziert bleibt, und wie man mit gegensätzlichem Verhalten umgeht. Dort sollte das Komitee aber nur als ``Schlichter'' zwischen den verschiedenen Lagern auf- treten. Wenn das Standardisierungskomitee ein Diener ist, dann wird es die besten Ergebnisse liefern. Wenn es meint, lenken zu können, wird es schlechte Ergebnisse produzieren. Große Verantwortung hängt an dieser Aufgabe, denn mit schlechten Standards muss die Menschheit zumeist lange kämpfen. http://marmaro.de/apov/ markus schnalke