Préface de Jacques Arsac
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