4 points par GN⁺ 2024-11-17 | 1 commentaires | Partager sur WhatsApp
  • À l’occasion d’un livre prêté à un étudiant pour ses lectures d’été, Simon Dobson se rappelle que SICP est l’ouvrage d’informatique qui a eu la plus grande influence sur sa carrière et ses intérêts de recherche
  • Contrairement aux cours d’introduction centrés sur Pascal, ce livre part des valeurs, des noms, des liaisons et du contrôle pour montrer ce que la programmation peut être
  • Abstraction lambda, calcul d’ordre supérieur, flux, évaluation paresseuse, interpréteurs et compilateurs, ramasse-miettes, mémoire virtuelle, langage machine, jusqu’aux langages spécifiques à un domaine, le tout relié dans Scheme
  • Son plus grand impact tient à la conception en couches, qui organise des systèmes complexes en plusieurs niveaux de langage, et à une vision de l’informatique comme discipline du « comment faire » plutôt que du « ce que c’est »
  • Le livre acheté en 1988 valait encore la peine d’être relu utilement en 2010, et SICP reste un ouvrage fondamental durable en informatique

Première rencontre avec SICP

  • Après avoir prêté à un étudiant Structure and Interpretation of Computer Programs comme lecture d’été, Simon Dobson s’est souvenu que ce livre était, pour lui, ce qui se rapproche le plus d’un ouvrage fondamental pour toute l’informatique
  • Son titre complet est Structure and Interpretation of Computer Programs, de Hal Abelson et Jerry Sussman ; il a été publié par MIT Press en 1984 et est aussi connu sous le nom de SICP
  • Le livre est toujours publié, et disponible intégralement en ligne
  • Dobson a découvert ce livre comme manuel recommandé après avoir terminé son premier cours de programmation, en deuxième année de son premier diplôme à Newcastle upon Tyne
  • Alors qu’il cherchait sa voie en informatique, SICP ne lui a pas montré « la programmation de l’époque » incarnée par Pascal, mais les formes possibles de la programmation

Des concepts construits dans Scheme

  • SICP commence par les éléments de base de la programmation — valeurs, noms, liaisons, contrôle — puis s’étend à un large éventail de sujets
    • abstraction lambda et calcul d’ordre supérieur
    • structures de données complexes contenant du calcul
    • modularité, mutabilité
    • flux
    • évaluation paresseuse
    • construction d’interpréteurs et de compilateurs
    • gestion du stockage, ramasse-miettes, mémoire virtuelle
    • langage machine
    • langages spécifiques à un domaine
  • L’étendue du propos est presque déconcertante, mais l’écriture et la construction des auteurs lui donnent une vraie cohérence
  • En particulier, tous les concepts sont traités dans un même cadre de langage, Scheme, et chaque notion nouvelle est construite à partir de ce qui a été appris auparavant

Concevoir des programmes comme on conçoit des langages

  • Le deuxième aspect de SICP qui a eu une grande influence est la manière dont Hal Abelson et Jerry Sussman voient tout comme un exercice de conception de langage
  • Le livre met l’accent sur la conception en couches, qui consiste à organiser des systèmes complexes en plusieurs niveaux de langage
    • chaque niveau est construit en combinant des composants considérés comme primitifs à ce niveau
    • les composants créés à un niveau servent d’éléments primitifs au niveau suivant
    • le langage de chaque niveau possède ses éléments primitifs, ses moyens de combinaison et ses moyens d’abstraction adaptés à ce niveau de détail
  • L’abstraction hiérarchique elle-même est familière aux informaticiens, mais la différence importante ici est l’idée que chaque couche doit être programmable
  • Dans cette perspective, une couche n’est pas simplement un dispositif pour cacher de l’information, mais un moyen de traiter le calcul et les transformations
  • Dans les langages de programmation dominants, cette stratification débouche difficilement sur une extension du langage lui-même
    • Java reste Java du haut en bas ; il a des classes et des bibliothèques, mais pas de nouvelles structures de contrôle
    • même si une structure de langage dédiée à un domaine précis serait utile, il est difficile de l’ajouter facilement dans le langage
    • inversement, si l’on veut empêcher l’usage d’une structure donnée dans un domaine, on ne peut pas la retirer du langage
    • Java-ME a retiré certaines fonctionnalités pour fonctionner sur de petits appareils, mais ce n’est pas quelque chose que l’on peut faire sans réécrire le compilateur

