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...

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 !