- Gerald Sussman explique que, depuis 1962, en passant par les premiers environnements informatiques comme l’IBM 7094, le PDP-6, Mac Hack 6 et Maxima, il n’a jamais cessé de s’attacher au plaisir de programmer en lui-même
- La programmation n’est pas un simple codage consistant à transposer mécaniquement des spécifications en code ; elle ressemble plutôt à une conception d’ingénierie abstraite, où l’on cherche à la fois les spécifications et l’implémentation possibles sous des objectifs imparfaits
- En rapprochant la structure eval/apply de Lisp et les interactions des équations de Maxwell, il voit la programmation comme une activité créative qui traite de questions conceptuelles profondes, au même titre que la physique, les mathématiques ou la philosophie
- Un bug n’est pas un simple échec, mais une occasion d’apprentissage qui apparaît quand des humains finis résolvent des problèmes à partir de plans simplifiés ; il fait partie de la « résolution de problèmes par débogage de plans presque corrects »
- La différentiation automatique, l’extension des opérations génériques de Scheme et l’expérience consistant à exprimer la mécanique classique sous forme de programmes exécutables montrent que la programmation peut clarifier d’autres disciplines ; il souligne que le plaisir est complet quand on partage sous forme de free/libre software
Conception et exploration au-delà du codage
- Sussman utilise des ordinateurs depuis 1962, lorsqu’il était lycéen, et a découvert l’informatique au Columbia Science Honors Program
- Les premiers ordinateurs, comme la famille IBM 7094, coûtaient plusieurs millions de dollars, ne pouvaient adresser que 2^15 mots de 36 bits et fonctionnaient avec un cycle d’environ 2 microsecondes
- Après son entrée au MIT, il a découvert des ordinateurs comme le DEC PDP-6, dont le système pouvait adresser 2^18 mots de 36 bits
- Une grande mémoire était nécessaire pour les premiers systèmes de manipulation symbolique comme Maxima
- Le MIT a commandé une grande mémoire à Fabritek ; sa fabrication a pris un an et, d’après les archives, elle coûtait environ 380 000 dollars
- Comme cette mémoire était très grande pour l’époque, elle a été appelée Moby, d’après le nom d’une baleine
- Il a participé à l’intelligence artificielle, à la conception de nouveaux ordinateurs, à l’invention de langages de programmation, à des simulations numériques de mécanique céleste et à l’écriture de grands systèmes symboliques, mais au cœur de tout cela se trouvait toujours son amour de la programmation
- La programmation n’est pas une tâche mécanique qui transforme une spécification bien définie en code exécutable
- Les bonnes spécifications ne viennent généralement pas d’en haut
- On explore ce qui est implémentable, puis on rédige les spécifications en fonction de ce qui peut réellement être atteint
- La programmation est donc une exploration conjointe qui cherche à la fois des spécifications et une implémentation possibles, en direction d’un objectif partiellement défini
- Contrairement à l’ingénierie physique, la programmation est davantage limitée par la capacité à organiser la pensée que par des contraintes physiques comme les tolérances, les courbures de coupe ou les erreurs de résistance
- Le programmeur manipule une immense machine virtuelle en choisissant représentations, algorithmes et niveaux d’abstraction
La programmation comme art créatif
- Pour expliquer la sensation de programmer, Sussman cite un texte dans lequel Edgar Allan Poe décrit comment il a écrit « The Raven »
- Poe y affirme que l’œuvre n’a pas été achevée par hasard ou intuition, mais étape par étape comme un problème mathématique, et révèle un processus complexe de choix, suppressions, insertions et corrections
- Ce processus est plus proche de l’expérience réelle de la programmation que du simple passage d’une spécification au code
- La programmation s’apparente à un art créatif, comme l’architecture, la musique, les mathématiques ou la physique théorique
- Les mathématiques sont une activité qui cherche à inventer de beaux théorèmes
- La physique théorique cherche à inventer des explications du monde physique
- La programmation consiste elle aussi à inventer et affiner des idées et des structures
La structure révélée par eval/apply et les équations de Maxwell
- L’apprentissage de Lisp 1.5 et de l’interpréteur eval/apply en première année au MIT a été un tournant dans la vie de Sussman
- eval reçoit une expression et un environnement, évalue l’opérateur et les opérandes pour produire une procédure et des arguments ; apply reçoit la procédure et les arguments, lie les arguments aux paramètres formels, puis revient à l’évaluation du corps
- Sussman estime que cette structure s’applique à tous les langages informatiques et au fonctionnement même des ordinateurs
- À la même époque, il a été fortement marqué par les équations de Maxwell apprises en cours d’électromagnétisme
- Maxwell a ajouté le terme de courant de déplacement pour résoudre l’incohérence entre la conservation de la charge et les équations existantes
- Il en résulte l’équation des ondes électromagnétiques, et le lien selon lequel la lumière est une onde électromagnétique
- Il existe une profonde analogie entre l’interaction eval/apply et la structure des équations de Maxwell, où champs électrique et magnétique engendrent mutuellement leurs variations
- Cette analogie rejoint aussi les relations entre variables duales, comme position et quantité de mouvement, énergie et temps
- La programmation rencontre au quotidien des questions philosophiques
- Il n’est pas trivial de savoir comment le nom
Chicagodans un programme désigne la ville réelle - L’identité de deux objets se révèle selon que la modification de l’un modifie aussi l’autre ; la mutation est liée au problème de l’identité
- Comme les programmes purement fonctionnels n’ont pas de mutation, ils doivent envisager l’identité autrement
- Dans une expression citée, le principe selon lequel « les choses identiques peuvent être substituées les unes aux autres » peut être rompu
- Des propositions comme « tous les corbeaux sont noirs » rendent difficile la signification de la preuve, comme dans le paradoxe du corbeau de Hempel
- Il n’est pas trivial de savoir comment le nom
La manière de traiter les bugs
- Sussman voit les bugs non comme des échecs honteux, mais comme des occasions d’apprendre
- Déboguer avec de bons outils peut être plaisant comme une aventure, et il affirme que les bugs devraient avoir des noms, comme fencepost error ou reader-writer bug
- Les bugs sont aussi le résultat de stratégies de conception puissantes
- Les humains ne pouvant pas penser à tout en même temps, ils élaborent des plans
- Un plan exige des simplifications, et les simplifications créent des omissions
- Des bugs en résultent, et le débogage devient le processus qui consiste à corriger un plan presque juste dans la direction souhaitée
- Sussman appelle cette approche « résolution de problèmes par débogage de plans presque corrects »
- L’exemple de la conception d’un filtre électrique illustre cette stratégie
- Pour créer un filtre ayant une réponse entre 30 Hz et 3 kHz, on factorise la fonction de transfert du système
- On combine résistances et condensateurs pour construire les sous-circuits nécessaires
- Mais chaque sous-circuit repose sur l’hypothèse qu’« aucun courant ne sort » ; les connecter ensemble provoque alors un loading bug
- Un correctif avec amplificateur peut résoudre ce problème dans certaines situations
- Tous les bugs ne sont pas amusants
- Sussman critique C et C++, qu’il juge remplis de pièges
- Il relie aussi aux logiciels écrits en C les situations où des bugs de gestion mémoire rendent fréquemment nécessaire un nouveau noyau
- Il donne aussi des exemples de manque de cohérence en Python :
{}est un dictionnaire mais{1}est un set, et un tuple est défini par la virgule plutôt que par les parenthèses
Différentiation automatique et physique exécutable
- En 1992, Sussman a passé du temps à Caltech avec le groupe de Kip Thorne pour apprendre la relativité générale, et explique avoir utilisé les programmes comme support de stockage du savoir
- Avec Dan, concepteur de puces en virgule flottante chez Hewlett-Packard, en réfléchissant à la dérivée d’une fonction, il a redécouvert indépendamment la différentiation automatique en mode direct (forward-mode automatic differentiation)
- L’objectif était une méthode qui ne soit ni une différentiation symbolique inspectant l’intérieur de la fonction, ni une approximation numérique
- Le cœur en était la règle de dérivation en chaîne, ou chain rule
- En étendant les nombres en objets différentiels possédant une partie finie et une partie infinitésimale, la chain rule fonctionne automatiquement dans la composition de fonctions
- Comme il utilisait Scheme, il a pu redéfinir les opérateurs arithmétiques primitifs pour les adapter aux objets différentiels, et Sussman raconte avoir implémenté cela en une nuit lors d’une « hack attack »
- Par la suite, plusieurs personnes ont contribué à affiner les dérivées de fonctions d’ordre supérieur, les dérivées multiples et l’extension dynamique des opérations primitives de Scheme
- Abelson a aidé à formaliser la bonne théorie des dérivées multiples
- Jeff Siskind, Barak Pearlmutter et Alexey Radul ont débogué des bugs subtils dans les dérivées de fonctions d’ordre supérieur
- Hansen a imaginé une manière d’étendre dynamiquement et efficacement les opérations primitives de Scheme
- Ce travail a conduit au système Scmutils, utilisé avec Jack Wisdom pour enseigner et étudier la mécanique classique et la géométrie différentielle
- Le livre de Sussman et Wisdom, 『Structure and Interpretation of Classical Mechanics』, vise à clarifier la compréhension de la mécanique classique au moyen de techniques computationnelles
- La notation traditionnelle des équations de Lagrange est ambiguë sans connaissances culturelles, et pose aussi problème du point de vue des types de fonctions
- Écrites en notation fonctionnelle et en code Scheme, les idées mathématiques deviennent des programmes clairs et exécutables
- Dans l’exemple de l’oscillateur harmonique, le programme calcule les équations du mouvement correctes pour la masse, la constante de ressort et la position, ainsi que la relation avec la fréquence angulaire
Le plaisir s’accomplit dans le partage
- Sussman résume le plaisir de programmer en plusieurs dimensions
- Le plaisir de découvrir de profondes analogies entre des mondes différents
- Le plaisir de rencontrer dans le travail concret des problèmes sur lesquels les philosophes réfléchissent depuis longtemps
- Le plaisir de la chasse lorsqu’on traque un bug
- Le plaisir de découvrir de bonnes idées et abstractions
- Le plaisir de clarifier d’autres disciplines grâce aux programmes
- Le plaisir de programmer s’accomplit lorsque l’on partage son travail avec d’autres, et il recommande d’utiliser et d’écrire du free/libre software
- Sussman regrette d’avoir dû enregistrer via Zoom, et dit vouloir des logiciels que l’on puisse lire, modifier et repartager
- Pour en savoir plus sur le logiciel libre et la liberté logicielle, il recommande de consulter la philosophie du logiciel libre de GNU, et invite à rejoindre et soutenir financièrement la Free Software Foundation
1 commentaires
Avis de Hacker News
J’ai vraiment aimé ce passage : « J’écris des programmes comme une façon de me souvenir de quelque chose. Ma mémoire, ce sont les programmes que j’ai écrits. Quand j’apprends des choses comme les mathématiques, la physique ou la biologie et que j’écris des programmes pour les exprimer, je peux les relire plus tard sans ambiguïté et les comprendre facilement ; c’est ainsi que je stocke le savoir. »
https://www.infoq.com/presentations/Expression-of-Ideas/
Le thème est très proche de la citation ci-dessus, et elle traite de la manière dont la programmation aide à mieux comprendre des objets comme les mathématiques et la physique.
Par exemple, la façon dont fonctionnent les analgésiques aide à comprendre les keyloggers ou les attaques de l’homme du milieu ; et en observant la « correction grammaticale » de l’ADN pendant la mitose, on peut apprendre beaucoup sur la compilation en général.
Le comportement d’un chiot qui avale tout ce qu’il voit revient à fournir au système immunitaire suffisamment de données de test sur son environnement, ce qui ressemble aussi au machine learning ; et une bonne partie des concepts de cybersécurité peuvent également se comprendre par la biologie.
Comme je pense plutôt en images, j’avais du mal à comprendre réellement les mathématiques, mais le code me permettait de créer des images et des relations dans ma tête.
J’ai eu de la chance de découvrir ça enfant ; sans cela, je pense que je me serais perdu.
Les problèmes, les décisions, les raisons, les faits qui les étayent et les alternatives examinées sont tous des connaissances ; et chaque instruction saisie dans un langage de programmation est aussi une décision.
La conception logicielle peut durer assez longtemps pour que les décisions passées et leur contexte soient oubliés ; elle peut aussi durer assez longtemps pour que des personnes partent, emportant des connaissances avec elles, et que de nouvelles personnes arrivent avec trop peu de connaissances.
Faire comprendre le code source à l’ordinateur n’est pas la partie difficile ; le plus dur est de permettre à d’autres personnes de comprendre ce qui a été accompli et de travailler mieux et plus vite.
Quand la tête et la mémoire ne suffisent plus, il faut s’aider de technologies comme l’écriture, l’imprimerie ou le logiciel pour mémoriser et organiser de plus grands ensembles de connaissances.
Mon plus gros problème avec les mathématiques était aussi que je ne pouvais pas me faire confiance pour ne pas commettre d’erreurs, ni même pour les repérer.
Un compilateur ou un interpréteur me force à m’en apercevoir.
Il y a longtemps, j’ai assisté à une conférence de Sussman dans un sous-sol de NYU avec une vingtaine de doctorants en neurosciences.
Il parlait déjà d’interprétabilité de l’IA bien avant que le sujet ne devienne à la mode.
Je lui ai posé une question ; il a immédiatement détecté qu’il y avait un ingénieur électricien dans la salle, s’est dirigé vers un tableau adjacent et a montré comment on pouvait déduire le fonctionnement d’un amplificateur opérationnel à partir des premiers principes.
Il dégageait une énergie et une intelligence extraordinaires, et il a clairement laissé une forte impression.
Je n’ai pas encore vu la vidéo, mais cela m’a immédiatement rappelé la citation d’Alan J. Perlis utilisée par Sussman et Abelson dans la dédicace de SICP.
Elle dit en substance qu’il est très important, en informatique, de préserver le plaisir de l’informatique, et qu’au début c’était vraiment amusant.
Les clients en ont parfois souffert, et nous avons commencé à prendre leurs plaintes au sérieux, mais l’idée est que nous ne sommes pas responsables d’une utilisation réussie, sans erreur et parfaite de ces machines.
Au contraire, notre responsabilité est de pousser les machines, de les envoyer dans de nouvelles directions et de préserver le plaisir ; il espère que l’informatique ne perdra pas ce sens de l’amusement, et l’essentiel est de ne pas se comporter comme des missionnaires ou des colporteurs de bibles.
Il ne faut pas penser que les clés d’une informatique réussie sont uniquement entre nos mains ; ce que nous avons entre les mains, c’est l’intelligence, c’est-à-dire la capacité de voir les machines comme quelque chose de plus grand qu’au premier contact, et de les rendre plus grandes encore.
Pour la plupart des autres, qui fabriquent des programmes pour compter des haricots, du point de vue de ceux qui paient les salaires, ne pas perdre un seul haricot est bien plus important que le plaisir que nous prenons ou l’extension des possibles.
Ce n’est pas un bug, c’est un petit morceau de fun /s
Un meilleur titre serait plutôt : « L’informatique académique est amusante, ou devrait l’être ».
Le fond, c’est que découvrir des analogies, réfléchir philosophiquement, déboguer, trouver de bonnes idées et gagner en clarté sont autant de choses amusantes ; mais cela ressemble surtout au luxe de professeurs payés pour ce genre d’activités, et cela s’accorde mal avec le monde où « le client veut ça d’ici ce week-end », à part peut-être le plaisir controversé du débogage.
La plupart de la « programmation » devrait probablement être vue davantage comme une matière d’école professionnelle, à la manière de la soudure.
Développer une nouvelle technique de soudure relève bien d’un sujet de recherche de niveau master ou doctorat, mais la plupart des soudeurs et des programmeurs travaillent avec des outils bien connus et des systèmes relativement simples.
Un élève en formation professionnelle peut ne pas vouloir perdre du temps à apprendre MIT/GNU Scheme pour ne plus jamais s’en servir dans sa vie professionnelle, tandis que pour un étudiant académique, cela peut être enrichissant, comme pour un linguiste d’apprendre à lire et écrire le linéaire B.
Toute activité peut être amusante, mais au final, des conditions comme les compétences et la stabilité émotionnelle des collègues et des managers, la conception et la sécurité de l’espace de travail, une rémunération permettant de vivre, ou l’existence d’une culture d’entreprise qui laisse passer le travail bâclé, ont joué un rôle plus important ; et il en va de même pour d’autres métiers spécialisés, comme la programmation de systèmes de contrôle industriels.
Tu constaterais que, dans tous les métiers, les personnes curieuses, réfléchies et instruites, autodidactes ou non, travaillent mieux que celles qui ne le sont pas.
Il y a longtemps, quand je travaillais comme soudeur, les personnes intelligentes, motivées et curieuses faisaient aussi mieux que celles qui se contentaient de tuer le temps.
Donc je suis d’accord pour dire que la programmation ressemble à la soudure, mais pas dans le sens que tu voulais probablement lui donner.
SICP a complètement changé ma façon de penser le code, l’abstraction et la modularité, alors que j’étais entouré de collègues qui bidouillaient en Pascal ou en C
Avec Lisp/Scheme, je pouvais construire un modèle mental du problème, tandis que mes collègues devaient faire l’abstraction dans leur tête puis l’implémenter dans des langages qui exigeaient de se concentrer sur le bas niveau
Je serai donc éternellement reconnaissant d’avoir découvert SICP tôt
Selon le langage dans lequel on programme, cela peut être plus amusant ou plus confortable
Je crois que je ne serai probablement jamais à l’aise avec C++
C’est agréable d’entendre le point de vue sur la programmation de l’un des auteurs de SICP, et les anecdotes des premières minutes sont aussi sympathiques
Quand j’ai expliqué que j’en avais absolument besoin parce que je rencontrais Sussman le lendemain, un employé a appelé le Harvard co-op ; ils en avaient un exemplaire en stock, alors j’ai pris un Uber jusqu’à la librairie de Harvard et j’ai acheté SICP
Le lendemain, en arrivant dans le bureau de Sussman au MIT, Abelson se trouvait là par hasard et s’apprêtait justement à partir ; ils ont donc tous les deux signé mon SICP
Sussman a ajouté : « Si tu étais arrivé 15 minutes plus tôt, ma femme l’aurait signé aussi ! », et jusque-là je ne savais pas que sa femme avait été la correctrice de SICP
J’ai aussi une superbe photo avec ces deux magiciens et le livre violet qu’ils venaient de me dédicacer
J’ai hâte de voir cette vidéo
Je n’ai pas encore vraiment travaillé SICP sérieusement, mais j’ai emprunté le livre et j’ai écouté les cours pendant que je faisais des travaux chez moi
Dans les cours SICP, il y a une citation de Sussman sur la compréhension des choses complexes que j’insère souvent dans des présentations liées à l’architecture ; c’est toujours la diapositive que les gens recopient frénétiquement
Honnêtement, j’ai aimé programmer pendant des années, et cela a même été mon principal hobby à une époque
J’essayais de nouveaux langages ou logiciels, je lisais des livres de programmation et je participais à divers chats comme libera/freenode
Mais en devenant freelance et en me concentrant sur la livraison rapide de code correct dans des contextes plus restreints, cette passion s’est estompée
Dans l’ensemble, c’est peut-être une bonne chose pour moi en tant qu’ingénieur, mais beaucoup de plaisir et d’apprentissage ont disparu de mon quotidien professionnel
Le freelance et le consulting consistent généralement à résoudre des problèmes, voire à les abattre comme des cibles, en les éliminant le plus vite possible, et l’élégance n’est pas indispensable
Si l’on veut être un builder qui crée des outils, je ne pense pas que cela arrive souvent en freelance ; passer à un rôle de consultant pourrait peut-être le permettre
Comme le consulting ressemble davantage à une relation à plus long terme, cela peut valoir la peine d’être envisagé comme prochaine étape