Guerre dans l'ordinateur STM 61

Pour paraphraser le Victor Hugo qu'on apprenait jadis a l'école, l'article de ce mois-ci aurait pu s'intituler "Tempête sous un capot de bécane". En fait, tous les programmeurs ont un jour connu des frustrations à cause d'un système ou d'un langage informatique. Dave, grand bidouilleur devant l'Eternel, ne fait pas exception, et a d'autant plus souffert qu'il a écrit beaucoup de code. Or, on peut profiter des frustrations d'autrui de deux manières en évitant de refaire les mêmes erreurs, et en se divertissant du spectacle. C'est à joindre ainsi l'utile et l'agréable que nous convie Dave. En démolissant au passage certaines idées reçues...

Avertissement

   Dans certains de mes articles précédents, j'ai fait preuve d'une certaine modération, d'une retenue un peu guindée.Si, si. Des histoires gentillettes, des questions métaphysiques. Je m'amolissais.

   Mais cette douceur joviale, quoique fort respectable, peut se révéler lassante. C'est pourquoi ce mois-ci, j'engage un chargeur, je mets une bastos dans le canon, j'ôte le cran de sécurité, je mets le sélecteur de tir sur "rafale", et j'ouvre le feu ! Accrochez-vous, c'est parti !

Qu'est-ce que la programmation?

   Certaines personnes croient encore que la programmation est un ensemble de principes théoriques rigoureux, décrits en algorithmes approuvés, délicatement écrits en "Pascal structuré", et compilés par quelque pauvre microprocesseur soigneusement tenu en laisse. En tout cas, c'est comme ça qu'on enseigne la programmation. J'en ai été victime lorsque j'ai passé mon Bachelor of Science [NdT : équivalent d'un bac ou d'une première année de licence] dans la section d'informatique d'une grande université. Ce n'est pas du tout ça. Jack Tramiel a dit que « les affaires, c'estla guerre ». Peuh ! Les affaires, c'est en donner aux gens pour leur argent. La véritable guerre, c'est la programmation !

   Prenons par exemple ma bidouille de l'année 1988, le Spectre 128. Un cliché usé voudrait que j'aie arpenté le gazon d'un campus par une journée ensoleillée, créant les algorithmes voulus dans ma tête, puis que je me sois assis devant un écran dans une salle emplie de musique New Age, et que j'aie frappé le programme en Pascal avec les dix doigts. Eh bien, croyez-moi, cela ne s'est pas passé ainsi. Oh, non.

   Le développement du Spectre ressembla plutôt à un combat à la baïlonnette. Je me battais contre des circuits intégrés diaboliques, des monstres froids, sans aucun doute communistes, qui faisaient tout ce qui était en leur pouvoir pour ne pas fonctionner.

