Editorial: Das richtige Werkzeug
"Es wurde alles schon einmal programmiert, aber noch nicht von jedem", so heißt ein Sprichwort. Es ist auch gewiss nichts dagegen einzuwenden, wenn jemand etwas programmiert, was schon existiert, weil er oder sie dadurch Übung erlangen will. Wer darüber hinaus in einer Programmiersprache wie Intercal programmieren möchte, soll auch das gerne tun. Doch darum soll es hier nicht gehen. Ich möchte mich hier stattdessen näher mit den Situationen auseinandersetzen, in denen tatsächlich unnötige Arbeit verrichtet wird, ohne dass dies bewusst in Kauf genommen wird.
Die Unix-Philosophie, jene die technischem Grundideen von Unix-Systemen beschreibt, besagt unter anderem, dass man für jede Aufgabe das passende Werkzeug einsetzen soll, statt sich von seinem Ehrgeiz leiten zu lassen. Wenn man ein neues Projekt in Angriff nimmt, sollte man sich also fragen, was denn das passende Werkzeug überhaupt ist. Häufig ist insbesondere die Kombination mehrerer Werkzeuge angemessen.
So macht es meist etwa wenig Sinn, einen Parser für eine Konfigurationsdatei zu schreiben, diesen im Laufe der Zeit um Unmengen von Funktionen zu erweitern, bis er den Umfang einer halben Programmiersprache hat, und die zahlreichen dabei anfallenden Bugs zu korrigieren usw. Viel sinnvoller ist meist die Möglichkeit, eine in Form einer Bibliothek vorliegende interpretierte Programmiersprache zu diesem Zweck einzubinden. Man bekommt auf diese Weise gratis einen ausgereiften Parser und eine mächtige Sprache zur Beschreibung einer Konfiguration, bei der BenutzerInnen Dinge wie Umgebungsvariablen problemlos verwenden können. Egal ob Guile, Ruby oder etwas Vergleichbares, der einfache Zugriff auf ein paar in diesen Sprachen gesetzte Variablen ist weit weniger Aufwand, als etwas auch nur halb so Mächtiges selbst zu schreiben.
Ein interessanter Nebeneffekt davon ist es, dass damit BenutzerInnen auf sanfte Weise an die Programmierung herangeführt werden. Es muss gewiss nicht jeder Mensch zum/zur ProgrammiererIn werden, doch es ist sicher keine schlechte Idee, fortgeschrittenen BenutzerInnen die Möglichkeit zu bieten, auf relativ einfache Weise kleine Erweiterungen für ein Programm zu schreiben.
Auch ist dringend zu empfehlen, auf ein vorhandenes Build-System wie autoconf (und am Besten auch noch automake) zurückzugreifen, statt zu versuchen, schlauer zu sein als die EntwicklerInnen dieser Werkzeuge. In der Praxis wird man es nie so gut hinbekommen wie diese. Programme, die ihr eigenes Build-System mitbringen, sind erfahrungsgemäß mit am Schwierigsten zu portieren.
Offensichtlich, aber dennoch erwähnenswert, ist die Verwendung von Bibliotheken. Es gibt eine Unmenge an freien Bibliotheken für viele Zwecke. Manche erleichtern dem/der ProgrammiererIn die Arbeit, andere erfordern zwar ein wenig zusätzlichen Aufwand, machen dafür aber die Benutzung des Programms signifikant komfortabler (ein typisches Beispiel dafür - selbst wenn es eigentlich keine Bibliothek ist - wäre gettext zur Internationalisierung). Man mag nun argumentieren, dass diese Strategie zu zahlreichen Abhängigkeiten führt. Doch wer sich auf diesen Standpunkt stellt, spricht sich gegen die Wiederverwendung von Code aus - und damit sowohl gegen die Unix-Philosophie als auch gegen die Vernunft.
Bei einem auf den ersten Blick eher nebensächlichen, aber für die Benutzung eines Programms doch oftmals recht wichtigen Aspekt wird sehr viel unnötiger Code geschrieben: Beim Verarbeiten der Argumente, die einem Programm von der Kommandozeile aus übergeben wurden. Diese Aufgabe wirkt auch eigentlich recht trivial, ist aber, wenn man sie richtig umsetzen will, mit hohem Aufwand verbunden. So sollten "-v -e -k" und "-vek" das gleiche Ergebnis bringen und Optionen, die Argumente erwarten, sollten sowohl in der Form "-o foo" als auch "-ofoo" akzeptiert werden. Außerdem gibt es noch die langen Optionen, bei denen Argumente in Form von "--output=foo" oder "--output foo" akzeptiert werden sollten, mal ganz abgesehen davon, dass auch Abkürzungen wie "--outp foo" bzw. "--outp=foo" gültig sein müssen, sofern sie eindeutig sind. Glaubt jetzt immer noch jemand, seinen/ihren eigenen Code zum Verarbeiten der Kommandozeilenargumente schreiben zu müssen?
Natürlich stellt sich auch die Frage, ob es unbedingt C oder C++ sein muss. Der Hauptgrund, warum diese so weit verbreitet sind, dürfte die hohe Ausführgeschwindigkeit sein. Sogar ganz abgesehen davon, dass die verwendeten Algorithmen oft ebenso entscheidend sind wie die verwendete Programmiersprache, ist Rechenzeit billig, während menschliche Arbeitskraft die wohl knappste Resource ist. Daher sollte man sich durchaus überlegen, ob nicht eine "langsame" Sprache für eine Aufgabe ausreichend ist. Unter anderem bieten Python, Ruby und wohl sämtliche Scheme-Implementierungen die Möglichkeit der interaktiven Ausführung von Code in einer Read-Eval-Print Schleife, was zwar ein simpler Mechanismus zu sein scheint, aber die Produktivität signifikant erhöhen kann.
Ein Programmierer formulierte es einmal so: "Mir ist es jedenfalls lieber, sehr viele interessante Dinge zu tun, statt nur ein paar interessante Dinge, die dafür schnell ausgeführt werden."