Le « comment faire » plutôt que le « ce que c’est »

  • Le troisième impact majeur tient à la vision de SICP sur ce que l’informatique étudie réellement
  • SICP voit la révolution informatique comme une révolution dans la manière de penser et d’exprimer la pensée
  • Le livre décrit cela comme une épistémologie procédurale (procedural epistemology)
    • si les mathématiques classiques fournissent un cadre précis pour traiter le « ce que c’est »
    • le calcul fournit un cadre précis pour traiter le « comment faire »
  • Dobson a déjà défendu l’idée que l’ordinateur est comme un nouveau microscope, qui aide les approches existantes tout en ouvrant de nouvelles sciences
  • Cette dimension du « comment faire » en informatique réapparaît dans plusieurs domaines
    • la description du fonctionnement de réseaux de capteurs capables de s’adapter tout en reflétant en continu les phénomènes dans lesquels ils sont déployés
    • l’interprétation de grands volumes de données extraites et combinées à l’échelle du Web
    • la capture de méthodes et de processus scientifiques en vue de les automatiser
  • La richesse de ces domaines encourage une intégration par les langages de programmation plutôt que par des logiciels packagés, et pousse à maintenir les interfaces et les structures flexibles et expérimentables avec des langages comme R

Pourquoi ce vieux livre reste lu

  • À l’intérieur du livre de Dobson figurait une date d’achat, septembre 1988 ; en 2010, cet ouvrage de près de 22 ans restait toujours pertinent
  • Il considère que SICP est presque le seul livre d’informatique de cet âge à pouvoir être utilement relu, et pas seulement pour un intérêt historique
  • Dans les livres de mathématiques, il n’est pas rare que le contenu dure longtemps, mais c’est plus inhabituel en informatique, où les idées évoluent vite et où beaucoup de sujets sont éphémères
  • Le fait que le contenu de SICP ait si peu vieilli montre que le livre a bien saisi les concepts essentiels de l’informatique
  • Pour ces raisons, SICP fait partie des rares livres d’informatique qui valent la peine d’être lus plus d’une fois ; comme les Lectures on Physics de Feynman en physique, il est considéré comme un livre qui distille de façon accessible l’essence de son domaine et résiste à l’épreuve du temps
  • La mise à jour du 27 janvier 2024 indique que le livre figure aussi dans l’annotated Lisp bibliography sous l’entrée Structure and interpretation of computer programs