Dave incendie le Pascal

   Pour comprendre combien les ROMs du Macintosh sont maléfiques, vous devez d'abord apprendre à connaître le Pascal, car les ROMs ont été en majeure partie écrite en ce langage.

   Le Pascal a rampé hors de sa crevasse au début des années 70, et s'est répandu comme une épidémie dans les universités, corrompant l'esprit de milliers d'innocents. Les créateurs du Pascal étaient épouvantés par les « langages non structurés ». Pour eux, le monde de la programmation était une jungle. Personne n'y suivait aucune règle. Personne ne s'y pliait à aucun standard. Rien n'y était normalisé.

   Or, les langages non structurés, comme le Basic, permettaient au programmeur de faire absolument ce qui lui chantait. Faire un saut en tout point du programme, n'importe quand. Passer d'un endroit à l'autre avec moult ruses. S'arranger pour que ça tourne, quoi. « Horreur ! », s'exclamèrent les Pascaldroïdes. En parfaits bureaucrates, ils avaient pour le contrôle absolu un amour à faire blêmir Big Brother. lls entamèrent donc une campagne pour ôter au programmeur sa liberté de mouvement.

   D'abord virent les slogans. « Codage en spaghetti ! » ; « Mauvaises habitudes de programmation ! » ; « L'important, ce n'est pas de faire un code qui marche, c'est d'en faire un qui soit beau ! »... Puis, dans un grand brouillard de confusion mentale, les Pascaldroïdes lâchèrent le Grand Mensonge : vous devez décomposer tout programme en quelques structures de contrôle. Si-Alors-Sinon. Faire-Tant que. Et le terrifiant GOTO fut banni.

   Arrivèrent d'autres slogans. « Structures de contrôle » ; « code élégant ». Et le pirede tous : « Code auto-documenté ». Celui-ci est bien le pire. ll suppose que la prochaine personne qui lira votre code est un mutant télépathe, capable de deviner l'usage de votre programme en en lisant le code, pas les commentaires.

    Première loi de Small :

    ll n'y a pas de code auto-documenté. Si vous n'avez pas davantage de commentaires que de code, c'est du boulot de cochon.

   Ce que les zélateurs du Pascal n'ont jamais, au grand jamais, pris en compte, c'est la couche de séparation que le Pascal interpose entre l'ordinateur et vous. La vitesse d'exécution des programmes se mit à baisser, parce que les compilateurs Pascal engendraient un code abominable. Vous ne pouviez plus comprendre pourquoi la machine se plantait, sauf si par miracle vous trouviez un bug dans votre programme en Pascal. Vous ne pouviez plus simplement taper RUN pour savoir si votre programme tournait. Non, vous deviez d'abord apprendre à utiliser un éditeur stupide, frapper votre code, puis le faire passer dans un compilateur, et enfin attendre qu'un « interpréteur de P-Code » vif comme une limace daigne exécutervos idées.

   Peu de temps après, le Pascal devint une religion. Les programmeurs furent privé de tout contrôle direct sur leurs processeurs, leurs programmes durent ralentir, et rares étaient les programmeurs qui savaient ce qui se passait au niveau des bits élémentaires. Le Pascal est en cela similaire à la politique stupide de la limitation de vitesse sur autoroute. « C'est pour votre bien » ; « c'est pour votre propre sécurité » !

   J'ai entendu ce mensonge bien souvent au collège, je m'en suis echappé juste avant que le Pascal ne devienne obligatoire. A ce moment-là, la section informatique avait sa clique d'activistes du Pascal. Ce langage était imposé aux programmeurs avec des méthodes à faire pâlir un gourou de secte. Si vous ne codiez pas en Pascal, vous n'étiez qu'un pauvre macho, vous n'apparteniez pas à la Nouvelle Vague, vous en étiez resté à la préhistoire. Tenez, j'ai même entendu un apprenti-programmeur me dire que « programmer en Pascal, c'est comme s'imposer de porter une camisolede force ».

   Pour bien vous rendre compte de la valeur de cet argument, imaginez-vous en père de famille. Votre fille attend un jeune homme avec lequel elle passera la soirée. ll frappe à la porte. Vous l'accueillez. Vous lui demandez ce qu'il fait dans la vie. ll répond: « je m'impose de porter une camisole de force ». Vous le chassez en pensant « quel abruti ! », pas vrai ?

    Deuxième loi de Small :

    En vérité, on peut écrire du bon ou du mauvais code dans n'importe quel langage. On peut appliquer des règles de structure dans n'importe quel langage.

    Troisième loi de Small :

    Tout programmeur assez stupide pour s'imposer une camisole de force la mérite amplement.

   Le Pascal ne réussit à s'imposer que grâce au conformisme le plus servile. Mais peu à peu, la vérité quant à ce langage commença à filtrer, en de discrets courants souterrains. Attention, si vous leviez la tête en disant « Eh bien moi, j'aime le Basic », les molosses du Pascal vous submergeaient en hurlant. Mais une saine réaction alimentait des murmures : « Pascal est si inefficace que mes programmes mettent un siècle à s'exécuter » ; « ll y a des choses qu'on ne peut même pas imaginer en Pascal, comme mélanger les types, alors que j'en aurait sacrément besoin ! » ; « Eh, vous avez vu ? Mon petit programme en Pascal donne après compilation un exécutable de 100 Ko de long ! ».

   La triste vérité, c'était que le Pascal était un langage mal conçu. Toutes les professions de foi, tous les bêlements affirmant que le Pascal est bon pour vous, butaient contre le mur des réalités : un programmeur codant en assembleur pouvait écrire un logiciel qui ridiculisait en vitesse le même logiciel écrit en Pascal, tout en étant beaucoup plus court. Pire : un programmeur pouvait se permettre en assembleur des choses à jamais impossibles en Pascal.

   C'est pourquoi les courants souterrains démarrèrent chez les gens assez malins pour voir que le Pascal, c'était du bluff. Pour les gens qui n'avaient pas peur de faire valser leur machine à pleine vitesse, l'assembleur s'imposa. Regardez plutôt :

    Lotus 1 -2-3 est écrit en assembleur [NdT : du moins les premières versions] ;
    Wordstar est écrit en assembleur ;
    dBase est écrit en assembleur ;
    XyWrite est écrit en assembleur ;
    Pratiquement tous les jeux d'arcade sont écrits en assembleur.

   Me fais-je bien comprendre ? Les programmes qui ont fait la fortune de leurs auteurs sont écrits en assembleur. Ce sont des programmes remarquables par leur vitesse, qui faisaient de votre ordinateur une voiture de compétition, qui lui faisaient chausser des bottes de sept lieues. Ces programmes se sont bien vendus parce que leurs utilisateurs aiment leur apparence, leur « look-and-feel ».

   Les posters de Samantha Fox ne se vendent pas parce qu'elle est « structurée ». Ou « élégante ». Encore moins parce qu'elle « s'impose une camisole ». Mais parce qu'elle est sexy !

