- Brian Kernighan blickt auf The Practice of Programming zurück, das er zusammen mit Rob Pike geschrieben hat: ein Buch, das 1999, als Internet, Python, Perl und Java sich rasant verbreiteten, zeigen wollte, „wie man Programme professionell und gut schreibt“
- Einige Beispiele sind mit der Zeit veraltet, doch Prinzipien wie Stil, Debugging und Haltung beim Schreiben lassen sich seiner Ansicht nach auch bei wechselnden Sprachen und Umgebungen übertragen
- CSV-Parsing ist nach wie vor unordentlich, und die Spezifikation ist nicht vollständig eindeutig; pandas ist mächtig, aber schwergewichtig und auf hohem Abstraktionsniveau, sodass einfacher Python-Code manchmal besser sein kann
- Bell Labs war dank langfristigem Denken, herausragenden Kollegen und geringem Druck durch Produkte oder Umsätze eine Forschungsumgebung, in der Arbeiten wie Unix, yacc und Werkzeuge zur Dokumenterstellung möglich waren
- Große Sprachmodelle sind eine Technologie, die seit November 2022 plötzlich großen Einfluss entfaltet; seine Erfahrung, dass Claude Python-Code für spaCy nahezu korrekt erzeugte, deutet auf Veränderungen in der Arbeitsweise von Programmierern hin
Die Programmierumgebung von 1999 und das Ziel des Buchs
- The Practice of Programming erschien rund 15 Jahre nach The Unix Programming Environment, das Kernighan und Rob Pike zuvor gemeinsam geschrieben hatten
- Ziel des Buchs war es, zu behandeln, „wie man Programme tatsächlich schreibt“ und „wie man sie effektiv und professionell schreibt“
- Die Computing-Umgebung um 1999 unterschied sich stark von der heutigen
- Das Internet war für die breite Öffentlichkeit ein relativ neues Phänomen, das etwa 1995 bis 1996 sichtbar wurde
- Python war eine vergleichsweise neue Sprache, Perl war weiterhin stark, und auch Java war populär
- Konkrete Beispiele mögen für heutige Leser weniger unmittelbar relevant sein, doch die allgemeinen Prinzipien lassen sich seiner Ansicht nach auf andere Umgebungen übertragen
- Die Moderatoren hielten insbesondere die Kapitel zu Styleguides und Debugging weiterhin für gültig und fanden bemerkenswert, dass das Wort „bug“ bereits vor der Grace-Hopper-Anekdote mit dem Mark-Computer auch im Kontext von Thomas Edison und dem Phonographen verwendet wurde
CSV, pandas, Speicher und Abstraktion
- Kernighan sagt mit Blick auf das CSV-Parser-Beispiel aus dem Buch, dass es auch heute keinen guten CSV-Parser gebe
- Im vergangenen Sommer verbrachte er einige Wochen bis etwa einen Monat damit, einen „richtigen CSV-Parser“ zu schreiben, um awk um CSV-Funktionen zu erweitern
- Die CSV-Spezifikation sei nicht vollständig eindeutig und in gewissem Sinne nicht standardisiert
- pandas wird als mächtiges, aber schwergewichtiges Werkzeug eingeschätzt
- In vielen Fällen sei es einfacher, direkt Python zu schreiben, als die impliziten Iterations- und Auswahlmechanismen im pandas-Stil zu verstehen
- Der Moderator sagt, dass pandas bei Machine-Learning- und Data-Science-Arbeiten häufig gewählt werde, man bei wichtiger Laufzeit-Performance aber über einfachere Ansätze nachdenke
- Speicherverwaltung sei heute in vielen Bereichen der Programmierung zu etwas geworden, um das man sich kaum noch kümmern müsse
- In C muss Speicher direkt verwaltet werden, was sehr schwierig ist
- In C++ ist es ebenfalls möglich, doch die richtigen Techniken zu erlernen sei schwierig
- In Python funktioniere es meist „wie Magie“
- Große Abstraktionen verbergen Probleme nicht immer vollständig
- Beim Verarbeiten eines Texts in Buchlänge mit spaCy erhielt er die Meldung, dass der Speicher nicht ausreiche, weil das standardmäßige Arbeitskontingent 1 GB betrug; das Problem wurde gelöst, indem die Einstellung verdoppelt wurde
- Als Kernighan aufwuchs, galten bereits Kilobytes als viel Speicher
- In der Embedded-Community bleiben Speicher und Performance sehr wichtig; neben C werden in diesem Kontext auch Sprachen wie Rust oder Zig erwähnt
Go, Plan 9 und die Forschungsumgebung der Bell Labs
- Der Moderator sagt, die Problemstellung von The Practice of Programming habe sich wie ein Ausgangspunkt für das Design der Sprache Go angefühlt
- Kernighan hält es für „vollkommen plausibel“, dass Rob Pike, einer der drei Schöpfer von Go, die im Buch behandelten Unbequemlichkeiten später im Hinterkopf hatte, als er über eine neue Sprache nachdachte
- Allerdings habe er keine konkrete Erinnerung daran, dass Pike damals gedacht habe, er werde „die Welt mit einer neuen Sprache verbessern“
- Die Arbeit an Plan 9 in den late 1990s sowie Sprachen wie Limbo und Alef sieht er als Teil der Entwicklungslinie, die zu Go führte
- Die Erfahrung bei Bell Labs kam für Kernighan einer idealen Umgebung nahe
- Während seiner Zeit als Doktorand in Princeton arbeitete er in den 1960er-Jahren zwei Sommer lang als Praktikant bei Bell Labs in einer Gruppe, die mit Multics zu tun hatte
- Die Erfahrung gefiel ihm so gut, dass er nach einem Rückkehrangebot keine Vorstellungsgespräche anderswo führte
- Von Anfang 1969 bis etwa 2000 war er bei Bell Labs
- Bei Bell Labs war damals langfristiges Denken möglich, und es gab wenig Druck, quartalsweise Ergebnisse oder sofort Produkte und Umsatz zu liefern
- Die Menschen konnten relativ unabhängig an Dingen arbeiten, die sie für interessant und wichtig hielten
- Da AT&T damals den Großteil der USA mit Telefondiensten versorgte, war es eine „problemreiche Umgebung“, und es gab viele Aufgaben, die für das Telefonsystem nützlich sein konnten
- Eine direkte Begegnung mit Claude Shannon gab es nicht
- Kernighan erinnert sich, dass Shannon einige Jahre vor seinem Eintritt bei Bell Labs zum MIT gewechselt war
- Mit Richard Hamming, der sich einmal ein Büro mit Shannon geteilt hatte, stand Kernighan nach eigenen Angaben eng in Kontakt
Lernen, Bücher schreiben und programmierendes Denken
- Kernighans frühes Lernen fand bei Bell Labs statt, wo er mit guten Leuten, Werkzeugen und interessanten Problemen in Berührung kam
- yacc war ein Werkzeug, das das Erstellen neuer Programmiersprachen erleichterte, und Kernighan nutzte es neben der traditionellen Sprachgenerierung auch in Bereichen wie Dokumenterstellung und deklarativen Sprachen
- Dabei lernte er viel über Sprachdesign und Implementierung
- Auch an Werkzeugen zur Dokumenterstellung war er lange interessiert
- Er wurde von runoffs frühem interaktivem Textverarbeitungsprogramm am MIT beeinflusst
- In Princeton schrieb er in Fortran ein ähnliches Dokumenterstellungsprogramm, um seine eigene Dissertation zu erstellen
- Bei Bell Labs entwickelte er Werkzeuge, um Bücher physisch einfacher herzustellen und zu verhindern, dass Programmbeispiele im Veröffentlichungsprozess beschädigt wurden
- Nach seinem Wechsel an die Universität wurde es zu einer wichtigen Lernerfahrung, bereits Bekanntes Nicht-Informatikern zu erklären
- Er musste Studierenden mit Stärken in Literatur oder Musik erklären, wie Binärzahlen funktionieren
- Dabei lernte er auch, dass Leibniz im späten 17. Jahrhundert der eigentliche Erfinder der Binärzahlen war und statt Buchstaben Noten verwendete, um etwas zu schaffen, das der hexadezimalen Notation ähnelte
- Die Motivation, ein Buch zu schreiben, entstehe, wenn es „etwas gibt, das es wert ist, gesagt zu werden“, und einen Co-Autor, mit dem man es gemeinsam sagen möchte
- Die meisten Bücher von Kernighan sind Gemeinschaftsarbeiten
- Zusammenarbeit sei viel einfacher als allein zu schreiben, weil man die Inhalte des jeweils anderen ergänzen und verfeinern könne
Große Sprachmodelle, Bildung und Buchempfehlungen
- Kernighan nennt als wichtige Entwicklungen in seiner Laufbahn Timesharing-Systeme, Unix, die Evolution von Programmiersprachen, den Ressourcenanstieg durch das Moore’sche Gesetz und den PC
- Timesharing war eine große Veränderung, weil man nach dem eigenen Zeitplan arbeiten konnte, ohne physisch vor dem Computer zu sitzen oder auf die Verarbeitung durch Operatoren zu warten
- Cloud Computing sieht er insofern wieder als eine Form, die dem Timesharing nahekommt, als Berechnung zentralisiert ist und Nutzer über hochwertige Peripheriegeräte mit entfernten Systemen kommunizieren
- Als derzeit interessanteste Technologie nennt er große Sprachmodelle
- Bemerkenswert sei, dass sie um November 2022 plötzlich aufgetaucht seien und in kurzer Zeit großen Einfluss entfaltet hätten
- Er bat Claude in zwei oder drei Sätzen um eine spaCy-bezogene Aufgabe; das Modell erzeugte Python-Code, der zu etwa 99,9 % korrekt war, und nutzte Python zudem ausgefeilter als er selbst
- Programmierer würden nicht verschwinden, aber ihre Arbeitsweise werde sich wahrscheinlich verändern
- LLMs eröffnen Studierenden neue Ansätze
- Ein Student sah die Möglichkeit, LLMs zur Verbesserung von Übersetzungen aus dem Altgriechischen zu nutzen
- OCR-Ergebnisse alter Druckdokumente aus dem 18. Jahrhundert könnten mithilfe des Sprachwissens eines Sprachmodells verbessert werden
- In Kursen für Nicht-Informatiker versucht er, die Funktionsweise von Computern mit technischen Fragen zu verbinden, die in der Welt eine Rolle spielen
- Viele Teilnehmer sind Studierende der Geistes- und Sozialwissenschaften und belegen den Kurs oft, um Anforderungen im quantitativen Denken zu erfüllen
- Behandelt werden Themen wie Hardware, Software, Kommunikation, net neutrality, privacy, security und Google antitrust, jeweils mit technischer Grundlage
- Programmierendes Denken – große Aufgaben in kleinere zu zerlegen und schrittweise zu denken – lasse sich auch auf andere Bereiche übertragen, etwa das Schreiben von Aufsätzen oder die Analyse juristischer Fragen
- Für Anfänger ist es wichtig, etwas zu finden, das sie selbst tun möchten
- Wer von einem interessanten Problem ausgeht, etwa ein Spiel zu bauen, persönliche Finanzen zu verbessern oder Texte zu analysieren, kann psychologische Hürden senken
- In Kursen für Nicht-Informatiker verwendet er eine Aufgabe, bei der zunächst Pride and Prejudice mit NLTK analysiert wird und die Studierenden anschließend ein anderes Buch ihrer Wahl auf dieselbe Weise untersuchen
- Die empfohlenen und erwähnten Bücher sowie Lesevorlieben sind vielfältig
- Unter den technischen Büchern schaut er gelegentlich wieder in The Mythical Man-Month hinein; manches sei gut gealtert, manche sprachlichen Formulierungen wirkten nach heutigen Maßstäben jedoch sehr sexistisch
- Jennifer Pahlkas Recoding America wird als interessantes Buch erwähnt, das behandelt, warum staatliche Software nicht so gut funktioniert wie erwartet und warum das System Verbesserungen erschwert
- Als nichttechnische Lektüre erwähnt er Geschichte, Militärgeschichte, Detektivromane, Dick Francis’ Romane über Pferderennen sowie Chip War über Halbleiter
1 Kommentare
Hacker-News-Meinungen
Dieses Buch ist ein Grundlagenbuch, das alle Programmierer lesen sollten, besonders Anfänger.
Wie man es von einem Buch von Kernighan erwartet, sind die Sätze einfach, knapp und präzise; auf etwas mehr als 200 Seiten steht ohne Ballast nur das Wesentliche. Man versteht die Prinzipien anhand der Beispiele und überträgt sie dann auf den eigenen Kontext.
Die Stärke der K&P-Bücher liegt darin, dass sie einen nicht mit Theorie erschlagen, sondern erst die praktische Anwendung von Techniken zeigen, sodass das anschließende Theoriestudium leichter zugänglich wird.
Als ich dieses Buch las, hatte ich zum Beispiel bereits Erfahrung mit Netzwerkprogrammierung und Protokollimplementierung. Im Kapitel „Notations“ wurden Pack/Unpack-Routinen für Netzwerknachrichten gezeigt, bei denen Paketlayouts mit Format-Strings im Stil von
printf/scanfbeschrieben werden — das war für mich ein Augenöffner. Ich lernte die Macht passender Notation und kleiner Sprachen kennen; außerdem gibt es Codefragmente, die Ideen zu virtuellen Maschinen, Code-Threading und JIT-Kompilierung zeigen.Auch Kernighans und Pikes älteres Buch „The Unix Programming Environment“ lohnt sich dazu. Das Kapitel „Program Development“ beschreibt auf etwa 50 Seiten den gesamten Prozess, mit Compiler-Entwicklungswerkzeugen einen Compiler für eine kleine Taschenrechner-Sprache zu bauen; soweit ich weiß, ist das die knappste und einfachste Erklärung zum Schreiben von Compilern.
Unterm Strich lohnt es sich, alle Bücher von Kernighan zu kaufen und durchzuarbeiten.
Das C-Buch habe ich früher gelesen, und ich erinnere mich, dass es hervorragend geschrieben war. Ich werde sicher viel Programmierweisheit mitnehmen, will aber auch aus Sicht des technischen Schreibens analysieren, warum Kernighans Bücher so gut sind.
Kernighan hat sich entweder intensiv mit Schreiben beschäftigt oder zumindest viel First-Principles-Denken darüber betrieben. Schon der Titel „The Elements of Programming Style“ verweist auf Strunk und Whites berühmtes Schreibbuch „The Elements of Style“.
Nach heutigen Maßstäben ist es etwas altmodisch, aber immer noch gut lesbar.
Das ist nicht sarkastisch gemeint; ich möchte verstehen, warum es auch für jemanden, der in seiner Karriere bequem vorankommt, Pflichtlektüre sein soll.
Ich mag „The Practice of Programming“ wirklich sehr.
Von allen Programmierbüchern, die ich bisher gelesen habe, sind mir die Lektionen aus diesem am stärksten im Gedächtnis geblieben. Ich habe es seit Jahren nicht mehr erneut gelesen, aber ich habe das Gefühl, dass es meine tägliche Praxis weiterhin beeinflusst.
Einige der konkreten Programmierbeispiele sind ziemlich veraltet, aber die allgemeinen Ideen sind weiterhin solide.
Ich mag Kernighan. Er ist ein wirklich bescheidener Mensch.
In einem seiner YouTube-Videos erzählte er, dass er in seiner Doktorarbeit ein schwieriges Problem löste, das sich später als NP-vollständiges Problem herausstellte, noch bevor die Theorie dazu ausformuliert war.
Ich schrieb ihm eine E-Mail mit der Bitte um die Arbeit und bekam ziemlich schnell eine Antwort; beim Lesen fand ich sie wirklich interessant.
Für mich und viele andere gehören seine Gedanken zum Programmieren zu den interessantesten und nützlichsten, zu einem erheblichen Teil, weil er sie sehr klar vermitteln kann.
Ich wünschte, heutige Interviews würden eher das Verständnis der Konzepte aus diesem Buch prüfen als LeetCode.
In dieser absurden neuen Welt könnte selbst Brian Kernighan ein LeetCode-hard-Interview nicht bestehen.
Es waren alles ziemlich praxisnahe Programmieraufgaben. Bei Stripe gab es ein Interview, in dem sie die Jackson-Java-Bibliothek geforkt und einen Bug eingebaut hatten; den sollte man finden und beheben. Das war ziemlich ungewöhnlich, aber viel näher an echter Programmierarbeit.
Mir fällt auch Katalin Karikó ein, die für mRNA den Nobelpreis erhielt und an der UPenn degradiert wurde, weil sie keine Forschungsgelder einwerben konnte.
Ein weiterer Autor, der in dieselbe herausragende Kategorie wie Kernighan und seine Bücher fällt, ist Jon Bentley, mit seinen Büchern Programming Pearls und More Programming Pearls.
https://en.m.wikipedia.org/wiki/Jon_Bentley_(computer_scient...
Dieses Buch bringt einem bei, über Effizienz von oben herab nachzudenken, mit Schwerpunkt auf Algorithmen und Sprache, und ist daher für alle Programmierer nützlich.
Moderne Bücher über Effizienz von Leuten wie Agner Fog oder Fedor Pikus behandeln vor allem Performance-Techniken auf Compiler-/Betriebssystem-/Prozessor-Ebene; zusammen gelesen ergibt sich das Gesamtbild.
Leute, das g ist stumm.
Es wäre schön, Rob Pike in die Sendung zu holen. Wahrscheinlich würde er unbedingt darauf hinweisen und die Aussprache korrigieren. Ich höre seine Stimme schon.
Rob Pike würden wir ebenfalls sehr gern einladen. Wir arbeiten daran, aber er ist etwas schwerer zu erreichen.
Ich habe zwar erst etwa ein Drittel des Videos gesehen, aber es war zu erkennen, dass die Moderatoren ziemlich gute, aufschlussreiche Fragen stellen.
Ich bin Carter, einer der Moderatoren des Videos. Es freut mich, dass ihr Spaß daran habt. Es war wirklich eine große Ehre, mit Brian Kernighan sprechen zu können.
Da dieses Format Bücher behandelt, wäre es wohl gut, in der Beschreibung oder in einem Teil der Kommentare die besprochenen Bücher und, wenn möglich, eine Medienliste zusammenzustellen.
„The Bit Player“ (eine Claude-Shannon-Dokumentation von 2018) habe ich auf meine Watchlist gesetzt, und „Recoding America“, „Chip War“ sowie „Endurance: Shackleton's Incredible Voyage“ auf meine Leseliste.
Es wäre schön, wenn ihr Kernighans Software Tools in Pascal zur Liste der Bücher hinzufügt, die im Podcast behandelt werden.
Ich habe das Buch und finde es gut.
Kernighan und Plaugher schrieben zuerst „Software Tools“ in RATFOR und danach „Software Tools in Pascal“. Und als direkte Reaktion auf diese Erfahrung schrieb Kernighan dann den Aufsatz „Why Pascal Is Not My Favorite Programming Language“.
Die Umsetzung in Pascal hätte viel einfacher sein müssen als die in RATFOR, war es aber nicht, und Kernighan dachte darüber nach, warum das so war.
Der Text ist nach wie vor interessant und zum Beispiel hier zu finden: https://www.cs.virginia.edu/~evans/cs655/readings/bwk-on-pas...
Allerdings bezieht sich der Text ursprünglich auf Standard-Pascal. Erweiterungen wie Turbo Pascal haben viele Probleme behoben. Nur waren, wie er sagte, diese Erweiterungen untereinander nicht portabel. Trotzdem wurde das bis zu einem gewissen Grad entschärft, weil Turbo Pascal de facto zur „Standard“-Erweiterung wurde.
Ich war von den Ideen und dem Text begeistert, und es wurde zum Ausgangspunkt dafür, auch die übrigen wichtigen Werke von Kernighan aufzuspüren und zu lesen.
Kernighan ist, zumindest in der ersten Auflage, auch Koautor des Buchs The Go Programming Language.