- software bloat /n./
The results of second-system effect or creeping featuritis. Commonly cited examples include `ls(1)', X, BSD, Missed'em-five, and OS/2. - -- The GNU Jargon file
Heute gibt es mal etwas Programmierer-Philosophie für Nicht-Programmierer.
Wenn man auf dem Computer beliebige Aufgaben erledigt haben will, braucht man dafür Programme. Leute, die sich solche Programme ausdenken müssen bei dem Design sich vor allem für eine Philosophie entscheiden. Die beiden Extreme dieser Philosophie sind "mein Programm kann alles" oder "mein Programm kann genau eins, das aber besonders gut".
Da dies etwas trocken ist, will ich mal ein paar Beispiele bringen. Für das erste Beispiel drehen wir mal das Zeit ordentlich zurück, und zwar so zwölf Jahre. Windows 95 ist noch nicht in Sicht, das Arbeiten mit Windows 3.1 bringt einen vor allem dann etwas, wenn man masochistisch veranlagt ist, und der Autor lernt Unix in der Inkarnation von SunOS 4.1 und etwas später Linux 1.0.9 kennen.
Ein zentraler Punkt auf einem Unix System ist ein Texteditor. Damals noch mehr als heute, weil man damals meistens nur einen nahm, egal ob mal einfach nur eine Notiz verfassen wollte, an der Systemkonfiguration arbeitete oder ein Programm schrieb: man hatte ein Texteditor für alle anfallenden Aufgaben.
Und auch damals war die Welt in Lager geteilt, wie man es schon in der Schulzeit kannte: Pelikan oder Geha, Coke oder Pepsi, TKKG oder die drei Fragezeichen. In diesem Fall hieß die Frage: vi oder emacs? Auf diesen Glaubenskrieg will ich nicht weiter eingehen, aber emacs ist ein Paradebeispiel für die "das Programm kann alles"-Philosophie.
Es war weit mehr als einfach nur ein Texteditor: man konnte mit diesem Programm auch E-Mails und (Usenet) News lesen, Tetris spielen oder auch im Web surfen. Und was noch nicht ging, konnte hinzuprogrammiert werden. Joseph Weizenbaums "Eliza" wurde dafür umgesetzt, inclusive eines automatischen Patienten, damit sich das Programm dann mit sich selbst unterhalten kann. Programmiererhumor halt. Natürlich gab es auch Lästerstimmen, die behaupteten, dass es Leute gäbe, die seit Wochen ihren emacs nicht mehr verlassen hätten, weil sie nichts anderes bräuchten. Ein anderes Gerücht besagt, dass emacs für "eight megabyte and constantly swapping" stehen würde, weil das Programm solche Unmengen von Ressourcen bräuchte. Ein PC hatte damals üblicherweise vier Megabyte Arbeitsspeicher. Heutzutage hat ein moderat ausgestatteter PC mindesten das 250-fache an Arbeitsspeicher.
Der vi hingegen konnte nur Dateien editieren. Dafür konnte er das unter fast allen Voraussetzungen. Auch wenn der emacs recht stabil lief, so war doch der vi derjenige, auf den man sich im Krisenfall verlassen hat. Wenn im System irgendetwas schief lief, arbeitete man an den Konfigurationsdateien mit dem vi, weil man damit zwar auch etwas kaputt machen konnte, er aber definitiv nicht selbstständig was kaputt gemacht hat. egal was schief lief.
Und diese gegensätzlichen Philosophien sind immer noch einer der grundsätzlichen Fragen bei der Entwicklung von Computerprogrammen: sollte der Webbrowser nun auch noch E-Mail und News beherrschen oder nicht? Sollte man sämtliche Officeprogramme als eins zusammenfassen, oder Textverarbeitung, Tabellenkalkulation, etc. doch lieber einzeln entwickeln? Soll der Musikplayer auch Filme abspielen können, oder wäre es sindvoll Audio- und Videoplayer zu trennen?
Die Wahrheit, genauer gesagt die Philosophie, die besten für das Projekt passt, liegt normalerweise irgendwo dazwischen. Ich bin jedoch im Laufe der Jahre dazu übergegangen, die Lösung der "vielen kleinen Programme" zu bevorzugen. Aus eigener Erfahrung weiß ich, dass die Wartung von Programmen mit ihrer Komplexität schwieriger wird, und zwar nicht linear, sondern eher exponenziell. Allerdings kann man auch nicht jedes Problem so weit runter brechen, dass die Programme immer überschaubar bleiben. Als ein Beispiel hierfür möchte ich das Zeichen- oder Malprogramm anführen: es wäre ziemlich sinnlos, wenn man für die Filter, wie zum Beispiel Weichzeichner oder Farbanpassungen, auf einmal ein anderes Programm aufrufen müsste.
Trotzdem bevorzuge ich bei der Suche nach Software, die eine Aufgabe für mich bewältigen soll, solche, die eben nur diese Aufgabe löst, und nicht noch über hundert andere, die sich mir gar nicht stellen. Lieber mehrere kleine als ein Riesenprogramm. Ist aber nur meine Meinung.
Kommentare
Wobei ex und das DOS Pendant EDLIN.EXE wirklich nur was Leute sind, denen die Terminalemulation abhanden gekommen ist :hack:
An sich bin ich derselben Meinung. Programme bitte nur so komplex wie es noch sinnvoll ist. Aber keine eierlegenden Wollmilchsäue.