Alors vinrent les années 80

   Venons-en aux années 80. Les gens commencèrent à abandonner le Pascal en masse : ses limitations étaient vraiment insupportables. Emergea alors le C, un Pascal qui était en fait efficace et rapide et vous laissait faire ce que vous vouliez. C'est pourquoi sa popularité croît sans cesse actuellement.

   Sur ce, Apple débarque. Apple aime le Pascal. Et même, Apple adore le Pascal. Et crée un ordinateur nommé Lisa.

   Quand une personne allumait un Lisa, dont le système d'exploitation était écrit en Pascal, elle avait toujours la même réaction : pourquoi est-ce si long ? Pourquoi cette machine est-elle si lente ? Et surtout, comment ont-ils fait pour ralentir autant un 68000 ?

   L'échec du Lisa fut le signe qu'il était temps de faire le Macintosh. Les routines d'affichage graphique étaient écrites en Pascal, puis optimisées en assembleur là où il y avait des goulots d'étranglement. Elles occupaient finalement 60% de la ROMs du Mac. Quant au système d'exploitation, il fut en grande partie réécrit en assembleur, pour l'accélérer.

   Mais hélas ! la machine gardait un affreux parfum de Pascal. ll fallait la supplier d'attribuer de la mémoire pour y charger un programme. ll falait lui plaider votre cause pour qu'elle ne sorte pas le programme de la mémoire une fois que vous l'aviez chargé. Votre programme était déplacé dans la mémoire sous vos pieds à intervalles plus ou moins aléatoires.Et le tout était justifié dans la documentation du Mac, sur un ton vertueux et compassé, comme étant « bon pour vous ».

   Vous ne pouviez pas faire les choses simplement, comme PRlNT "BONJOUR". Non, il vous fallait d'abord initialiser le gestionnaire de mémoire, le tas, et QuickDraw, puisouvrir un GrafPort, choisir une police, choisir sa taille, ses caractéristiques (gras, italique, etc.), lancer une boucle de traitement d'événements, lire un fichier ressource contenant le texte « BONJOUR », et peut-être alors pouviez-vous espérer afficher « BONJOUR ». ll fallait neuf pages de Pascal pour faire un affichage simple.

   Peut-être avez-vous entendu dire que le Mac est la machine la plus difficile à programmer. A mon humble avis, c'està cause de son héritage pascalien. Le Pascal a obligé les programmeurs à faire les choses d'une seule manière, selon le vieux rêve des gardes-chiourme qui veulent à tout prix standardiser les programmes. Rappelez-vous Nikita Khrouchtchev martelant la tribune de l'ONU de sa chaussure, du genre « moi veux tout le monde il fairrle comme moi décide ! », et vous aurez un bon aperçu de la façon dont les comités de normalisation aiment à contrôler les programmeurs.

   La plupart du temps, cette contrôlite aiguë finit par rendre les programmes lourds et lents. Et c'est ce que le Mac force les programmeurs à faire. C'est pourquoi on lit si souvent dans la presse que tel logiciel pour le Mac est « retardé de 3 mois ». Ou « encore instable ». Ou que « ce produit a été abandonné ».