1 commentaires

 
GN⁺ 2024-11-17
Avis de Hacker News
  • Les « classiques » comme SICP parlent de conception de programmes, mais aujourd’hui la conception de systèmes me semble être une compétence bien plus importante
    Je ne sais pas si les systèmes distribués relèvent de « l’informatique », mais ce sont, en pratique, des problèmes qu’il faut résoudre beaucoup plus souvent
    J’ai tendance à rendre les systèmes aussi simples que possible, à utiliser des outils d’observabilité pour repérer les zones où la conception est insuffisante, puis à sortir des structures de données ou des solutions plus « informatiques » quand c’est nécessaire
    Dans la plupart des cas, la notation grand O et la complexité en temps d’exécution n’ont pas d’importance, et on peut résoudre beaucoup de problèmes avec des tableaux et des CPU rapides
    Même quand un problème de performance apparaît, il faut d’abord profiler pour trouver le goulot d’étranglement
    L’informatique n’enseigne pas très bien le fonctionnement du cache mémoire du CPU
    Un bel algorithme de graphe peut avoir une meilleure complexité en temps d’exécution, mais ruiner le cache CPU et donc être plus lent qu’un tableau qui l’exploite bien
    Les problèmes réellement plus courants consistent à gérer la tolérance aux pannes, l’exactitude des verrous et files distribués, ainsi que la scalabilité des systèmes
    J’ai une formation en informatique/électrotechnique, donc je suis peut-être biaisé

    • Pour concevoir des systèmes, il faut avoir un point de vue d’implémentation ; même si l’on remonte la chaîne de valeur jusqu’à la conception, on ne peut pas faire l’impasse sur l’expérience des couches inférieures
      J’ai appris le cache mémoire du CPU il y a 30 ans, au premier semestre de licence d’informatique, avec le livre de Hennessy et Patterson, et à ma connaissance il est toujours utilisé
      La tolérance aux pannes, l’exactitude des verrous et files distribués, ainsi que la scalabilité des systèmes étaient aussi abordées en licence d’informatique, et je n’avais pas de formation particulière en informatique/électrotechnique
    • L’informatique et le développement logiciel sur le terrain ont un peu divergé
      Il existe toujours du travail consistant à créer des frameworks, des moteurs de bases de données et des outils de gestion de versions, et ce type de travail exige au quotidien des connaissances approfondies en informatique comme les algorithmes et les structures de données
      Mais ces postes sont moins nombreux qu’avant, et pour une application on utilise plus souvent Postgres que l’on n’implémente soi-même un moteur de base de données
      La grande majorité du travail consiste à implémenter de la logique métier ; savoir comment une base de données fonctionne en interne permet d’obtenir de meilleurs résultats, mais on peut produire beaucoup de logiciels qui fonctionnent sans savoir comment les index sont stockés sur disque
      Beaucoup de diplômés en informatique s’imaginent que leur travail consiste à écrire des frameworks, alors qu’en réalité il consiste à utiliser des frameworks existants, à implémenter de la logique métier, et à s’appuyer sur leur formation en informatique pour comprendre ces frameworks en profondeur
    • Traditionnellement, le domaine des bases de données se concentre beaucoup sur la résolution de problèmes algorithmiques liés au traitement de données bien plus volumineuses que ce qui tient en mémoire
      Les données existent sous forme de « pages » sur disque, et la RAM dispose d’un nombre fixe de « slots de pages »
      Déplacer des pages entre le disque et la RAM est lent, il faut donc le réduire autant que possible
      Ainsi, même des problèmes qui paraissent triviaux deviennent intéressants. En informatique classique, il n’existe pas vraiment de notion distincte de « jointure », parce que ce n’est pas assez complexe pour mériter un nom
      On peut facilement considérer la recherche algorithmique comme une sorte d’essence pure, mais on peut aussi voir l’efficacité des algorithmes comme n’ayant de sens que dans un contexte donné de données et de matériel
      C’est ce qui rend le travail intéressant, et comme il ne suffit pas d’appliquer partout des bibliothèques ou des recettes toutes faites, l’expertise algorithmique reste utile
    • C’est vrai, mais je pense que non seulement les juniors, mais aussi des programmeurs expérimentés ont souvent du mal au niveau tactique du codage
      Je galère en ce moment avec un composant sur lequel je dois faire une petite modification : il contient inutilement beaucoup d’état et manipule deux abstractions à la fois
      Il traite des fichiers tout en utilisant à la fois le système de fichiers et la base de données pour stocker l’état ; j’ai été surpris de voir à quel point la conception était mauvaise
      J’ai passé plusieurs jours à éviter de simplement ajouter une couche par-dessus, comme d’habitude, ce qui l’aurait rendu encore plus difficile à comprendre
      La culture des pull requests semble avoir conduit à approuver n’importe quelle cochonnerie sans prendre le temps de réfléchir en profondeur au code réel
      J’aimerais que les revues de code en personne reviennent
    • Je me demande si tu as lu Software Design for Flexibility: How to Avoid Programming Yourself into a Corner de Chris Hanson et Gerald Jay Sussman
      Paru en 2021
  • Le lien vers l’exemplaire gratuit du livre est cassé
    https://mitp-content-server.mit.edu/books/content/sectbyfn/b...
    https://web.mit.edu/6.001/6.037/sicp.pdf
    Je n’avais jamais vu de version PDF officielle jusqu’à aujourd’hui
    Vers 2001, seule la version HTML était gratuite, et quelqu’un l’avait convertie en TeXinfo : https://www.neilvandyke.org/sicp-texi/
    Si vous voulez suivre SICP aujourd’hui, vous pouvez exécuter le code dans MIT Scheme ou DrRacket : https://www.neilvandyke.org/racket/sicp/

    • Pour ceux qui voudraient essayer MIT Scheme, les mainteneurs actuels ne fournissent plus de .dmg, mais la version x86_64 de MIT Scheme peut être téléchargée et compilée
      La version actuelle (v12.1) fonctionne sur les Mac avec CPU Intel sous Sequoia, ou sur Apple silicon via Rosetta
      Cela dit, le compilateur de code natif est un peu cassé, et il n’est probablement pas nécessaire pour SICP
      Il me semble que cela fonctionnait sur les macOS antérieurs à Monterey, donc une dépendance fournie par Apple a peut-être changé, mais je n’ai pas creusé
      Si vous n’avez pas absolument besoin de MIT Scheme et ne voulez pas vous battre avec la compilation, Racket peut être un meilleur choix
    • À noter : je recommande de le faire avec Racket
      Il me semble qu’il existe un mode SICP explicite
      J’ai essayé de le faire avec GNU Guile, mais de petites différences de syntaxe entre Guile et MIT Scheme ont rendu l’exercice assez pénible
    • Si vous voulez le lire dans un navigateur, il me semble que la version TeXinfo a servi de source à une belle version HTML5
      La mise en forme est meilleure que celle de l’original du MIT : https://sarabander.github.io/sicp/
    • Il faut savoir que le « langage de dessin » du chapitre 2 n’est pas pris en charge par MIT Scheme en 2024
      Il existait autrefois un paquet, mais il n’est plus maintenu depuis près de 20 ans
      En revanche, DrRacket dispose d’un paquet dédié pour résoudre ces exercices
    • DrRacket inclut SICP et HTDP sous forme de packs pédagogiques
  • On peut regarder les cours filmés de 1986 dans lesquels Abelson et Sussman enseignent le contenu de ce livre
    Leur explication de la manière de créer et de relier plusieurs couches d’abstraction m’est encore utile aujourd’hui, aussi bien personnellement qu’en mentorat
    Dans la vidéo, c’est la leçon 3A, à 1:07:55
    https://m.youtube.com/playlist?list=PLE18841CABEA24090

    • La blague sur la Kabbale me fait rire à chaque fois
    • En regardant ce genre de vidéos, il est étrange de se dire que ces gens n’avaient aucune idée de ce qui allait arriver ensuite
  • The Elements of Programming Style mérite d’être lu trois fois, et je l’ai relu bien plus souvent que cela avec profit
    Si cela vous intéresse, j’en ai écrit une critique en 2010 : https://reprog.wordpress.com/2010/03/06/programming-books-pa...

    • Je pensais que vous parliez de Elements of Programming, de Stepanov et McJones, et honnêtement je pourrais lui faire la même recommandation et lui attribuer la même valeur
      https://elementsofprogramming.com/
  • La partie que je préfère dans SICP, et qui me reste en tête depuis des années, est l’idée de programmation par souhait
    C’est une manière de construire quelque chose de haut en bas, comme si les routines de bas niveau existaient déjà
    Ensuite, on descend jusqu’au fond en créant réellement ces routines de bas niveau
    Je trouve que cette façon de penser s’accorde très bien avec le développement piloté par les tests
    On écrit d’abord des tests pour la fonctionnalité que l’on aimerait avoir, puis on va satisfaire ce souhait
    La plupart des développeurs semblent construire de bas en haut, pour finalement obtenir quelque chose que personne ne voulait

    • Si l’on procède ainsi, c’est parce qu’on recherche la performance et le naturel
      On peut souhaiter par accident quelque chose dont on ne connaît pas encore la vraie nature, et se retrouver avec un fragile bazar tout en bas
      C’est généralement ce qui arrive, car la nature algorithmique des choses n’est que rarement intuitive
      Commencer par le bas, c’est comme partir des quarks que l’on possède réellement, plutôt que de se dire « si seulement la magie existait »
      Il n’y a pas de magie, et quand on arrive tout en bas, on trouve des quarks au lieu de particules magiques ; au passage, on perd aussi les indices contextuels qui aideraient à convertir entre ces deux physiques
      Les deux approches sont utiles. Pour résoudre des problèmes profonds, il faut parfois oser souhaiter
      Mais personnellement, je préfère placer la magie dans la couche juste sous le sommet
      On construit de bas en haut, puis juste avant la logique métier, on crée une couche magique de commodité qui fait les allers-retours avec le langage métier
      Ainsi, cela reste ajustable et ne produit pas un enchevêtrement jusqu’au plus bas niveau
    • Le Dr Donald Knuth a lui aussi utilisé à peu près cette approche en écrivant TeX
      Il a d’abord écrit un système de mise en forme/balisage qui lui semblait approprié, puis a imaginé un mode de programmation adapté au markup — donc des macros — avant de passer à l’implémentation
      J’essaie une approche similaire dans mon travail sur une bibliothèque pour modéliser du G-code dans OpenSCAD
      Je l’ai récemment réécrite en OpenPythonSCAD « pur », donc j’espère qu’elle deviendra utilisable
    • Le monde Smalltalk prend bien en charge cette approche avec la programmation dans le débogueur
      Pharo vaut le coup d’être essayé
  • Le SICP est le meilleur livre à lire comme premier livre quand on étudie l’informatique
    Après avoir programmé pendant des années en amateur, lu des livres sur la programmation structurée et touché à plusieurs langages, de Pascal à Common LISP, j’ai utilisé Abelson & Sussman dans un cursus d’informatique de premier cycle, et ça m’a ouvert les yeux
    Il montre la simplicité, la beauté et l’interactivité de Scheme, tout en enseignant que l’informatique consiste à empiler des couches de différents types d’abstraction
    On part de l’abstraction procédurale et de l’abstraction de données, puis on va jusqu’à définir soi-même des langages spécifiques à un domaine et à implémenter leur compilateur, voire à définir du nouveau matériel dans du logiciel
    Tout paraît si naturel, et seul un véritable maître peut donner cette impression
    Cela dit, il faut acheter la 2e édition, pas la 1re ni une édition plus récente
    L’édition récente utilise Python au lieu de Scheme, et ce n’est pas terrible

  • J’avais vraiment envie d’aimer SICP, mais Lisp m’a freiné
    J’aime Haskell et Standard ML
    Je me demande si d’autres ont eu une expérience similaire
    Un livre proche de SICP dans l’esprit, mais qui utiliserait un autre langage comme support, serait intéressant
    Je n’ai pas envie de faire SICP en JavaScript

    • L’article de 1987 A Critique of Abelson and Sussman or Why Calculating is Better than Scheming pourrait vous intéresser : https://dl.acm.org/doi/10.1145/24697.24706
      L’auteur propose d’utiliser KRC ou Miranda comme alternative à Scheme
      Je ne connais pas bien KRC, mais Miranda est un langage de programmation fonctionnelle à typage statique qui a influencé Haskell
    • SICP n’est pas un livre sur Lisp, mais il utilise les propriétés propres à Lisp pour montrer des concepts importants qu’il serait difficile de reproduire facilement dans un autre langage
      Un livre semblable à SICP sans utiliser Scheme ou Lisp serait soit complètement différent de SICP, soit, au minimum, incapable d’enseigner la même chose
      D’après mon expérience, Haskell et ML étaient beaucoup plus difficiles à comprendre que Scheme, donc je serais curieux de savoir ce qui vous a paru difficile
    • J’avais vraiment envie d’aimer SICP, et si je l’avais lu il y a 15 ans, je l’aurais probablement aimé
      J’ai commencé à le lire le mois dernier et j’ai trouvé qu’il couvrait trop large
      Il survole trop de principes mathématiques intéressants, puis passe au sujet suivant au moment où ça devient amusant
      Autrement dit, c’est trop superficiel
      Avec le recul, le fait que j’avais déjà vu beaucoup de cours ou de documents dérivés de SICP n’a pas aidé non plus : à chaque nouveau sujet introduit, je me disais « encore ça »
    • Je comprends ce sentiment. Lisp m’a repoussé, et c’était parce que je n’étais pas assez intelligent
      Je me suis quand même forcé à aller jusqu’au bout, et comme je n’étais pas assez intelligent pour manier Lisp, j’ai au contraire énormément appris
      Comme je passais beaucoup trop de temps à lire le code, j’ai l’impression d’avoir appris davantage que je ne l’aurais fait avec un langage familier
      Il existe aussi une version Python de SICP
      Je ne l’ai pas suivie jusqu’au bout moi-même, je l’ai seulement parcourue rapidement, donc ce n’est pas une recommandation, mais je laisse le lien comme preuve de son existence
      https://wizardforcel.gitbooks.io/sicp-in-python/content/0.ht...
    • Functional Programming in Scala, aussi appelé Red Book of Scala, me semble être un livre qui enseigne à penser de la même manière que SICP tout en utilisant un langage typé
      Les deux livres sont d’ailleurs côte à côte dans ma bibliothèque, et ils valent clairement la peine d’être lus
  • À la deuxième lecture, je me suis plongé dans les notes de bas de page et la bibliographie, et il y avait là aussi tout un monde magnifique
    Si ma mémoire est bonne, il existe un article où Sussman et son équipe conçoivent un processeur programmable sur mesure pour calculer des propriétés de corps célestes, c’est-à-dire des trajectoires
    Comme toujours, c’est vertigineux

  • SICP m’a fait comprendre tôt qu’il existait plusieurs modèles de programmation, alors qu’en licence je n’avais appris qu’un nombre limité de modèles
    C’est l’un des livres qui m’ont donné le sentiment de pouvoir m’orienter dans la documentation de n’importe quel langage, bibliothèque ou framework

    • L’un des meilleurs cours de programmation que j’ai suivis à l’université était un cours de langages de programmation comparés, qui couvrait plusieurs langages pendant environ deux semaines chacun
  • À côté de SICP, je mettrais aussi toute la série The Little * parmi les ressources qui valent la peine d’être lues au moins deux fois
    Types and Programming Languages est très bien aussi
    Pour ce que je fais, c’est de l’informatique applicable, mais il ne faut pas seulement lire : il faut aussi implémenter
    Sans répétition, on en oublie une partie
    Peut-être parce que je le connaissais et le respectais personnellement, mais je relis assez souvent les livres et articles de Dijkstra
    Ils sont aujourd’hui difficiles à appliquer directement, mais ils sont bons pour le cerveau, et je le considère personnellement comme un excellent auteur