- Brian Kernighan revient sur The Practice of Programming, écrit avec Rob Pike, comme sur un livre qui cherchait, en 1999, à expliquer « comment bien programmer de façon professionnelle » à une époque où Internet, Python, Perl et Java se diffusaient rapidement
- Certains exemples ont vieilli avec le temps, mais il estime que des principes comme le style, le débogage et la manière d’écrire restent transposables même quand les langages et les environnements changent
- L’analyse de CSV reste toujours aussi délicate et la spécification n’est pas totalement claire ; pandas est puissant, mais lourd et très abstrait, si bien qu’un simple code Python peut parfois être préférable
- Bell Labs était un environnement de recherche qui rendait possibles des travaux comme Unix, yacc ou des outils de préparation de documents, grâce à une vision de long terme, à d’excellents collègues et à une faible pression produit ou rentabilité
- Les grands modèles de langage sont une technologie qui a soudainement eu un fort impact après novembre 2022, et son expérience avec Claude générant presque correctement du code Python lié à spaCy annonce un changement dans la manière de travailler des programmeurs
L’environnement de programmation en 1999 et l’objectif du livre
- The Practice of Programming est paru environ 15 ans après The Unix Programming Environment, que Kernighan et Rob Pike avaient auparavant écrit ensemble
- L’objectif du livre était de traiter de « la manière dont on écrit réellement des programmes » et de « la manière de le faire efficacement et professionnellement »
- L’environnement informatique autour de 1999 était très différent d’aujourd’hui
- Internet était encore une nouveauté relativement récente pour le grand public, apparue vers 1995-1996
- Python était un langage assez récent, Perl dominait encore et Java était lui aussi populaire
- Les exemples concrets peuvent être moins immédiats pour les lecteurs d’aujourd’hui, mais il estime que les principes généraux restent applicables à d’autres environnements
- Les animateurs ont jugé que les chapitres sur le style et le débogage restent particulièrement valables, et ont trouvé remarquable que le mot « bug » soit attesté avant l’anecdote du Mark de Grace Hopper, notamment chez Thomas Edison et dans le contexte du phonographe
CSV, pandas, mémoire et abstraction
- À propos de l’exemple de parseur CSV présent dans le livre, Kernighan affirme qu’il n’existe toujours pas aujourd’hui de bon parseur CSV
- L’été dernier, il a passé plusieurs semaines, voire près d’un mois, à écrire « un vrai parseur CSV » pour ajouter des fonctionnalités CSV à awk
- Il considère que la spécification CSV n’est pas totalement claire et, d’une certaine manière, pas vraiment standardisée
- pandas est présenté comme un outil puissant mais lourd
- Il explique que, dans bien des cas, il est plus simple d’écrire directement du Python que de comprendre les mécanismes implicites d’itération et de sélection propres à pandas
- L’animateur note que pandas est souvent choisi pour le machine learning et la data science, mais qu’il envisage des approches plus simples lorsque les performances d’exécution sont cruciales
- La gestion mémoire est devenue un domaine dont beaucoup de développements n’ont presque plus à se soucier
- En C, il faut gérer la mémoire soi-même, ce qui est très difficile
- En C++, c’est possible aussi, mais les techniques permettant de le faire correctement sont difficiles à maîtriser
- En Python, cela fonctionne le plus souvent « comme par magie »
- Les grosses abstractions ne masquent pas toujours complètement les problèmes
- En traitant un texte de la taille d’un livre avec spaCy, il a reçu un message indiquant un manque de mémoire, le quota de tâche par défaut étant de 1 GB ; il a résolu le problème en doublant ce réglage
- À l’époque où Kernighan grandissait, même des kilooctets représentaient déjà une grande quantité de mémoire
- Dans la communauté de l’embarqué, la mémoire et les performances restent des enjeux majeurs, et des langages comme Rust ou Zig sont aussi mentionnés dans ce contexte, pas seulement le C
Go, Plan 9 et l’environnement de recherche de Bell Labs
- L’animateur dit avoir eu l’impression que les préoccupations de The Practice of Programming avaient servi de tremplin à la conception du langage Go
- Kernighan répond que Rob Pike était l’un des trois créateurs de Go et qu’il est « tout à fait crédible » que les frustrations évoquées dans le livre aient constitué un arrière-plan lorsque l’idée d’un nouveau langage est apparue
- Il précise toutefois qu’il n’a pas de souvenir concret de Pike disant à l’époque qu’il voulait « améliorer le monde avec un nouveau langage »
- Il considère que les travaux sur Plan 9 à la fin des années 1990 ainsi que des langages comme Limbo et Alef font partie de la généalogie ayant mené à Go
- L’expérience de Bell Labs a été, pour Kernighan, proche d’un environnement idéal
- Alors qu’il était doctorant à Princeton, il y a travaillé deux étés dans les années 1960 comme stagiaire, dans un groupe lié à Multics
- L’expérience lui a tellement plu qu’après avoir reçu une proposition pour revenir, il n’a passé aucun autre entretien
- Il est resté à Bell Labs du début de 1969 jusqu’aux alentours de 2000
- À cette époque, Bell Labs permettait une réflexion de long terme et subissait peu de pression liée aux résultats trimestriels ou à la nécessité immédiate de produire des revenus
- Les chercheurs pouvaient travailler de façon relativement indépendante sur ce qu’ils jugeaient intéressant et important
- Comme AT&T fournissait alors le service téléphonique à la majeure partie des États-Unis, c’était un « environnement riche en problèmes », avec beaucoup de sujets potentiellement utiles au système téléphonique
- Il n’a jamais rencontré directement Claude Shannon
- Il croit se souvenir que Shannon était parti au MIT quelques années avant son arrivée à Bell Labs
- En revanche, Kernighan était proche de Richard Hamming, qui avait autrefois partagé un bureau avec Shannon
Apprentissage, écriture de livres et pensée informatique
- Les premiers apprentissages de Kernighan se sont faits à Bell Labs, au contact de personnes talentueuses, de bons outils et de problèmes intéressants
- yacc était un outil qui facilitait la création de nouveaux langages de programmation, et Kernighan l’a utilisé non seulement pour la génération classique de langages, mais aussi dans des domaines comme la préparation de documents et les langages déclaratifs
- Ce travail lui a beaucoup appris sur la conception et l’implémentation des langages
- Il s’est aussi longtemps intéressé aux outils de préparation de documents
- Il a été influencé par runoff, l’un des premiers programmes interactifs de préparation de texte du MIT
- À Princeton, il a écrit en Fortran un programme similaire pour produire sa propre thèse
- À Bell Labs, il a créé des outils pour faciliter matériellement la fabrication des livres et éviter que les exemples de programmes soient abîmés durant le processus d’édition
- Après son passage à l’université, le fait d’expliquer à des non-spécialistes des choses qu’il connaissait déjà est devenu une forme importante d’apprentissage
- Il devait expliquer à des étudiants plus à l’aise en littérature ou en musique comment fonctionne le binaire
- C’est aussi dans ce contexte qu’il a appris que Leibniz était l’inventeur effectif du système binaire à la fin du XVIIe siècle et qu’il avait produit quelque chose de proche de l’écriture hexadécimale en utilisant des notes de musique au lieu de lettres
- Il explique que l’envie d’écrire un livre naît lorsqu’il y a « quelque chose qui mérite d’être dit » et « un coauteur avec qui on a envie de le dire »
- La plupart de ses livres sont coécrits
- Selon lui, la collaboration rend l’écriture bien plus facile que le travail solitaire, car chacun peut compléter et affiner le propos de l’autre
Grands modèles de langage, enseignement et lectures recommandées
- Parmi les évolutions majeures de sa carrière, Kernighan cite les systèmes en temps partagé, Unix, l’évolution des langages de programmation, l’augmentation des ressources liée à la loi de Moore et le PC
- Le temps partagé a été une transformation majeure, car il permettait de travailler selon son propre rythme sans être physiquement devant l’ordinateur ni attendre l’intervention d’un opérateur
- Il voit le cloud computing comme une forme qui se rapproche à nouveau du temps partagé, dans la mesure où le calcul est centralisé et où l’utilisateur communique avec un système distant au moyen de périphériques sophistiqués
- Il considère que la technologie la plus intéressante aujourd’hui est celle des grands modèles de langage
- Il juge remarquable qu’ils aient surgi brusquement vers novembre 2022 et aient eu un impact aussi fort en si peu de temps
- Il raconte avoir demandé à Claude, en deux ou trois phrases, une tâche liée à spaCy, et avoir obtenu un code Python correct à environ 99,9 %, avec un niveau d’usage de Python plus raffiné que le sien
- Il ne pense pas que les programmeurs vont disparaître, mais estime que leur manière de travailler pourrait changer
- Les LLM ouvrent aussi de nouvelles approches pour les étudiants
- Un étudiant pense qu’ils pourraient servir à améliorer la traduction du grec ancien
- Ils pourraient aussi améliorer les résultats d’OCR de documents imprimés du XVIIIe siècle en s’appuyant sur les connaissances linguistiques des modèles
- Dans ses cours destinés aux non-spécialistes, il essaie de relier le fonctionnement des ordinateurs aux enjeux technologiques du monde réel
- Beaucoup d’étudiants viennent des humanités et des sciences sociales, et suivent ces cours pour satisfaire une exigence de raisonnement quantitatif
- Il y traite de matériel, de logiciel, de communication, de net neutrality, de privacy, de security ou encore de l’antitrust visant Google, toujours avec une base technique
- Il estime que la pensée informatique, qui consiste à découper un grand problème en petits problèmes et à raisonner par étapes, est transférable à d’autres domaines comme la rédaction d’un mémoire ou l’analyse de questions juridiques
- Pour les débutants, il est important de trouver un sujet qu’ils ont eux-mêmes envie d’explorer
- Qu’il s’agisse de créer un jeu, d’améliorer ses finances personnelles ou d’analyser un texte, partir d’un problème qui les intéresse permet de réduire la barrière psychologique
- Dans son cours pour non-spécialistes, il utilise un exercice où l’on analyse Pride and Prejudice avec NLTK, puis où chaque étudiant choisit un autre livre à explorer de la même manière
- Les livres recommandés ou mentionnés, ainsi que ses goûts de lecture, sont variés
- Parmi les livres techniques, il relit parfois The Mythical Man-Month ; il estime qu’une partie a bien vieilli, mais que certaines formulations paraissent aujourd’hui très sexistes
- Recoding America de Jennifer Pahlka est cité comme un livre intéressant sur les raisons pour lesquelles les logiciels gouvernementaux fonctionnent moins bien qu’espéré et sur la façon dont les systèmes rendent l’amélioration difficile
- Côté lectures non techniques, il mentionne l’histoire, l’histoire militaire, les romans policiers, les romans hippiques de Dick Francis, ainsi que Chip War, consacré aux semi-conducteurs
1 commentaires
Commentaires de Hacker News
Ce livre est un ouvrage fondamental que tous les programmeurs, en particulier les débutants, devraient lire.
Comme on peut s’y attendre d’un livre de Kernighan, le style est simple, concis et précis, et il va droit à l’essentiel en un peu plus de 200 pages, sans superflu. Il suffit de comprendre les principes à partir des exemples, puis de les appliquer à son propre contexte.
La force des livres de K&P, c’est qu’ils ne vous écrasent pas sous la théorie : ils montrent d’abord l’application concrète des techniques, ce qui rend ensuite l’étude de la théorie beaucoup plus accessible.
Par exemple, j’ai lu ce livre alors que j’avais déjà de l’expérience en programmation réseau et en implémentation de protocoles, et dans le chapitre « Notations », la présentation de routines pack/unpack de messages réseau qui décrivent la disposition des paquets avec des chaînes de format de style
printf/scanfa été une vraie révélation. J’y ai appris la puissance d’une notation bien choisie et des petits langages ; il y a aussi des fragments de code qui illustrent les idées de machine virtuelle, de code threading et de compilation JIT.L’ancien livre de Kernighan et Pike, « The Unix Programming Environment », vaut aussi la peine d’être lu en parallèle. Le chapitre « Program Development » présente, en une cinquantaine de pages, tout le processus de création d’un compilateur pour un petit langage de calculatrice à l’aide d’outils de développement de compilateurs ; à ma connaissance, c’est le texte le plus court et le plus simple qui explique comment écrire un compilateur.
En bref, les livres de Kernighan valent tous la peine d’être achetés et étudiés.
J’avais lu le livre sur C il y a longtemps et j’en gardais le souvenir d’un excellent style. Je vais sans doute en tirer beaucoup de sagesse en programmation, mais je veux aussi analyser, du point de vue de l’écriture technique, pourquoi les livres de Kernighan sont si bons.
Kernighan a dû beaucoup étudier l’écriture, ou au moins mener une réflexion de premiers principes assez poussée à ce sujet. Le titre « The Elements of Programming Style » fait d’ailleurs référence au célèbre livre de Strunk et White sur l’écriture, « The Elements of Style ».
C’est un peu daté selon les critères actuels, mais ça reste un livre facile à lire.
Ce n’est pas du sarcasme : j’aimerais comprendre pourquoi c’est une lecture indispensable, même pour quelqu’un dont la carrière avance confortablement.
J’aime vraiment beaucoup « The Practice of Programming ».
Parmi tous les livres de programmation que j’ai lus, ce sont les leçons de celui-ci qui me sont le plus restées. Je ne l’ai pas relu depuis des années, mais j’ai l’impression qu’il influence encore ma pratique quotidienne.
Certains exemples de programmation concrets ont assez mal vieilli, mais les idées générales restent solides.
J’aime beaucoup Kernighan. C’est quelqu’un de vraiment humble.
Dans l’une des vidéos sur YouTube, il racontait que, dans sa thèse, il travaillait sur un problème difficile qui s’est révélé plus tard être un problème NP-complet, avant que la théorie ne soit formalisée.
Je lui ai envoyé un e-mail pour demander sa thèse ; il m’a répondu assez vite, et sa lecture s’est révélée vraiment intéressante.
Pour moi et pour beaucoup d’autres, ses réflexions sur la programmation comptent parmi les plus intéressantes et les plus utiles, en grande partie parce qu’il sait les transmettre très clairement.
J’aimerais que les entretiens d’aujourd’hui évaluent plutôt la compréhension des concepts présents dans ce livre, au lieu de LeetCode.
Dans ce nouveau monde absurde, Brian Kernighan lui-même pourrait ne pas réussir un entretien LeetCode hard.
C’étaient toutes des questions de programmation assez pratiques. Chez Stripe, il y avait un entretien où ils avaient forké la bibliothèque Java Jackson, y avaient introduit un bug, puis demandaient de le trouver et de le corriger. C’était assez atypique, mais beaucoup plus proche du vrai travail de programmation.
Cela me rappelle aussi Katalin Karikó, prix Nobel pour l’ARNm, qui a été rétrogradée à l’UPenn parce qu’elle n’arrivait pas à obtenir des financements.
Un autre auteur qui appartient à la même catégorie d’excellence que Kernighan et ses livres est Jon Bentley, avec Programming Pearls et More Programming Pearls.
https://en.m.wikipedia.org/wiki/Jon_Bentley_(computer_scient...
Ce livre apprend à réfléchir à l’efficacité par le haut, en mettant l’accent sur les algorithmes et les langages, ce qui le rend utile à tous les programmeurs.
Les ouvrages modernes sur l’efficacité, comme ceux d’Agner Fog, Fedor Pikus, etc., traitent surtout des techniques de performance au niveau compilateur/système d’exploitation/processeur ; les lire ensemble permet d’avoir une vue d’ensemble.
Les amis, le g est muet.
Ce serait bien d’inviter Rob Pike. Il insisterait probablement pour corriger la prononciation. J’entends déjà sa voix.
Nous aimerions aussi beaucoup inviter Rob Pike. C’est en cours, mais il est un peu plus difficile à contacter.
Je n’ai regardé qu’environ un tiers de la vidéo, mais on voit que les animateurs posent plutôt bien des questions pertinentes.
Je suis Carter, l’un des animateurs de la vidéo. Ravi que vous l’appréciiez. C’était vraiment un immense honneur de pouvoir discuter avec Brian Kernighan.
Comme ce format traite de livres, ce serait bien de lister dans la description ou dans certains commentaires les livres abordés, et si possible une liste des médias.
J’ai ajouté « The Bit Player » (le documentaire de 2018 sur Claude Shannon) à ma liste de vidéos à regarder, et « Recoding America », « Chip War » ainsi que « Endurance: Shackleton's Incredible Voyage » à ma liste de lectures.
Ce serait bien d’ajouter aussi Software Tools in Pascal de Kernighan à la liste des livres à traiter dans le podcast.
Je possède ce livre et je le trouve bon.
Kernighan et Plaugher ont d’abord écrit « Software Tools » en RATFOR, puis « Software Tools in Pascal ». Et en réaction directe à cette expérience, Kernighan a écrit l’article « Why Pascal Is Not My Favorite Programming Language ».
Écrire en Pascal aurait dû être beaucoup plus facile qu’en RATFOR, mais ce ne fut pas le cas, et Kernighan a réfléchi aux raisons.
Cela reste un texte intéressant, que l’on peut lire par exemple ici : https://www.cs.virginia.edu/~evans/cs655/readings/bwk-on-pas...
Cela dit, l’article vise à l’origine le Pascal standard. Des extensions comme Turbo Pascal ont corrigé beaucoup de problèmes. En revanche, comme il le disait, ces extensions n’étaient pas portables entre elles. Le fait que Turbo Pascal soit devenu l’extension « standard » de facto a tout de même résolu le problème dans une certaine mesure.
J’ai été impressionné par les idées et l’écriture, et cela m’a ensuite servi de tremplin pour chercher et lire les autres œuvres majeures de Kernighan.
Kernighan est aussi coauteur du livre The Go Programming Language, au moins pour la première édition.