Remonter Remonter Suivant

Préface de Jacques Arsac

pour le livre Initiation à la programmation avec Scheme de Laurent Bloch

Encore un livre sur la programmation, en l'an 2000 ! Tout le monde sait que l'informatique est une nouvelle technologie, que son apprentissage est d'autant plus facile que les industriels ont fait de gros efforts pour la rendre conviviale. Comme cela a été répété maintes fois depuis les années soixante-dix, un enfant l'apprend en quelques jours et l'explique à ses grands-parents ! Nous avons maintenant des logiciels spécialisés pour toutes sortes d'applications, nul ne programme plus.

Dans le même temps, nous avons connu, à la fin de l'année 1999 une grande peur du bogue de l'an 2000. Connaissant bien les pièges de la programmation, et la compétence limitée de trop de programmeurs professionnels, j'avoue que je n'aurais pas pris l'avion le 31 décembre à 23 heures ! Et de fait, l'ordinateur que j'utilise quotidiennement affiche comme date des fichiers créés ce jour : 27/9/19:0. J'ai ma petite idée sur l'erreur qui a donné comme successeur à 1999 le nombre 19:0, le caractère « : » est le successeur du caractère « 9 » dans la table de caractères reconnus par l'ordinateur. Mais comment un programmeur a pu commettre une erreur pareille, c'est ce que je ne peux comprendre. Je me suis occupé de l'enseignement optionnel de l'informatique en classe de seconde dans les lycées : nous n'aurions pas toléré cette faute d'un de nos élèves, elle est indigne même d'un débutant !

On est donc dans une situation paradoxale : comme on ne veut plus programmer, il faut s'en remettre à des professionnels, et l'expérience montre qu'ils peuvent commettre des erreurs monstrueuses et inexcusables. Dès lors, quelle confiance leur faire ? Pour bon nombre d'applications, cela n'a pas une importance colossale. La date assignée à mes fichiers par le système d'exploitation que j'utilise est fausse, mais le système ne s'en sert pas, l'erreur est sans conséquence. Que se serait-il passé si le système était muni d'un dispositif mesurant l'âge des fichiers et éliminant les plus vieux ? Mais pour faire cela, il aurait fallu que le programmeur soit capable de soustraire les entiers représentant deux millésimes, alors qu'il n'est même pas capable d'ajouter 1.

Un scientifique attache la plus grande importance au contrôle du dispositif qu'il a conçu pour réaliser quelque expérience, c'est à ce prix qu'il pourra faire confiance aux résultats et les communiquer à la communauté scientifique internationale. Quelle confiance peut-il faire aux calculs réalisés par ordinateurs sur les résultats qu'il a lui-même mesurés ? Il m'a été dit parfois qu'on avait utilisé le logiciel de traitement des mesures dans des cas où le résultat est connu d'avance, et qu'alors on avait constaté le bon fonctionnement de ce logiciel. Mais c'est oublier un point essentiel en épistémologie, énoncé par Blaise Pascal et repris par Karl Popper : des essais en nombre quelconque ne peuvent en aucun cas valider une théorie. 60 est divisible par 2, par 3, par 4, par 5, par 6. Si cela ne vous suffit pas, il est encore divisible par 10, 15, 20... 60 est divisible par tous les entiers ! Ce n'est pas parce quelques essais ont été satisfaisants que l'on peut déclarer un programme juste : il est valide parce qu'on a montré sa validité en le construisant. C'est une exigence de rigueur normale en science.

Je ne prétends pas qu'un scientifique doive faire table rase de tout ce qui a été fait avant lui, et recommencer indéfiniment à réécrire un programme bien connu. Comme Laurent Bloch, je pense seulement que s'il a un peu pratiqué la programmation, l'informatique perd sa qualité de boîte noire magique à laquelle on fait une confiance infinie. Il a appris à se méfier, il garde un esprit critique et est attentif au moindre signe d'anomalie. Il sait comment mettre dans ses données quelques éléments redondants dont il connaît l'effet qu'ils produiront : cela peut servir de signal d'alarme... Quand nous avons créé l'option informatique des lycées nous n'avions pas d'autre but. Il était bien clair qu'elle n'avait pas pour but la formation de futurs professionnels, il s'agissait seulement de doter le futur citoyen d'un minimum d'esprit critique.

Laurent Bloch évoque avec justesse la question des langages de programmation. Selon George Steiner, un extraterrestre visitant la terre et voyant la diversité des races humaines se dirait qu'on doit y pratiquer une dizaine de langues différentes, avec quelques variantes dialectales : il y en a plus de deux mille. L'auteur de la Genèse en chercha l'origine dans le mythe de Babel. Subterfuge inutile. La création des langages de programmation commença vers 1950. En 1970, on en comptait plus de 2000. Et pourtant, ils n'ont qu'un objectif restreint : permettre d'exprimer des algorithmes d'une façon exploitable par un ordinateur. On est loin de l'extrême variété de pensées que les langages naturels doivent être capables de communiquer. Laurent Bloch évoque l'aspect passionnel qui entoure le choix d'un langage. Faut-il s'en étonner ? Dans le temps où l'on vante les mérites d'Internet comme moyen de communication planétaire, on voit se durcir les positions sur le patois local, parlé par une petite communauté de gens, et dont l'effet est de construire des barrières linguistiques. Mais il est vrai qu'un langage est un patrimoine culturel par la masse des textes qui l'utilisent, et qui représentent le génie d'une communauté. Puis-je me résoudre à voir disparaître le français, langue de Molière ou de Boileau ? Si Babel n'avait pas existé, nous l'inventerions aujourd'hui...

