Programmation en binaire absolu
Les premiers programmeurs écrivaient en binaire absolu : chaque instruction & chaque adresse en chiffres binaires bruts. Une instruction simple pouvait ressembler à 01100101 00001010 — code d'instruction & adresse mémoire en binaire.
Le problème du code spaghetti
Quand une erreur obligeait à insérer une nouvelle instruction, les programmeurs faisaient face à un dilemme. Insérer sur place signifiait que chaque adresse d'instruction suivante se décalait d'une position — forçant le programmeur à mettre à jour chaque référence d'adresse dans tout le programme. Catastrophique.
La solution : remplacer l'instruction juste avant le point d'insertion par un saut vers la mémoire vide. À cet emplacement vide : écrire l'instruction écrasée, ajouter les nouvelles instructions, puis sauter en arrière. Quand des erreurs apparaissaient dans les corrections, appliquer la même astuce à nouveau en utilisant d'autre mémoire vide.
Résultat : le chemin d'exécution à travers le programme sautait vers des emplacements apparemment aléatoires. Hamming a appelé ça 'une boîte de spaghetti'. Le chemin de flux de contrôle, dessiné sur papier, ressemblait exactement à des spaghettis emmêlés.
Les voies de sortie
Deux améliorations immédiates : la notation octale (grouper les chiffres binaires en ensembles de 3) & l'hexadécimal (groupes de 4, utilisant A–F pour les valeurs au-delà de 9). Celles-ci ont réduit les erreurs d'écriture mais n'ont pas résolu le problème d'adresse fondamental.
L'assemblage symbolique (par exemple IBM SAP — Symbolic Assembly Program — & SOAP — Symbolic Optimizing Assembly Program sur l'IBM 650) permettait aux programmeurs d'écrire des noms d'instructions (ADD, MOVE) & des étiquettes d'adresse symboliques au lieu du binaire. L'assembleur traduisait en binaire au moment de l'entrée, gérant automatiquement les assignations d'adresses.
SOAP effectuait une optimisation supplémentaire : il arrangeait les instructions sur le tambour rotatif de sorte que l'instruction suivante arrive à la tête de lecture juste au moment où la précédente se termine — codage à latence minimale. SOAP s'auto-compilait même : le programme A traité comme données pour produire B, B exécuté sur A pour mesurer combien l'auto-compilation l'améliorait.
Bibliothèques & code relocalisable
Hamming a noté que l'idée de logiciel réutilisable (bibliothèques mathématiques) est venue très tôt — Babbage l'avait conçue. Le problème : une bibliothèque à adresse absolue obligeait chaque routine à occuper les mêmes emplacements mémoire à chaque fois qu'elle était utilisée. Quand la bibliothèque totale devait trop grande, les programmes se disputaient les mêmes adresses.
La solution : le code relocalisable. L'assembleur génère des instructions qui font référence à la mémoire relativement — décalages depuis une adresse de base — plutôt que des adresses absolues. Un éditeur de liens résout les adresses finales au moment du chargement.
Les rapports non publiés de Von Neumann (largement distribués) décrivaient les astuces de programmation nécessaires. Le premier livre de programmation publié (Wilkes, Wheeler & Gill, EDSAC, 1951) codifiait ces techniques.
La bifurcation de la conception de langage
FORTRAN (1957, IBM) & ALGOL (1958, comité international) représentent deux philosophies de conception qui ont produit des résultats radicalement différents.
FORTRAN
John Backus a dirigé le projet FORTRAN (FORmula TRANslation) chez IBM. L'objectif de conception : rendre le langage facile à utiliser pour les scientifiques & ingénieurs. FORTRAN acceptait la notation mathématique qui semblait naturelle à ses utilisateurs : A = B + C * D plutôt que ADD B, C; STORE T; MULTIPLY T, D; STORE A.
FORTRAN a survécu plus de 60 ans. Il reste en utilisation active en calcul scientifique, dynamique des fluides, modélisation climatique, & physique informatique. Hamming a noté cette durabilité comme preuve d'une conception réussie.
ALGOL
ALGOL (Algorithmic Language) a été conçu par un comité de logiciens & informaticiens visant la rigueur mathématique : un langage logiquement épuré, formellement définissable. La notation Backus-Naur Form (BNF) pour décrire les grammaires a été inventée pour spécifier ALGOL.
ALGOL a échoué en pratique. Malgré son élégance logique & son énorme influence sur la conception de langages ultérieurs (Pascal, C, & presque tous les langages modernes descendent des concepts de grammaire d'ALGOL), ALGOL lui-même n'a jamais été largement déployé. Le verdict de Hamming : logiquement conçu, humainement inutilisable.
La hiérarchie des langages
Hamming a décrit une hiérarchie naturelle du code machine en passant par l'assemblage, les langages de plus haut niveau, & ultimement un 'langage orienté problème' proche de la façon dont les praticiens pensent à leur domaine problématique. Chaque niveau ajoute de la lisibilité humaine au prix de l'efficacité machine.
Les quatre critères de conception de langage de Hamming
Hamming a distillé la leçon de FORTRAN vs ALGOL en quatre critères pour un langage de programmation réussi :
1. Facile à apprendre — un novice peut devenir productif rapidement
2. Facile à utiliser — les tâches courantes nécessitent une cérémonie minimale
3. Facile à déboguer — les erreurs produisent des messages significatifs & localisables
4. Facile à utiliser des sous-routines — la réutilisation & l'abstraction ne nécessitent pas un effort héroïque
Il a ajouté une observation structurelle : la langue humaine porte environ 60% de redondance ; la langue écrite environ 40%. Les langages à faible redondance (comme APL) produisent des one-liners élégants que les experts trouvent beaux & que les débutants trouvent opaques — & qui contiennent des erreurs indétectables quand un seul caractère change de sens.
L'implication : un langage conçu pour l'élégance logique optimise pour le mauvais lecteur. Le programmeur est humain ; les humains ont besoin de redondance pour attraper les erreurs & communiquer l'intention.
Conception de langage psychologique vs logique
Hamming est revenu au contraste FORTRAN/ALGOL comme une leçon en dynamique institutionnelle & humaine, pas seulement en conception de langage.
FORTRAN a été conçu psychologiquement — pour les humains qui l'utiliseraient, spécifiquement les scientifiques qui pensaient en notation mathématique. ALGOL a été conçu logiquement — pour la correction formelle & l'élégance théorique.
Le paradoxe que Hamming a identifié : un langage logiquement correct que les humains résistent échoue ; un langage pragmatiquement conçu que les humains adoptent réussit, même s'il est logiquement plus désordonné.
Il a cité APL comme le cas extrême : logiquement élégant, exprimable en one-liner, avec son propre ensemble de caractères spéciaux. Les experts l'adoraient. Les programmeurs normaux le trouvaient illisible. Un changement de caractère unique pouvait transformer silencieusement le sens d'un programme. APL a une petite communauté dévouée & presque zéro utilisation dominante.
L'argument de redondance humaine : la langue parlée est ~60% redondante (contexte répété, mots clarifiants, structure prévisible). La langue écrite ~40% redondante. Cette redondance sert à la détection d'erreurs — les humains sont peu fiables, la langue a donc évolué pour porter assez d'information répétée pour attraper & corriger les erreurs. Un langage à faible redondance supprime ce filet de sécurité.
La hiérarchie des compilateurs
Hamming a décrit la mise en couches des compilateurs/interpréteurs : un programme peut lire dans un langage de plus haut niveau & le traduire dans un langage de plus bas niveau. Empilez ces couches — chacune traduit un niveau vers le bas. En haut : un langage orienté domaine que les experts dans un domaine (biologie, finance, physique) écrivent naturellement. En bas : le code machine. Chaque transition est un compilateur ou interpréteur.
Prédire la survie des langages
En 1993, Hamming avait observé de nombreux langages réussir & échouer. FORTRAN (1957) a survécu. ALGOL (1958) a échoué. COBOL (1959) a survécu des décennies dans l'informatique commerciale. LISP (1958) a survécu dans la recherche en IA. PL/I (1964) a essayé d'unifier tout & a échoué.
Le motif récurrent
Le chapitre sur l'histoire du logiciel de Hamming contient une structure récurrente :
1. Une limitation douloureuse existe (adresses absolues, notation binaire, code non maintenable)
2. Quelqu'un invente une couche d'abstraction qui cache la limitation
3. L'abstraction permet une nouvelle échelle, qui crée de nouvelles limitations douloureuses
4. Répéter
Binaire → octal/hexadécimal → langage d'assemblage symbolique → FORTRAN → programmation structurée → langages orientés objet → langages spécifiques au domaine. Chaque couche résout la douleur la plus aiguë du prédécesseur tout en introduisant une nouvelle classe de problèmes.
La douleur du code spaghetti (adresses absolues) a mené au langage d'assemblage symbolique. Les grands programmes en langage d'assemblage ont mené à FORTRAN. Les grands programmes FORTRAN ont mené à la programmation structurée & ensuite à l'orientation objet. La lecture de Hamming s'est terminée avant ces transitions ultérieures, mais le motif continue.
Sa leçon pour les ingénieurs : vous résolvez toujours la douleur exposée par l'abstraction précédente. Comprendre la couche sur laquelle vous êtes actuellement obligeait à connaître pourquoi la couche en dessous existe.