Si vous vous êtes déjà approché d'un ordinateur, ne serait-ce que de loin et avec des gants, vous devez avoir remarqué que l'informatique semble régie par une loi fondamentale. Les anglicistes et les snobs la baptisent parfois Loi de Murphy, mais en bon français, il s'agit de la LEM (Loi de l'Emm... Maximum). Dave nous propose ce mois-ci la première partie d'une étude de LEMologie, science de l'étude de la LEM, dans laquelle il est passé maître. La LEM a quatre conséquences principales, qui ont été identifiées et formalisées par Dave, sous le nom des Quatre Lois de Small. Croyez-en son expérience...
J'ai passé au moins 60% de mon existence à m'occuper d'ordinateurs. En
fait, comme mes cinq ou dix premières années n'ont pas été
informatisées, elles font baisser la moyenne : actuellement, c'est
plutôt 75% de mon temps que je consacre à l'informatique. Durant tout
ce temps, j'ai remarqué que ces machines ont une certaine propension à
n'en faire qu'à leur tête, et de ces observations sont nées les
Première, Seconde, Troisième et Quatrième Lois de Small.
En bon
bidouilleur, je voudrais partager l'information et vous épargner
d'avoir à les redécouvrir par de tragiques expériences où vous
pourriez perdre votre candeur. Si vous voulez bien me suivre...
Première loi de Small (dite "Loi de l'Effort Maximum") "Quelle que soit la façon dont vous vous y prenez pour résoudre un problème donné, il vous faudra faire le plus grand effort possible" |
Permettez-moi d'illustrer cet énoncé de quelques
exemples. Naturellement, je vous fais confiance pour en fournir plein
d'autres quand vous aurez vu où je veux en venir.
Supposons que vous utilisiez OUTlL 1.0, un programme qui accomplit une
tâche donnée. Un beau jour, OUTlL 2.0 sort, et la publicité affirme
qu'il est cinq fois plus rapide. Vous avez un projet qui nécessite
l'emploi d'OUTIL, version 1 .0 ou 2.0.
En achetant la mise à jour, vous espérez donc pouvoir effectuer ce
travail 5 fois plus rapidement, libérant ainsi 80% de ce temps pour
d'autres tâches - que vous pourrez consacrer à faire avancer vos
travaux informatiques, ou à votre famille et vos amis.
Mais la Loi de l'Effort Maximum est là pour anéantir tout espoir
concernant ces 80% de temps libre, quoi que vous fassiez. Il se
produira quelque catastrophe. J'en ai fait la cruelle expérience tant
de fois que c'en est devenu une règle pour moi (je m'attends à
l'inévitable, mais ne croyez pas que j'aime ça !).
J'en vois qui hochent la tête en disant : "Ce pauvre Dave a été
traumatisé par ses bogues, il est trop pessimiste." Hélas non ! Par
exemple...
OUTlL 2.0 aura fatalement quelque incompatibilité avec la version
1.0. Tenez, ce bogue bien connu de la 1 .0, vous aviez appris à le
contourner, et vous aviez mis au point une bidouille pour l'éviter. Eh
bien, le bogue a été corrigé, et désormais, votre bidouille plante. Ou
encore, alléché par les nouvelles fonctionnalités de la 2.0, vous vous
hâtez d'en tirer parti. Mais comme tout nouveau code, ces
fonctionnalités ont introduit de nouveaux bogues, qu'il vous faudra
découvrir et apprendre à contourner, au prix d'un temps
considérable. C' est la raison pour laquelle je m'en tiens obstinément
à un seul jeu d'outils, tout en tenant une liste des bogues identifiés
pour chaque outil. Ce n'est qu'en maugréant et en traînant des pieds
que je change d'outil.
Ce type-là de catastrophe m'est arrivé de nombreuses fois, et j'ai un
wagon entier d'histoires vécues pour le prouver.
Tenez, essayez donc de mettre deux labels sans opération entre eux sur
deux lignes consécutives en AS68, l' assembleur livré avec le kit de
développement original d'Atari dès 1985. C'est parfaitement
licite. Vous pouvez par exemple avoir besoin de mettre un label à une
routine dont le début est aussi celui d'une boucle, et vous avez deux
labels ROUTINE1 et BOUCLE consécutifs.
Eh bien, AS68 n'aime pas cela. Mais attention, il ne va pas cracher un
message d'erreur, que nenni, ce serait trop facile ! Non, ce que va
faire AS68, c'est décaler de deux octets chaque adresse de saut
relatif assemblée après ces deux lignes (une adresse de saut relatif
est en fait un nombre d'octets en plus ou en moins à sauter dans le
code pour atteindre la destination du branchement). Vous avez bien lu
: chaque adresse stockée dans le programme exécutable sera fausse à
partir de ce point ! Le décalage est cumulatif. Si vous avez à nouveau
un double label plus loin dans le code, le décalage sera de 4 octets,
puis de 6, et ainsi de suite, à chaque BRA ( branchement), JMP (saut)
ou JSR (appel de sous-programme). Et il est très difficile de s'en
apercevoir, parce qu'on soupçonne son code ou sa machine avant de
penser qu'un assembleur est capable de bêtises pareilles. Cela produit
des plantages vraiment curieux. J'ai ainsi découvert, à mon grand dam,
que le second mot d'une instruction en langage machine 68000 est
habituellement une donnée. Quand un saut aboutit sur celle-ci, on
obtient un plantage "instruction illégale"... dans le meilleur des
cas. Le pire survient lorsque la donnée, par un malheureux hasard, est
interprétée comme une instruction valide, ce qui fera planter le
programme plus loin, lançant le malheureux programmeur sur une fausse
piste.
Et après "La vengeance du double label", voici "La malédiction de l'
assemblage conditionnel". l'assemblage conditionnel consiste à prendre
en compte ou non certaines parties du code d'après la valeur de
certains symboles. Eh bien, lui aussi provoque le fameux décalage de
deux octets des sauts.
Nous continuons notre festival des horreurs avec "L'écraseur de
fichiers fou contre- attaque". Il est 5 h du matin... La nuit sans
lune n'est éclairée que par la lampe du bureau d'un pauvre programmeur
(la caméra s'approche lentement de celui-ci, vu de dos)... La future
victime, fatiguée, a un instant d'absence et tape innocemment AS68 -L
MONPROG au lieu de AS68 -L MONPROG.S. Froidement, AS68 écrit son
fichier de sortie par dessus le code source, le fameux fichier de
suffixe ".S" amoureusement peaufiné, l'écrasant irrémédiablement !
(Violons suraigus, la victime s'arrache les cheveux et s'effondre en
sanglotant...) Ahurissant, non ? J'ai massacré mon code source un bon
nombre de fois, perdant à chaque fois des heures de travail, et je
suis devenu totalement paranoïaque quant à mes sauvegardes. Dan Moore
a finalement résolu le problème par un petit utilitaire appelé à la
place de AS68. Si le nom du fichier ne se termine pas par ".S", tout
s'arrête, sinon, AS68 est effectivement exécuté. Cela m'a sauvé
maintes fois.
Il y a encore d'autres histoires d'horreur sur AS68, LO68 et RELMOD,
les outils du kit de développement initial d'Atari, mais je vous les
épargnerai, sinon, il faudra rebaptiser ce journal "Freddy Krueger
Magazine".
Et pourtant, j'ai utilisé ces outils à longueur de journée, que ce
soit pour écrire Spectre ou des programmes publiés dans le magazine
américain START. Car je connaissais leurs bogues. Avant de commencer
un nouveau projet, je relisais rapidement la liste de bogues et me
remémorais qu'il fallait éviter telle et telle manip.
J'ai laissé tomber AS68, qui était abominablement lent, en faveur de
DevPak ST et de DevPak TT de la firme anglaise
HiSoft. Malheureusement, HiSoft change sans arrêt de distributeurs, ce
qui fait que j'ignore à qui vous pouvez les commander à l'heure où
vous lisez cette saga. Si vous cherchez un assembleur et savez où vous
procurer DevPak, n'hésitez pas, c'est un bon produit. Rapide de
surcroît : il laisse sur place AS68. Mais il m'a fallu pas mal de
temps pour convertir mes sources du format AS68 au format DevPak (il
n'y a hélas pas de format standard pour le code assembleur). Par
exemple, la déclaration d' une variable longue d'un mot s'écrit "VAR1
.dc.w $0" en AS68, mais "VAR1 dc.w $0" en DevPak. Notez la différence,
le point devant le mot-clé "dc". Cela n'a l'air de rien, et faire
cette modification est d'ailleurs automatisable par un
Cherche/Remplace, mais il y a d'autres différences plus ou moins
importantes. Et dans un programme de 25000 lignes comme Spectre, ces
modifications mineures, mises bout à bout, m'ont pris plusieurs jours
! En passant à DevPak, nous avons dû abandonner LO68 et Relmod pour
ALN, le nouvel éditeur de liens d'Atari. ALN est beaucoup plus rapide
que les programmes qu'il remplace, mais très délicat à paramétrer. Il
nous a fallu un temps fou pour trouver la bonne combinaison d'options
et de paramètres afin qu'ALN se comporte comme nous le
souhaitions. Niveau de débogage, sensibilité aux
majuscules/minuscules, longueur des labels... Il devait y avoir 64
combinaisons possibles, c'est naturellement la 64ème qui était la
bonne.
Ce fut donc une parfaite illustration de la Première Loi de
Small. DevPak nous a sans doute fait gagner un facteur 10 en temps
d'assemblage, mais ce gain de temps a été totalement anéanti par un
temps de débogage et de paramétrage dix fois plus long.
Reprenons notre utilitaire OUTlL. Admettons que la version 2.0 soit
parfaitement compatible avec la 1 .0 (ce que, personnellement, je n'ai
jamais vu). Eh bien, un autre type de catastrophe se produira. C'est
obligatoire : il se produira fatalement quelque chose pour vous faire
utiliser ce temps que vous pensiez pouvoir gagner. Tenez, une fois,
Dan Moore a cru pouvoir gagner du temps sur la maintenance du code de
Spectre en en réécrivant une partie en C' ce qui fut long et
pénible. Hélas, lorsqu'une structure contenait des déclarations de
variables longues d'un octet, le compilateur alignait celle-ci sur les
mots. Autrement dit, il insérait des zéros dans la structure entre les
octets pour aligner ceux-ci sur des adresses paires. Inutile de dire
que cela faisait planter tout ce qui utilisait ces structures. Dan n'a
pas pu trouver un moyen d'éviter cet alignement automatique, et a dû
se résoudre à abandonner ce compilateur.
Et si ce n'est pas un outil qui vous fait faux bond, c'est le système
d'exploitation. En transférant un fichier source de 600000 octets
entre un lecteur de disquettes externe Toshiba 2000SX et le ST, les 51
2 premiers octets du fichiers sont répétés ad nauseam jusqu'à remplir
les 600 Ko. Inutile de dire qu'en éditant le fichier, on a la surprise
de sa vie. C'est un bogue qui n'est toujours pas corrigé en TOS 1
.4. Je me suis laissé dire que le problème provient des tables
d'allocations de fichiers (FAT) d'un kilo-octet de ces lecteurs
externes, que le TOS ne supporte pas. Il lui faut des FAT de 2 Ko. Le
format du Toshiba n'a donc pas l'heur de plaire au TOS, que ce soit en
simple ou en double face. Il faut savoir que le DOS, la partie du TOS
qui gère les disquettes, a été réécrit, parce que l'ancienne version
devenait affreusement lente lors de la création d'un fichier sur un
disque dur presque plein... entre autres bogues. Et cette nouvelle
version, au lieu de lire sur le disque la taille de la FAT, suppose
bêtement que la FAT fait toujours 2 Ko. Je sais même qui a fait cette
bourde (mais il ne travaille plus chez Atari). Merci, gars, c'est
sympa, on se souviendra de toi.
Croyez-moi, il se produira fatalement quelque chose. Et encore, si
c'est un bon gros cataclysme bien franc, qui anéantit proprement tous
vos espoirs, estimez-vous heureux. Parce que dans le pire des cas,
vous aurez en fait droit à une multitude de petits incidents
insignifiants. Vous serez submergés par une infinité d'anicroches qui,
prises une à une, n'ont rien d'effrayant, mais qui vous pourriront la
vie en survenant toutes en même temps. Comme devoir renommer 36
sous-répertoires pour faire plaisir à un utilitaire. Ou ajouter une
ligne de directives d'édition de lien à chacun des 58 fichiers de
votre code. Cela prend un temps fou, comme j'ai pu m' en rendre compte
: c'est exactement ce que j'ai dû faire pour Spectre 3.1.
Et finalement, tout le temps que vous aviez cru pouvoir économiser
avec OUTlL 2.0 sera gaspillé en préparations et corrections pour
adapter la nouvelle version à vos besoins. Conclusion : au lieu de
vous jeter sur la version 2.0, vous feriez aussi bien d'aller jouer au
golf.
La Loi de l'Effort Maximum marche aussi dans les activités non
informatiques. En cherchant bien, je suis persuadé que vous vous
souviendrez de moult occasions où vous auriez pu gagner du temps
si... si un minuscule incident n'était pas survenu. Vous étudiez
soigneusement un itinéraire et découvrez qu'on peut emprunter un
raccourci ? Paf ! Une déviation ou un accident viennent l'obstruer. Ça
marche à tous les coups. La possibilité de trouver un raccourci
dégagé n'existe pas, sauf dans les films.
A mon grand regret, je dois vous dire qu'il existe une raison physique
sous-jacente à cette folie apparente, et que tout espoir d'échapper à
cette loi est donc vain. Cette raison, on la trouve dans la physique
quantique, qui remonte à 1 926. Il s'agit d' un ensemble de lois
régissant le comportement des particules subatomiques, et expliquant
des événements incompréhensibles pour la physique newtonienne. Et vous
allez voir que la physique quantique s'accorde parfaitement avec la
Première Loi de Small.
Tout d'abord, ne croyez pas que seul les savants atomistes soient
concernés par la physique quantique. Les transistors, briques de base
des circuits intégrés de nos Atari (entre autres), fonctionnent selon
ses principes. Et de nombreux physiciens de haut niveau pensent que la
physique quantique ne se contente pas de décrire ce qui se passe
réellement au plus profond de la matière, mais qu'elle décrit aussi
notre univers quotidien.
Petit exemple : dans tout le Colorado, on peut ramasser des rochers de
pechblende, qui contient de l'uranium naturel. De temps à autre, un de
ces atomes fissionne, c'est-à-dire qu'il se casse en deux tout en
émettant deux neutrons (ou plus). Comme l'uranium n'est pas concentré,
il ne se produit nulle réaction en chaîne ou explosion. Mais quel est
l'atome qui va éclater ? On ne peut pas le prédire. Et tout semble
indiquer que c'est impossible.
Mais... mais... Et là, je vais vous demander de me croire sur parole
(et d'aller lire un bouquin d'initiation à la physique quantique, qui
est ce qui se rapproche le plus de la magie)...
Ce qui se produit est totalement différent selon que cette fission est
observée ou non. l'observation pouvant d'ailleurs être soit directe
(par détection des neutrons émis grâce à un compteur Geiger), soit
indirecte par détection de phénomènes induits par cet événement. Selon
que l'événement quantique (la fission) est observé ou non, il y aura
littéralement deux histoires possibles pour cet atome ! Ces deux
histoires surviennent en parallèle dans le temps. Dans l'une, l'atome
fissionne, dans l' autre, il reste intact. Chacune de ces histoires
forme un "continuum d'espace- temps", ce qui signifie "région d'espace
dans un temps donné". Il n'y a rien de sorcier à ce sujet, même si la
science-fiction abuse du terme. Mais la Nature ne fait son choix entre
ces deux continuums possibles que si l'événement est observé ! Sinon,
elle s'en contrefiche, et les deux possibilités coexistent. Car la
Nature fait rarement plus que le strict nécessaire (tout comme moi
d'ailleurs) . Et si un observateur est présent et voit l'atome éclater
(ou non), Maman Nature va "effacer" le mauvais continuum (celui qui
correspond à l'événement contraire), qui cessera d'exister. Mais
seulement dans ce cas.
Ce concept d' histoires parallèles a été développé par Richard
Feynman, brillant physicien plein d'humour et prix Nobel de physique
[NdT : Feynman est mort en 1989.] C'est
également lui qui a compris pourquoi la navette Challenger a
explosé. Il faisait partie de la commission d'enquête. Durant une
réunion, il a pris un échantillon du matériau dont étaient faits les
joints toriques des boosters à poudre de la navette, et l'a laissé
tremper dans de l'eau avec des glaçons durant la pause de midi. Il a
pu alors montrer que le matériau du joint n'était plus souple, mais au
contraire dur et cassant, ce qui explique la défaillance du joint le
jour du lancement, jour où, précisément, il gelait. Bref, ce n'est pas
un idiot.
C'est donc avec la caution d'un éminent scientifique que j'ai formulé
ma Première Loi. Il y a deux continuums d'espace-temps, l'un dans
lequel vous ne prenez pas le raccourci et où il est dégagé, l'autre
dans lequel vous prenez le raccourci et où il est barré par une
déviation. Vous en choisissez un et l'autre cesse d' exister. Pas
d'autre possibilité. Certes, c'est un peu déprimant, mais c'est ainsi
que marche la Nature...
Dans n'importe quelle réunion, on peut entendre des histoires prouvant
la Loi de l'Effort Maximum, venant en général de gens qui ont essayé
une astuce quelconque pour gagner du temps et ont échoué pour quelque
raison bizarre. Je l'affirme haut et fort : ce n'est pas là l'effet
d'un mauvais sort, mais bien la façon dont les choses se passe
naturellement. Par analogie, considérons à nouveau un rocher de
pechblende. Il est impossible de savoir quel atome d'uranium va
fissionner à un instant donné, mais en revanche, en connaissant la
quantité d' uranium dans le rocher, on peut statistiquement prédire,
avec une grande précision, combien de désintégrations atomiques se
produiront. l'incertitude quantique débouche sur une certitude
statistique : un certain nombre de fissions doit avoir lieu. Eh bien,
en informatique, c'est pareil. Vous ne savez pas précisément quelles
calamités vont s'abattre sur vous, mais c'est mathématique, elles vont
survenir. Le temps que vous comptiez gagner doit être dépensé.
Pour rester encore un peu dans ce domaine fascinant, permettez-moi de
revenir sur un postulat majeur de la physique moderne, à savoir que
rien ne peut se déplacer plus vite que la lumière, y compris
l'information. C'est précisément ce qui pousse les ingénieurs à
miniaturiser toujours davantage les circuits pour pouvoir déplacer
davantage d'information dans des temps de plus en plus brefs. Depuis
qu'Einstein l'a formulé en 1915, ce postulat a fini par être
universellement accepté. Mais peut-être est-ce aller un peu vite en
besogne. Steven Hawking, dans son nouveau livre (excellent !)
intitulé "Trous noirs et bébés- univers", dit que les particules plus
rapides que la lumière sont probablement nécessaire pour que l'univers
fonctionne correctement ! Attention, il ne s'agit pas d'un mystique du
Nouvel Age, mais de Steven Hawking, l'homme qui a récupéré la théorie
du Big Bang dans la poubelle où ses contradictions l'avaient amenée,
et l'a si bien peaufinée qu'elle est à présent presque universellement
admise. C' est aussi l'auteur d",Une brève histoire du temps", un
incroyable best-seller expliquant comment l'on a pu déterminer l'état
de l'univers une infime fraction de seconde après le Big Bang.
L'argument d'Hawking est simple. Comme chacun sait, les trous noirs
sont des étoiles qui se sont effondrées sur elles-mêmes, concentrant
toute leur masse sur un infime diamètre, ce qui engendre une gravité
si intense que rien, même pas la lumière, ne peut s'en échapper. De
nombreux vulgarisateurs ont présenté les trous noirs comme le destin
ultime de l'univers, car ces astres dévorent toute la matière qui
passe à leur portée. (Et il semble que dans la constellation du Cygne,
nous en ayons un bon exemple). Mais, souligne Hawking, une particule
entrant dans un trou noir a en fait deux histoires distinctes (ça ne
vous rappelle rien ?). Car pour une telle particule, le temps ralenti
de plus en plus jusqu'à s'arrêter quand elle entre dans le trou noir,
en raison de l'intense champ gravitationnel qui y règne. Mais alors,
elle viole le principe d'incertitude de Heisenberg, dont j'ai parlé
dans un précédent article. [NdT : voir ST-Mag n°
78.] En effet, si le temps se fige pour cette particule, on peut
prédire à la fois sa position et le moment où elle l'occupera. Or, le
principe d'Heisenberg a été maintes fois validé, et rien n'indique
qu'il cesse d'être valable dans ces conditions. Donc, selon Hawking,
une particule se sent moralement obligée de sortir du trou noir tôt ou
tard, et la seule façon d'y parvenir est d'aller plus vite que la
lumière. Cela implique qu'un trou noir laisse graduellement s'échapper
des particules, perdant progressivement de sa masse... ce qui peut
équilibrer la matière absorbée par l' astre. Les trous noirs ne sont
donc peut-être pas le destin ultime de l'univers.
C'est cette bidouille mathématique d'Hawking, simple mais géniale, qui
fait de lui LE bidouilleur subatomique, par excellence
[NdT : en français dans le texte.]
Cela pourrait signifier que le siècle qui a vu naître la limite
absolue de la vitesse de la lumière pourrait bien aussi voir cette
limite s'évanouir. Les astronomes et les physiciens du monde entier
discutent fébrilement cette théorie dont les implications sont
ahurissantes.
Voilà donc ma Loi de l'Effort Maximum. Et c'est sans grand effort qu'on en trouve des exemples dans la vie de tous les jours. Je me suis contentée de lui trouver un nom, je ne prétends pas l'avoir découverte. J'espère que vous êtes soulagé, maintenant que vous savez qu'il est impossible d'y échapper !
Traduction et adaptation: Password90