Dès lors quel langage choisir ? J'ai rencontré cette difficulté dans la création de l'option informatique des lycées. Certains disaient : il faut enseigner Fortran ou Cobol, c'est ce qu'on utilise dans l'industrie. Mais je répondais qu'entre le temps où l'élève apprend au lycée, et celui où il sera en train de programmer dans une entreprise, d'autres langages seront apparus, et l'on aura fait un investissement inutile. Nous avons refusé de choisir, affirmant que maîtriser la programmation n'est pas connaître un langage, mais être capable de concevoir une méthode de traitement. Son expression dans un langage de programmation est un problème mineur devant celui de sa conception. Rappelez-vous « l'art poétique » de Nicolas Boileau.

Ce que l'on conçoit bien s'énonce clairement
Et les mots pour le dire arrivent aisément


Un cours de programmation n'est pas là pour vous enseigner des mots, mais pour vous permettre d'exprimer vos idées avec des mots. Le résultat vaudra ce que valent vos idées :

Il est certains esprits dont les sombres pensées
Sont d'un nuage épais toujours embarrassé
Le jour de la raison ne les saurait percer...


L'expérience m'a montré qu'en programmation comme en beaucoup de domaines, la clarté et la simplicité sont rarement l'effet d'un premier jet. On écrit d'abord des choses complexes, puis on les nettoie, on les simplifie.

Hâtez-vous lentement et sans perdre courage
Vingt fois sur le métier remettez votre ouvrage,
Polissez le sans cesse et le repolissez.


Encore faut-il avoir quelque chose à dire. On utilise un ordinateur pour lui faire exécuter des tâches répétitives fastidieuses, ou pour lui faire faire de longs calculs. C'est lui qui fait, pas le programmeur. Ce n'est pas parce que vous savez faire que vous êtes capables de faire faire par un autre. Si je vous donne un paquet de fiches pas trop gros en vous demandant de les classer, par exemple par ordre alphabétique, vous ferez sans difficulté ce petit travail. Pourriez-vous me dire quelle méthode systématique vous avez utilisée ? Vraisemblablement aucune. Vous aurez constaté que telle fiche va avant telle autre, telle va en début de paquet, telle autre en fin. Si deux fiches ne sont pas dans le bon ordre, vous les avez échangées. Il y a loin de faire à faire faire. C'est le problème de tout professeur. Un professeur de mathématiques sait résoudre les exercices de fin de chapitre de son manuel, mais ce n'est pas ce qu'on lui demande : il doit les faire résoudre par ses élèves, et c'est autrement difficile !

Ce cours de programmation vous aidera à trouver comment découvrir une méthode de résolution ou une procédure d'action communicable à un ordinateur. La programmation fonctionnelle choisie par Laurent Bloch permet au programmeur d'en dire le minimum, laissant à l'ordinateur le soin de développer ce qui a été laissé implicite par le programmeur. Il en résulte parfois une perte d'efficacité dans l'exécution. C'est un choix qui est parfaitement justifié dans l'enseignement de la programmation à des chercheurs scientifiques dans le but de leur permettre de comprendre ce qu'est l'informatique, pas de battre des records d'efficacité. Si un jour vous vous trouvez devant un problème tellement complexe que l'efficacité devient primordiale, il sera temps d'aller discuter avec un expert en programmation. Vous apprendrez à écrire des programmes clairs, lisibles, élégants. Un programme est d'abord fait pour être lu par un homme : pourvu qu'il soit syntaxiquement correct, une machine en tirera toujours quelque chose. Nous le disions aux élèves de lycée : la pratique de la programmation aide l'étudiant à développer sa créativité (inventer de nouveaux algorithmes), la rigueur (on doit pouvoir montrer qu'ils sont justes avant même de les essayer sur un ordinateur), la clarté d'expression (ils doivent être lisibles par un autre programmeur).

En 1980, lors du colloque mondial d'informatique à Melbourne, on me demanda de remplacer dans une table ronde un orateur russe qui n'avait pu faire le déplacement. On devait discuter de la synthèse automatique de programme : vous dites à l'ordinateur qu'il doit construire un programme pour calculer le plus grand commun diviseur de deux nombres, et il invente l'algorithme d'Euclide ! Un des participants déclara qu'il espérait bien que le projet n'aboutirait jamais, sinon avec quoi pourrait-il s'amuser. Pour moi comme pour lui, la programmation est un jeu, une sorte de défi intellectuel. J'aime ces « petits problèmes », à l'énoncé très simple, mais pour lesquels il est parfois si difficile de trouver une façon simple de les faire résoudre par une machine. En voici un exemple (n'y perdez pas trop de temps, si ce jeu vous amuse) : je donne trois nombre entiers a, b, et c, inférieurs au plus grand entier que l'ordinateur peut représenter exactement, mais voisins de lui. Calculer le reste de la division du produit a b par c. Le résultat est inférieur à c, donc représentable exactement, mais le produit a b est trop grand... Je souhaite à tous les lecteurs de ce livre de trouver dans la programmation autant de plaisir que moi.

Jacques Arsac
© copyright Éditions Technip 2000
Remonter