"The Art of Unix Programming", Buch von Eric S Raymond das volltext hier online liegt: http://www.faqs.org/docs/artu/index.html
Erklärt den Unix way of doing things, in all seinen Gestaltungs-Mustern, Hintergründen und Vorteilen. Komprimiert die Erfahrungen aus fünfzig Jahren Hacker- und Programmierer-Kultur.
Lektüre-Notizen:
- Früher ! da kostete jeder Funktionsaufruf noch zehnmal mehr als einfach den gleichen Code-Block nochmal hinzupasten ! Die Geschichte des Code als eine Geschichte der Partitionierung. http://www.faqs.org/docs/artu/modularitychapter.html
- Einkapselung der Module. Sie zeigen einander glatte Oberflächen, mit Öffnungen (APIs) nur da, wo Daten-Austausch explizit erwünscht ist. Die APIs sind Gott, nicht die Innereien des Moduls. Denk dir zuerst deine APIs aus, bevor du den Code schreibst, dann läuft alles besser. Modularisierung soll Programme klein halten, denn zu große Programme die zu viel machen sind unübersichtlich und fehlerhaft. Es gibt aber auch eine zu kleine Modul-Körnung. (Wenn die Module so klein sind, dass ihre Interaktion wiederum hochkomplex aussieht ...) 200-400 "logische" und 400-800 "physische" Code-Zeilen scheinen das Optimum. http://www.faqs.org/docs/artu/ch04s01.html
- Kompakt ist, was bei Erfahrenheit kein Nachschlagewerk braucht. Bjarne Stroustrup erwartet nicht, dass je irgendjemand C++ ganz versteht. Orthogonalität bedeutet: Code verursacht nur genau das, was er soll. Sich wiederholender Code ist verunübersichtlichender Müll. Eine klare formale Problemlösung ist einer Heuristik vorzuziehen; letztere provoziert Komplexität. Betrachte Heuristiken als extrem teuer. Zen: Fange bei einer Ambition Null an. Wirf erstmal alle Vorannahmen ab. http://www.faqs.org/docs/artu/ch04s02.html
- Die Designer-Schule sagt: Entwickle top-down! Der Unixer entwickelt aber lieber bottom-up. Das ist more exploratory. Viel Zusammenklebe-Code ist gefährlich und zeugt von unklarer Trennung zwischen interner Code-Mechanik und API-Spezifikation. C war erfolgreich, weil es eine logische Ideal-Rechner-Architektur antizipierte und sich dafür optimierte statt für ein einzelnes Gerät. http://www.faqs.org/docs/artu/ch04s03.html
- Funktionen von Bibliotheken sollten nicht nur in Programmiercode, sondern auch von der Kommandozeile aufrufbar sein, d.h. sie sollten eine Programm-Implementierung haben ("library exercisers"). Das macht sie benutz- und testbarer. Umgekehrt sollte auch jedes Programm in Code einbaubar sein. Dass GIMP nicht so sehr ein großes Programm sondern eher ein dünner Verknüpfungs-Layer über einer weiten Programm-Bibliothek sei, ja, so fühlt sich das auch an. http://www.faqs.org/docs/artu/ch04s04.html
- Objekt-Orientierung bedeutet die enge Verknüpfung einer Funktion mit einer Datenstruktur. Außerhalb von Simulationen und Grafik braucht kein Mensch Objekt-Orientierung. Sie widersprucht dem Unix way. Eine Abstraktion, die die Layer (und den Zusammenklebe-Code) multipliziert und alles komplizierter macht. Der Layer forciert eine Abstraktion auf Kosten der Möglichkeit aller anderen. (Mein Unbehagen mit Objekt-Orientierung rejoicet, in Wirklichkeit war ich die ganze Zeit ein Unix-C-Guru anstatt einfach nur ein unbelernter Programmierer!) http://www.plomlompom.de/wiki/pmwiki.php?n=Mind.TheArtOfUnixProgramming
- Eine Funktion wird zu komplex, wenn man ihren Nutzen nicht mehr in einer Zeile Prosa beschreiben kann. Sieben sei die Zahl, die nichts überschreiten darf (API-Einstiegspunkte usw.). Und achte auf relativ gleichmäßige Verteilung der API-Größenzahlen. http://www.faqs.org/docs/artu/ch04s06.html
- Unixer schreiben Code lieber ganz neu, als ihn zu patchen, wofür sie ihn erst mühevoll verstehen müssten. Was dann an Code doch bestehen bleibt, über Jahre, Jahrzehnte, ist also offensichtlich evolutionär gefiltert nach leichter Verstehbarkeit, sodass es völliges kein Neuschreiben provozierte. http://www.faqs.org/docs/artu/ch06s03.html
- Die Kunst der vielen Teile, die kooperieren. http://www.faqs.org/docs/artu/multiprogramchapter.html
- Performance ist mir egal, aber sowas von ! (Naja, zumindest voreilige Starren darauf.) http://www.faqs.org/docs/artu/ch07s01.html
- Pipes! Pipes! Pipes! Toller Programm-Name: rblsmtpd. Signale. Ach ja, und ich könnte mal wieder über "fetchmail" reden. Besser: Wie FreeCiv funktioniert. Desweiteren viele komplizierte System-Interna. http://www.faqs.org/docs/artu/ch07s02.html
- Was doof war und was man nicht mehr tun sollte in InterProzessKommunikations-Fragen. http://www.faqs.org/docs/artu/ch07s03.html
- Einfachheit ist wichtiger als Performance! http://www.faqs.org/docs/artu/ch07s04.html
- Gib dem Nutzer alle Anpassungs-Macht, aber verkompliziere deinen Code nicht mit tausend Konfigurations-Switches, wennn die Manipulation stattdessen über andere Unix-Programme geht. http://www.faqs.org/docs/artu/ch10s01.html
- Hierarchie der Konfigurationen. http://www.faqs.org/docs/artu/ch10s02.html
- Konfigurations-Dateien werden für Text-Editoren geschrieben. Konfigurationsdateien für Sprachen sollten in diesen Sprachen geschrieben sein. Toleriere Whitespace-Unregelmäßigkeiten. http://www.faqs.org/docs/artu/ch10s03.html
- Die wenigen Fälle, für die man Umwelt-Variablen einsetzt; schlechte Idee, denn die Herkunft ihres Gesetzt-Seins ist schwer zu kontrollieren. http://www.faqs.org/docs/artu/ch10s03.html
- Kommando-Zeilen-Parameter. Alles üblicherweise kleingeschrieben, weil, bei den alten Maschinen, "[h]olding down the shift key required actual effort". Liste all der über Programme hinweg konventionalisierten Parameter. http://www.faqs.org/docs/artu/ch10s05.html
- Das X-Client-Server-Modell ist total verwirrend, das findet sogar Eric S. Raymond. http://www.faqs.org/docs/artu/ch10s06.html
- Der alte Disclaimer: Breche Konventionen, wenn du musst. (Aber: Breche sie tönernd, damit man sich nicht auf ihr Eingehaltenwerden verlässt.) http://www.faqs.org/docs/artu/ch10s07.html
- Baue deine Interfaces nicht nur für menschliche Benutzer, sondern auch für andere Programme. http://www.faqs.org/docs/artu/interfacechapter.html
- Rule of Least Surprise. Außerdem waren die Ur-Benutzer von Netscape und Mozilla alle Emacser. http://www.faqs.org/docs/artu/ch11s01.html
- Unix' Benutzeroberflächen wurden zuerst für Fernschreiber-Terminals designt, sogar noch ohne Bildschirm. Ab 1980 dann curses, ab 1987 X, das alles ziemlich unelegant und kompliziert und balkanisiert machte. http://www.faqs.org/docs/artu/ch11s02.html
- Mögliche Qualitäten einer Benutzeroberfläche. http://www.faqs.org/docs/artu/ch11s03.html
- CLI oder GUI, alles hat seine Vor- und Nachteile. Kommt immer drauf an, welches Problem bearbeitet wird. Aber trotzdem sind GUIs scheiße, weil unskriptierbar. http://www.faqs.org/docs/artu/ch11s04.html
- Der Unix-Entwickler entscheidet sich im Zweifelsfall für Expressivität, d.h. Alles-Können eines Programmes. Der Standard muss voll und ganz implementiert werden. Er verweigert sich eines Rankings der Bedeutung der einzelnen Funktionen, vergisst das Bauen einfacher Defaults und betrachtet seinen Job auch dann als erledigt, wenn das Programm theoretisch alles kann, aber praktisch niemand die Lernkurve aufbrächte. Raymond nennt das natürlich nicht Arroganz, sondern Bescheidenheit gegenüber dem User. Dann aber ein gutes Plädoyer für Dursichtigkeit und Entdeckbarkeit als Unix-way-kompatible Leitlinien im Bauen Laien-freundlicher Anwendungne. http://www.faqs.org/docs/artu/ch11s05.html
- Katalog der verschiedenen Unix-Programm-Sorten, entlang ihrer Oberfläche dem Benutzer gegenüber, von Kommandozeile bis Proto-GUI, von Skriptierbarkeit bis Unskriptierbarkeit. Den Begriff "roguelike" habe ich lange gesucht. Für more sophisticated Fälle eine Auftrennung zwischen Triebwerk und Oberfläche. http://www.faqs.org/docs/artu/ch11s06.html
- Die beste Interaktivität ist Null Interaktivität! GUIs machen Programmaufbau sehr kompliziert. http://www.faqs.org/docs/artu/ch11s07.html
- Missbrauche Web-Browser als GUIs. http://www.faqs.org/docs/artu/ch11s08.html
- Beschränke Output aufs Allernotwendigste. Kannst du dich nicht zügeln, nutze halt eine Verbosity-Switch als Ventil. http://www.faqs.org/docs/artu/ch11s09.html
- Unix spricht alle Sprachen wo nur denkbar! Beleidige sie alle! http://www.faqs.org/docs/artu/ch14s01.html
- Wenn du eine Idee hast, fange nicht mit C an. Wenn du keine Lust darauf hast, die Hälfte deiner Zeit dich um Speichermanagement zu kümmern, nimm nicht C. http://www.faqs.org/docs/artu/why_not_c.html
- Unter Unix, Shell-Skripten ist die Meta-Programmiersprache, die dann den Code von allem Anderen integriert. http://www.faqs.org/docs/artu/ch14s03.html
- C ist das portable Assembler, und alles Andere baut maschinell darauf auf. C++ ist die Nachteile von C kombiniert mit dem Aufhoppsen auf den gestrigen Objekt-Orientierte-Programmierung-Trend. "Perl is shell on steroids" und viel mächtiger als awk, aber auch unglaublich hässlich, verschroben und unlesbar. Tcl/Tk ist seltsam, einfach und nicht für Großes geeignet. Python ist für nahezu jede Aufgabe Gott, es sei denn sie ist winzig oder erfordert superviel RegExp-Spielchen; seine Geschwindigkeitsschwächen lassen sich durch direkte Verschaltbarkeit mit maschinennahem C-Code ausgleichen. Für Java spricht im Vergleich ziemlich wenig. http://www.faqs.org/docs/artu/ch14s04.html
- Uralte Trends, aber immerhin hat 2003 schon von Ruby gehört. http://www.faqs.org/docs/artu/ch14s05.html
- X-Toolkits: Tk ist altmodisch, GTK ist für Freunde von C und GIMP, Qt ist für C++, wxWindows ist meta. http://www.faqs.org/docs/artu/ch14s06.html
- Dokumentations-Formate. Schade, ich dachte, es ginge eher ums inhaltliche Gestalten. http://www.faqs.org/docs/artu/documentationchapter.html
- WYSIWYG ist nice, aber eigentlich immer irgendwie und undurchsichtig broken. Mit Markup-Programmierung gehen komplexe und Dokumenten-weite Veränderungen leichter. http://www.faqs.org/docs/artu/ch18s01.html
- Unix-Gebrauchsanweisungen sind nicht pädagogisch, aber präzise geschrieben. Sie erklären nichts zweimal und verlangen vom Leser Mitdenken, listen dafür aber auch ehrlich alle Bugs auf. http://www.faqs.org/docs/artu/ch18s02.html
- troff/nroff/man, TeX/LaTeX, out: Texinfo, in: DocBook http://www.faqs.org/docs/artu/ch18s03.html
- Unix-Dokumentations-Formate-Chaos, Standardisierung auf XML-DocBook to the rescue. http://www.faqs.org/docs/artu/ch18s04.html
- DocBook als Beispiel einer XML-Formatier-Werkzeugkette. http://www.faqs.org/docs/artu/ch18s05.html
- In deiner Dokumentation, sei präzise, lasse kein funktionales Detail aus, unterschätze den Nutzer nicht. http://www.faqs.org/docs/artu/ch18s06.html