On peut y arriver (2003)
(multicians.org)- Lors de la refonte du système de fichiers Multics chez Honeywell Cambridge, André Bensoussan a pris en charge le VTOC manager, un sous-système central, de la conception jusqu’aux tests
- Ce module devait déplacer les informations descriptives des fichiers entre le disque et la mémoire, tout en gérant aussi le buffer pool et l’espace disque, ce qui en faisait en pratique une sorte de petit gestionnaire de mémoire virtuelle
- André ne codait pas directement devant le terminal : il peaufinait schémas et code au crayon, en cherchant une conception symétrique capable de contenir les informations d’état
- Après la saisie du manuscrit final, les seuls problèmes rencontrés à la première compilation furent trois fautes de frappe, et l’exécution après liaison au système a réussi du premier coup
- Le seul bug découvert ensuite venait du fait que Tom Van Vleck avait indiqué dans le mauvais ordre l’ordre d’appel de la procédure de traitement des erreurs, ce qui montrait à quel point le programme lui-même était abouti
Travail sur le VTOC manager de Multics
- André Bensoussan a travaillé avec Tom Van Vleck chez Honeywell Cambridge sur le système d’exploitation Multics
- Une modification de grande ampleur du système de fichiers nécessitait un sous-système appelé VTOC manager
- déplacer les informations descriptives des fichiers entre le disque et la mémoire
- gérer le buffer pool en mémoire partagée
- gérer l’espace disque destiné aux informations sur les fichiers
- En raison de ce rôle, le VTOC manager devait fonctionner comme un petit gestionnaire de mémoire virtuelle
- André était chargé de la conception, de l’implémentation et des tests de ce module
Un programme achevé au crayon
- André s’est d’abord assis à son bureau pour dessiner de nombreux schémas
- il voulait une forme agréable à lire et symétrique, tout en contenant toutes les informations d’état
- au point que son entourage s’inquiétait du retard pris dans l’écriture du code à cause du calendrier
- Il a aussi codé non pas au terminal, mais au crayon
- il a refusé l’aide à la saisie
- il a réécrit certaines parties, recopié, effacé et corrigé jusqu’à produire le manuscrit final
- Après avoir entièrement saisi le manuscrit final au crayon dans le terminal, la première compilation a échoué, mais elle a réussi après correction de trois fautes de frappe
- Une fois lié au système et exécuté, cela a fonctionné du premier coup, et par la suite le VTOC manager a continué à fonctionner parfaitement
- Le seul bug découvert venait du fait que Tom Van Vleck, interrogé par André sur l’ordre d’appel de la procédure de traitement des erreurs, avait répondu de mémoire sans vérifier
- un crash s’est produit lors du premier passage par ce chemin d’erreur
- en dehors de cela, le programme ne présentait aucun problème
1 commentaires
Réactions sur Hacker News
Je pense que la raison principale pour laquelle il a pu le faire, c’est que les exigences étaient définies très clairement
Aujourd’hui, si les logiciels sont si souvent lents et pleins de bugs, c’est en grande partie parce que personne ne sait vraiment ce qu’on est en train de construire, ou que, même si on le sait, ça change sans arrêt à cause de l’« agile »
Si on donne aux développeurs une API claire et des critères bien définis, la plupart écriront du code qui fonctionne très bien
Les exigences, ce n’est pas empiler des listes et des tickets sur un tableau Kanban, c’est réellement apprendre le domaine de ce qu’on veut construire
On peut construire quelque chose dans un domaine qu’on ne comprend pas, mais le résultat a de fortes chances d’être médiocre ; si on accepte ce processus de production de déchets comme un brouillon permettant d’apprendre le problème métier et les solutions possibles, alors ça va
Il n’y a pas de raccourci vers la qualité
Si vous êtes partie prenante, vous devez pouvoir accéder aux personnes qui construisent l’application et vérifier qu’elles comprennent le domaine. C’est possible sans les harceler en permanence
Il faut se méfier des fanfarons qui enchaînent les buzzwords
Si vous êtes designer ou programmeur, vous devez vérifier que les parties prenantes et les experts métier sont actifs et réellement impliqués. Sinon, obtenir les exigences et la compréhension du problème devient aussi pénible qu’arracher des dents
Certaines parties prenantes ne veulent peut-être même pas résoudre le problème, voulaient peut-être partir dans une direction complètement différente, ou sont contrariées pour des raisons politiques. Il n’y a presque rien qui fasse couler un projet aussi sûrement qu’une partie prenante paresseuse ou désengagée
Les parties prenantes ne savent pas ce qu’elles veulent, tout en réclamant au hasard des fonctionnalités supplémentaires ou de gros changements
On finit par devoir gérer une multitude de cas particuliers pour forcer l’outil à faire des choses qu’il n’est pas censé faire
Les designers conçoivent souvent sans tenir compte des fonctionnalités nécessaires, du comportement du système existant, ou des demandes des parties prenantes ; et les équipes qui développent les différentes parties du système travaillent en silos sans vraiment communiquer
Des processus « agiles » mal conçus essaient de tout faire entrer dans une période donnée sur la base d’estimations douteuses
Au final, ces problèmes empêchent le système de fonctionner comme prévu ou le transforment en amas de bugs
Si les exigences sont claires et ne changent pas, que les membres du projet communiquent bien et qu’on a un contrôle total sur le processus, alors ça se passe bien. Le cas décrit dans l’article semble être de cet ordre
Je travaille surtout dans de grandes entreprises, et 90 à 99 % de ce qui arrive relève du cas moyen
Mais il existe d’innombrables cas spéciaux façon licorne, qui ne se produisent qu’une fois tous les trois ans, au moment où une éclipse lunaire et une éclipse solaire coïncident pendant que des sorcières lancent des sorts dans la forêt
Comme il faut les gérer dans le code au lieu de les traiter manuellement, cela crée des bugs et augmente énormément la quantité de code à relire et à maintenir
Et ne me lancez même pas sur la maintenance. C’est un sujet douloureux
Les exigences changent toujours. C’est une force de la nature ; il n’existe pas de monde où tout le monde sait dès le départ ce qu’il faut construire, reçoit une API entièrement spécifiée, puis part dans sa grotte pour l’implémenter
La réalité ne fonctionne jamais comme ça, et si vous avez besoin de ces conditions, alors le génie logiciel n’est probablement pas le bon métier pour vous
S’il n’y avait pas d’utilisateurs, mon logiciel serait parfait ;)
J’ai travaillé avec quelqu’un qui avait fait défection depuis l’Union soviétique. Il disait que si les programmeurs soviétiques étaient aussi bons, c’était parce que l’accès aux ordinateurs était extrêmement limité
Quand on doit programmer au crayon et sur papier, on a envie que ça marche dès la première exécution
Coïncidence amusante : nous travaillions chez Honeywell
Dans ce cas, était-ce une bonne méthode de formation, ou simplement un bon filtre pour écarter les moins motivés ?
À l’école, on ne pouvait pas utiliser d’ordinateur pendant les cours, donc on avait l’habitude de programmer sur papier, et même de déboguer ainsi
En rentrant chez moi, je l’ai saisi et exécuté, et je me suis demandé si je pourrais reproduire la fameuse anecdote sur Multics
La première compilation a échoué, mais après avoir corrigé un seul nom de variable, tout a parfaitement fonctionné
Pendant quelques années, dans la boucle édition → compilation → sortie, je trouvais les listings imprimés bien supérieurs à un terminal, parce qu’il était difficile de parcourir, déplacer et modifier efficacement le code
L’arrivée de meilleurs éditeurs visuels, de terminaux plus grands, et de compilations et exécutions plus rapides a fini par améliorer les choses
Pour prendre une analogie, c’était comme les premières armes à feu. La poudre humide, les mécanismes à silex peu fiables et le fait de devoir tout bourrer dans le canon rendaient cette période de transition depuis l’arc long assez peu efficace
Dans le précédent fil HN sur cet article, il y a un bon commentaire du compte jrd259, qui a travaillé avec André : https://news.ycombinator.com/item?id=18415231
Il parle de l’importance d’un grand bureau et d’un espace de travail personnel sans notifications
Cela me rappelle deux fois où j’ai programmé sur papier dans ma vie
La première, c’était vers 10 ou 12 ans. J’étais allé chez mes grands-parents, qui n’avaient ni ordinateur ni smartphone, mais il y avait une machine à écrire mécanique qui pouvait frapper en noir et en rouge via un sélecteur
Mon principal hobby à l’époque, c’était Turbo Pascal, donc j’ai tapé à la machine un programme Pascal que je comptais saisir plus tard sur le PC à la maison pour l’exécuter
Comme je suis resté une semaine chez mes grands-parents, j’avais largement le temps de réfléchir, de déboguer à la main et de retaper les parties erronées
La deuxième fois concerne Ziim, un langage de programmation ésotérique que j’ai créé (https://esolangs.org/wiki/Ziim), ainsi que la fonction d’addition binaire sur cette page
Cette fonction était énorme, complexe, et comportait un bug. Je savais qu’il y avait un bug parce que je l’avais exécutée dans l’interpréteur, mais je ne savais ni où était le problème ni comment le corriger
Par hasard, j’ai dû prendre un car longue distance d’environ 6 heures, et c’était l’occasion parfaite pour déboguer
J’ai recopié la fonction d’addition de Ziim au crayon sur du papier quadrillé, puis je l’ai exécutée à la main étape par étape dans le bus. J’ai pu trouver et corriger le bug, et j’ai dû refaire entièrement l’agencement de la fonction
La leçon, je suppose, c’est qu’imposer volontairement des limites à sa capacité à faire les choses de la manière facile peut parfois mener à un code mûrement réfléchi
Cela dit, je ne fais pas ça d’habitude. Je passe aussi très vite à écrire des snippets à la va-vite et itérer, ou à exécuter ligne par ligne avec un débogueur. Il faudrait peut-être que j’y repense
Mais si on fait tout sur papier, cela finit par ne plus être très différent du fait de travailler directement sur l’ordinateur. On se met à tout écrire, et on perd cette abstraction et cette prudence
Quand j’ai commencé, c’était la toute fin de l’ère des « gros ordinateurs »
Autrefois, un « programmeur » était le plus souvent proche d’un opérateur de saisie, et c’était souvent une femme
Ceux qui écrivaient les logiciels rédigeaient leurs programmes sur papier dans des bureaux pleins de fumée de cigarette
Le temps de calcul était cher et rare. Si un bug apparaissait à l’exécution, on n’avait aucune chance de le corriger avant d’avoir à nouveau un créneau de saisie, puis un autre créneau CPU
Cela encourageait donc l’approche mesurer deux fois, couper une fois
À l’époque, la plupart des logiciels étaient assez modestes comparés à ce que nous tenons aujourd’hui pour acquis, ce qui rendait cette méthode plus facile. De plus, les entrées et sorties des logiciels étaient extrêmement limitées, on ne parlait même pas encore d’interface utilisateur, et connecter des périphériques était une affaire sérieuse
De nos jours, quand j’écris du logiciel, je procède souvent en le « jetant contre le mur pour voir ce qui colle ». Il est plus simple d’écrire du code à moitié abouti et de le déboguer dans l’IDE
Mon développement logiciel a plutôt un caractère itératif, et j’en ai parlé ici : https://littlegreenviper.com/miscellany/evolutionary-design-...
Je me souviens d’un devoir à l’université où il fallait écrire un petit noyau de système d’exploitation
Je ne connaissais pas vraiment le C, et je n’avais qu’une compréhension théorique de ce que faisait un noyau, mais je devais écrire quelques centaines de lignes de C pour gérer les tâches
Je pensais que si ce programme ne fonctionnait pas, il serait presque impossible à déboguer parce que c’était du code concurrent, et que les bugs se manifesteraient sous forme de conditions de course impossibles à identifier
J’ai raisonné sur l’ensemble du système, puis j’ai passé plusieurs jours à écrire en réfléchissant énormément à une multitude de petites fonctions indépendantes
Ensuite, j’ai compilé et exécuté le tout et, après avoir corrigé l’évidente erreur de compilation du « point-virgule manquant », cela a marché du premier coup
Chaque fois qu’une réalisation impressionnante est publiée, les commentaires cherchent généralement à y trouver des défauts. J’aimerais que ça s’arrête
Au lieu de concevoir un gestionnaire de mémoire virtuelle pour un nouveau système d’exploitation, ils ne sont plus qu’un engrenage dans une machine qui transforme des requêtes SQL en HTML pour montrer des publicités aux enfants et aux personnes âgées
Difficile de ne pas devenir cynique et amer
En réalité, non. C’est précisément à cela que doit ressembler une discussion
C’est vrai dans une certaine mesure, mais une meilleure question, tournée de façon positive, serait : comment parvenir aujourd’hui, dans un environnement d’entreprise, à une situation où des réalisations comparables sont possibles ?
C’est généralement ce que je constate chaque fois que je vois ce genre de réaction. Il faut simplement un peu de temps pour que le filtre de modération par les utilisateurs fasse remonter les meilleurs commentaires
Si cette personne avait dû affronter le défi que j’ai vécu, elle se serait simplement effondrée
À l’époque, les logiciels étaient bien plus petits
Aujourd’hui, dès qu’un projet dépasse un peu le stade du programme-jouet, il fait généralement plusieurs mégaoctets, et il est impossible de l’« écrire d’un seul jet » dans un fichier unique.
C’est plus gros et plus complexe que ce sur quoi la plupart des gens travaillent aujourd’hui. Une grande partie du travail actuel ressemble davantage à du code de collage gonflé pour assembler du CRUD/REST et ce genre de choses.
Ce code est peut-être plus petit que l’ensemble d’un projet en nombre de lignes, mais plus gros que l’unité que les gens manipulent réellement. Et ce n’est encore qu’une partie du code complet du système d’exploitation.
C’est tout le « gestionnaire chargé d’administrer les informations descriptives des fichiers ». Il devait transférer les informations de fichiers entre le disque et la mémoire, gérer un pool de buffers en mémoire partagée, et aussi gérer l’espace disque destiné à ces informations.
Que se passerait-il si on demandait à la plupart des programmeurs d’aujourd’hui d’écrire maintenant, dans le langage de leur choix, quelque chose avec les mêmes exigences et la même sémantique ?
La plupart seraient déjà perdus rien qu’au stade de l’imaginer. Quant à l’écrire sur papier, le saisir et le faire fonctionner, ce serait encore bien plus difficile.
Une petite partie correspond à des URL de composants électroniques, mais près de 90 % n’est que du texte en anglais. Et 10 % consistent en citations de textes d’autres personnes, de pages web, de notes d’application de fabricants, de livres, etc.
C’est un fichier unique, et il le restera probablement jusqu’à la fin de l’année, voire au-delà. Si cela continue au même rythme, il atteindra 12 mégaoctets. Il n’y a là rien d’impossible.
Si cela vous intéresse, vous pouvez faire
git clonehttp://canonical.org/~kragen/sw/leatherdrink.gitPour l’instant, j’y ai commité la toolchain avr, donc cela pèse presque 200 mégaoctets, et il y a aussi des photos, des vidéos et des schémas.
Pour un langage de programmation, l’augmentation mensuelle en octets serait plus faible, mais sans doute d’un facteur cinq environ.
Le code écrit par André Bensoussan est ici : https://multicians.org/vtoc_man.html
Au moment de m’asseoir à mon bureau pour commencer à travailler et enfin terminer quelque chose que je rechignais à faire, je me suis naturellement dispersé et j’ai eu envie d’aller voir les nouvelles sur reddit ou HN.
J’ai ouvert HN, et le premier titre était celui-ci.
« On peut le faire »
Ça m’a motivé.
P.-S. : bien sûr, j’ai aussi lu l’article :)
« Comment André a-t-il pu faire ça sans autre outil qu’un crayon ? »
Quand je suis entré au lycée à 14 ans, j’écrivais la plupart de mon code sur papier pendant les cours de programmation.
J’étais un enfant pauvre dans un pays pauvre, et non seulement je n’avais pas de PC à la maison, mais les rares « ordinateurs » de la salle informatique de l’école étaient des clones du ZX Spectrum incapables d’exécuter le langage de programmation que nous utilisions alors, Turbo Pascal.