Dave descend en flammes les ROM du Mac

   Prenez donc les ROM, ces monstres froids, avec cet héritage dictatorial, et insérez-les dans un ST, comme je l'ai fait en 1985 (c'était facile à cette époque, il suffisait de les enfoncer dans les supports prévus pour les ROMs duTOS, vu que le TOS était encore sur disquette). Penseriez-vous que les ROMs aiment cela ? Certainement pas. Elles se mettent à agir exactement comme un agent du KGB qui a été kidnappé et forcé à vivre aux Etats-Unis. Les ROMs jettent un oeil sur le bus du ST. ll y a là un bon disque dur bien rapide. ll y a aussi un bon affichage vidéo monochrome, conçu proprement, pas un de ces bricolages qui vous ralentissent un processeur. Et même un lecteur de disquette tout à fait correct. Croyez-vous que les ROMs en soient satisfaites ? Pas du tout ! lmaginez un agent du KGB contemplant un supermarché d'un air dégoûté, et vous aurez une approximation. L'agent est horrifié par le manque de normes, l'absence de contrôle... Tenez, le port de l'uniforme n'est même pas obligatoire ici !

   Du coup, les ROMs déclarent la djihad. Leur but, dans la vie, devient le Plantage. En bref,elle se montrent si inaptes à s'adapter à la vie dans leST qu'elles passent un pacte de suicide mutuel. Elles veillent tard dans la nuit, complotant dans l'ordinateur des machinations ignobles pour mieux planter. Glissons une oreille :
- Camarade Lobachevsky ! Au rapport !
- Da, camarade officier !... Les lecteurs de disquettes semblent inattaquables. Par contre, la routine de formatage des disquettes n'est pas très robuste, si bien que nous pourrions planter là. ll y a aussi de bonnes possibilités du côté des circuits de l'interface série.

   Le lendemain, quelqu'un essaya de formater une disquette en mode Mac sur ce ST. Vlan ! L'écran du « Mac planté » apparut. Les ROMs poussèrent un soupir de soulagement béat. Plus tard, quelqu'un tenta de faire tourner un programme de communication qui s'adressait directement aux circuits de l'interface série. Plantage.

   J'ai bien essayé de menacer ces ROMs. Je les ai reliées à une prise électrique commandée par un interrupteur, et, le doigt sur le bouton, j'ai dit : « Obéissez, ou sinon... ». Dans un ricanement méprisant, elles m'ont répondu : « Vas-y, appuie, sale impérialiste ! On va te montrer comment savent mourir des ROMs écrites en Pascal !... ».

   Comme ça ne marchait visiblement pas, j'ai commencé à dresser des barrières autour des ROMs via le logiciel, en limitant les dégâts qu'elles pouvaient causer par leurs sabotages.
- Camarade Lobachevsky ! Au rapport ! Vous nous aviez assuré que vous alliez planter cette machine aujourd'hui !
- Je... je ne comprend pas, camarades. Aujourd'hui, le port série nous a été retiré. J'ai essayé toutes les fonctions, et elles marchent toutes !...

   Le camarade Borodine, un homme à l'air mauvais, prend la parole : « J'ai une solution. Beaucoup de programmes Mac écrivent accidentellement à l'adresse zéro. Sur cette machine, cela provoque un plantage. Ainsi, le système ne sera jamais stable».

   La réunion se termine alors dans de grands éclats de rires. Le lendemain, je fis tourner Excel de Microsoft. Plantage. A cause d'une écriture à l'adresse zéro.

   Là, j'eus bien peur d'être vraiment coincé. Le manuel du 68000 de Motorola est clair : une écriture à l'adresse zéro provoque une erreur de bus, et on ne peut pas rattraper une erreur de bus. En fait, pour pouvoir le faire, il faut un 68010 ou mieux. (Ecoutez le tuyau, les étudiants en informatique ! Le rattrapage des erreurs de bus, c'est la manière d'implémenter la mémoire virtuelle et la pagination sur disque).

   Je refermai soigneusement le manuel Motorola, et j'essayai quand même une bidouille pour tenter de rattraper les erreurs de bus. Et vous savez quoi ? Le manuel avait tort ! Je continuai et écrivis du code pour que la machine ignore les erreurs de bus. Ce ne fut pas chose aisée, mais ça marchait.

   A présent,les ROMs se réunissent, pétrifiées d'horreur :
- Camarade Borodine ! Nous avons fait aujourd'hui cinquante écritures à l'adresse zéro, et il n'y a eu aucun plantage ! Gardes !... Emmenez Borodine au peloton d'exécution !...
(Bruit de rafales d'AK-47.)

   Cela a duré quelque temps. Au fur et à mesure que les ROMs découvraient de nouvelles façons de planter, j'installais de nouvelles barrières, de manière à l'interdire. Et tandis que les programmes Mac essayaient un tour de cochon après l'autre, créant des problèmes qui réussirent à planter même de vrais Mac, je trottinais derrière avec mon ramasse-crottes pour nettoyer les débris.

   Le Spectre 1 28 contient ainsi des zones démilitarisées, des barbelés, des champs de mines, des pièges, des alarmes... entre autres. Les ROMs sont quasiment enfermées dans un goulag. Bien sûr, elles élaborent toujours des plans démoniaques. Elles ont trouvé un moyen de saboter l'option « prévisualisation de page » dans Microsoft Word3.02. Mais tôt ou tard, je découvrirai ce moyen, et je lui enfoncerai un pieu de bois dans le c*ur.

   Cela a été une lutte continuelle, une guerre intense. J'ai perdu bon nombre de batailles, et il y a toujours des choses qui refusent de marcher, mais finalement, j'ai gagné la guerre.

Conclusion

   Voilà, c'est ce dont je voulais vous parler. Une critique du Pascal à faire faire des apoplexies aux amoureux de ce langage. La vérité sur ce qui se passe la nuit dans les réunions secrètes des ROMs du Mac. Et un aperçu sur l'étrange psychologie tordue d'un programmeur en assembleur.

   J'apprécie toujours les remarques et commentaires. Si vous voulez bien me faire part des vôtres, exécutez le programme suivant pour obtenir mes adresses télématiques :

 IF {LANGAGE(Favori) ==PASCAL} &AND& {EMOTION ==INDIGNATION} DO
    Adresse CompuServe = 00000,000;
    Adresse GEnie = Nil;
    Adresse Internet = ping.pong
 ELSE
    AdresseCompuServe =76606,666;
    Adresse GEnie = DAVESMALL;
    Adresse Internet = dsmall@well.sf.ca.us
 ENDIF

Traduction et adaptation: Password
Titre original : "War inside the computeur"