Avant-propos
Le présent ouvrage est né d'un cours dispensé à l'Institut
Pasteur pour un public de jeunes chercheurs ou
futurs chercheurs en biologie désireux de connaître
l'informatique. Étant entendu que savoir utiliser un logiciel n'est
en rien connaître l'informatique, il faut enseigner la programmation,
qui est le coeur de la discipline.
Apprendre à programmer n'est pas acquérir un peu de dextérité avec tel
ou tel langage, c'est avoir une vision d'ensemble de tout ce qui peut
se programmer en quelque langage que ce soit.
Aujourd'hui chacun programme son magnétoscope ou sa machine à laver :
posséder une vision d'ensemble de la programmation des ordinateurs,
c'est autre chose, c'est maîtriser un langage suffisamment puissant
pour décrire n'importe quel algorithme et suffisamment précis pour
accéder à chaque élément de l'architecture de von Neumann. Ces
exigences disqualifient pour acquérir la compréhension de la
programmation le langage du magnétoscope, incroyablement compliqué
mais peu puissant, et les langages de trop haut niveau, comme
Mathematica
ou Perl qui sont à la programmation ce
que les plats surgelés sont à la cuisine, pratiques et
éventuellement utiles, mais heureusement qu'il y a
autre chose1.
Ces principes posés il faut considérer que ce livre s'adresse
(c'est peut-être son originalité) à des lecteurs qui abordent
l'informatique en « seconde discipline ». À des étudiants
qui abordent l'informatique comme leur vocation première il convient
d'en faire acquérir la vision la plus étendue (et la plus profonde)
possible, avec à l'esprit un objectif, hors d'atteinte,
d'exhaustivité. Les destinataires du cours dont ce livre est un
élément ont déjà consacré de longues années à acquérir des
connaissances approfondies dans un autre domaine (ici la biologie,
mais si c'était l'épigraphie latine le présent ouvrage ne serait
modifié que pour le choix de quelques exemples). Ils sont
souvent engagés dans la rédaction d'une thèse ou un travail de
recherche. Ils n'ont ni le loisir ni le but de faire table rase de
leur première discipline, ils souhaitent au contraire féconder la
connaissance qu'ils en ont par une hybridation fructueuse avec
l'informatique. Le succès d'une greffe n'est pas proportionnel à la
taille du greffon : il leur faut en apprendre le moins possible.
Comment déterminer ce « moins possible » ? C'est un peu une question
de morale. On peut faire large mais superficiel, ou profond mais sur
un domaine étroit. Nous avons cherché à exposer jusqu'à une profondeur
raisonnable un domaine central et peu susceptible de péremption (la
programmation) sous un angle assez général pour que la transposition
des connaissances acquises vers d'autres modes de réalisation
technique soit possible.
Gustave Flaubert
2
aurait été ravi de connaître l'informatique. On rêve
du chapitre supplémentaire où Bouvard et Pécuchet se débattraient avec
la programmation. Si l'on cherche dans
l'informatique autre chose qu'un moyen de briller au coin de la
machine à café grâce au romantisme un peu facile d'un lexique étrange,
il faut éviter la course à la nouveauté souvent juste
apparente. L'informatique évolue vite mais les idées vraiment
nouvelles y sont, comme partout, rares. Acquérir la maîtrise d'un
langage de programmation prend du temps, et en changer ne rend pas
plus intelligent. Aussi chercherons nous plutôt à introduire, à
l'occasion de tel langage contingent (mais choisi avec soin), des
notions générales et, espérons-le, réutilisables.
Dans la quête du moins possible, il faut aussi éviter la tentation
d'aller vers les langages prétendus « amicaux pour l'utilisateur ». Dans
ce domaine de la démagogie il faut décerner un coup de chapeau à
l'increvable Basic, qui renaît
de ses cendres sous une forme dite
« visuelle » pour venir finalement rivaliser avec Perl dans les coeurs
de tous ceux qui voudraient bien avoir les solutions sans s'être posé
les questions. Mais rien n'y fait, les difficultés intrinsèques de la
programmation sont inévitables et elles rattrapent au coin du bois
ceux qui avaient cru sauter la barrière sans payer
3.
Cet avant-propos s'est laissé entraîner vers la sempiternelle querelle
des langages, aussi régulièrement déclarée stérile que reprise avec
animation. C'est comme pour les goûts et les couleurs, plus on dit
qu'on n'en discute pas plus ils font la matière permanente de nos
conversations, comme le remarquait le philosophe corse Théodore Adorno.
Il y a sans doute de bonnes raisons à cela.
Chaque informaticien aura un jour ou l'autre à
choisir un langage de programmation, et comme il y en a des milliers,
chacun particulièrement bien adapté à tel ou tel usage, la question ne
peut être tranchée une fois pour toutes. Autant se donner une idée des
critères pertinents.
C nous est souvent suggéré pour notre enseignement. De moins en moins
certes, au fur et à mesure que ce langage, s'il reste très présent, se
démode pour les nouveaux développements. Il y a des arguments forts
pour C : c'est un langage universellement répandu, pour lequel
existent beaucoup de bons traducteurs accessibles facilement et
gratuitement. Nous ne l'avons pas envisagé pour plusieurs raisons :
pour comprendre vraiment ce que l'on fait en écrivant un programme C
il faut une bonne connaissance du fonctionnement interne de
l'ordinateur, ce qui nous semble un manque d'abstraction, une
confusion des objets néfaste à l'acquisition des fondements. C ne
permet pas l'enseignement de tournures souhaitables. Par contre la
syntaxe présente toutes les obscurités voulues, de sorte qu'un cours basé sur ce
langage serait consacré pour moitié à tirer au clair le fonctionnement
intime des primitives du système d'exploitation (ce qui serait l'objet
éventuel d'un autre enseignement, plus technique, qui aurait été
précédé d'un apprentissage de la programmation...), pour une autre
moitié à l'exégèse de bizarreries syntaxiques, ce qui serait
franchement sans intérêt. Il est clair qu'un informaticien devra un jour
ou l'autre apprendre ce langage : il ne nous semble pas propice cependant
à l'enseignement initial.
Et C++ ? Il a grosso-modo les inconvénients de
C, plus d'autres décrits par Stanley Lippman
(Inside the C++ Object Model).
Et Java ? Notre cursus comporte une session
consacrée à Java, parce que nous pensons que c'est un objet
d'enseignement raisonnable et qu'il convient de donner aux élèves la
notion de la pluralité des langages. Mais Java, contrairement à une
idée reçue, est loin d'être un langage facile à apprendre, surtout
comme premier langage.
Aussi notre choix s'est-il porté vers
Scheme, un dialecte sobre et moderne de
Lisp, d'abord parce qu'il nous a enthousiasmés, ensuite
parce que son examen ultérieur nous a révélé qu'il permettait
d'introduire pratiquement tous les concepts fondamentaux de la
programmation sans être encombré des lourdeurs syntaxiques qui rendent
si pénible l'apprentissage de certains langages. Les traducteurs de
Scheme sont maintenant universellement répandus, légers et efficaces,
disponibles gratuitement sur l'Internet selon les modalités de plus
en plus répandues du logiciel libre, et ce pour tous les types de
systèmes.
Cette exigence de dépouillement nous a aussi conduits à écarter du
programme de nos enseignements bien des aspects purement techniques de
l'informatique, ainsi que certaines constructions qui ont surtout pour
utilité d'illustrer la virtuosité de celui qui les manie.
Une autre caractéristique de notre enseignement en a dicté certains
traits : ce qui a attiré vers la science un jeune biologiste, souvent,
c'est plus l'aspect expérimental que l'aspect formel, alors que l'on
peut soupçonner chez un jeune mathématicien une complexion
inverse. Beaucoup de cours de programmation s'adressent à des
étudiants de la seconde catégorie, et supposent acquis un goût pour
les méthodes formelles et un bagage mathématique qui risquent d'être
moindres ici. Nous avons banni ce présupposé, ce qui nous a conduit à
éviter les exemples trop mathématiques et à introduire de façon
informelle certaines notions susceptibles d'exposés plus
rigoureux. Nous croyons que la formalisation rigoureuse peut venir
après la familiarisation informelle, surtout en informatique, qui est
une discipline où l'exécution compte beaucoup. Une idée a surgi au
grand jour ces dernières années en informatique (après avoir été
pratiquée honteusement depuis les origines) : programmer un problème
est un bon moyen de le comprendre. Le surmoi mathématique condamnait
cette approche expérimentale (terme insultant pour un mathématicien
classique) : la libération des moeurs des années 70 en a finalement
même si tardivement eu raison. Le cours initial auquel correspond le
présent ouvrage est suivi d'un cours plus théorique qui aborde les
grammaires formelles et le l-calcul : nous croyons que commencer par
là serait au mieux inutile, alors que les découvrir après avoir
commencé à programmer peut apporter la révélation de leur puissance
simplificatrice.
Les programmes donnés dans ce livre n'y sont que pour illustrer des
notions : ils n'ont surtout pas la prétention d'être complets, ils
visent surtout la concision et la simplicité. Le contrôle d'erreur
de données est généralement omis, le lecteur qui envisage de s'inspirer
de ces exemples pour un usage réel sera bien inspiré, à titre
d'exercice, de l'ajouter à son ouvrage.
Ce livre prend place dans un enseignement assuré pendant quatre ans
par Frédéric Chauveau, sans lequel il ne serait pas ce qu'il est (même
si c'est pour s'en écarter). Le lecteur assidu reconnaîtra ce que les
lignes qui suivent doivent aux auteurs classiques du domaine, notamment
H. Abelson, G. et J. Sussman
(Structure and Interpretation of Computer Programs)
grâce auxquels l'auteur de
ces lignes, comme tant d'autres, a découvert Scheme avec émerveillement
(ce livre est désormais accessible sur le WWW :
le SICP),
J. Chazarain (Programmer avec Scheme, de la pratique à la
théorie), Véronique Donzeau-Gouge Viguié
et Thérèse Accart-Hardin (Concepts et outils de programmation),
C. Queinnec(Les Langages Lisp) ,
D. Friedmann, M. Wand et C. Haynes (Essentials of Programming Languages).
Et sans le système de programmation
Bigloo
de Manuel Serrano qu'aurions nous fait ?
C. Queinnec a en outre écrit le logiciel qui
nous a permis d'inclure dans le texte la plupart des exemples
de programmes qui y figurent,
l2t.
William Saurin a été un lecteur, un conseiller et un encourageur
constant. Christian Queinnec et Manuel Serrano ont aussi relu
et conseillé. Il convient toutefois de dire que notre modeste propos ne prétend
pas se comparer à ces modèles et que ses insuffisances et erreurs
ne sauraient leur être imputées. Les enseignants
et les élèves du Cours Pasteur d'Informatique en Biologie ont
fourni ample matière à réflexion. Jean-Marc Ehresmann a prodigué
ses lumières mathématiques. Enfin c'est Fouad Badran qui
m'a donné mon premier interprète Scheme sur une disquette.
Pour profiter de la lecture de ce livre
il convient de disposer d'un interprète
ou d'un compilateur Scheme. Il en existe de nombreux pour toutes les
plates-formes souhaitables (Unix, Macintosh, PC sous Windows ou
sous DOS). Il y a même des prototypes pour le PalmPilot.
Beaucoup sont disponibles gratuitement, notamment ceux cités ici.
Ces logiciels sont raisonnablement bien décrits à l'emplacement
suivant :
Schemer's site.
Le logiciel plus particulièrement utilisé ici est
BiglooBigloo de Manuel Serrano, un système pour
Unix et Windows 2000 qui combine compilateur et interprète :
Bigloo.
Sur un site voisin et ami, un interprète Scheme pour
Unix avec une boîte à outils graphique, écrit par Érick Gallesio :
STklos.
D'autres informations sur Scheme peuvent être
consultées à :
Schemers.org.
Une implémentation pour Macintosh (avec une boîte à outils
graphique) :
Gambit
DrScheme, une réalisation reconnue pour
sa cohérence et ses qualités pédagogiques, oeuvre d'une équipe avec
notamment Shriram Krishnamurthi et sous la direction de
Matthias Felleisen :
DrScheme
LiSP2TeX, désormais baptisé plus laconiquement l2t, est disponible à :
l2t.
Christian Queinnec est aussi l'un des auteurs d'un système d'enseignement à distance
pour Scheme disponible sous forme de
cédéroms télé-chargeables
sur le site de l'Université Pierre et Marie Curie.
Signalons également que sont accessibles par le WWW trois excellents ouvrages en
anglais dont Scheme est le personnage principal, le « SICP »
(Structure and Interpretation of Computer Programs) d'Abelson et Sussman,
The Scheme Programming Language
de R. Kent Dybvig
et How to Design Programs,
par la même équipe que DrScheme.
- 1
- Les plats surgelés peuvent être
considérés avec indulgence,
dans un refuge en montagne par exemple, quand on n'a vraiment
pas le temps de faire autrement. Mais si on n'a jamais
cuisiné soi-même une matelote d'anguilles, l'ouverture
d'innombrables emballages de la maison P... ne nous en
révélera jamais le secret.
- 2
- Gustave Flaubert (1821--1880) a exercé une verve sarcastique
aux dépens des snobs et de la science.
- 3
- Ce qui n'exclut nullement la possibilité d'écrire de
bons programmes en Perl ou en Visual Basic,
simplement il y faudra les mêmes compétences qu'avec
un autre langage, et ils ne sont pas de bons véhicules
d'apprentissage. Un ouvrage récent relève le défi de
construire une initiation à la programmation autour de
Visual Basic, Word et Excel.
C'est courageux et intéressant (voir Michèle Soria
et al., [50]).
© copyright Laurent Bloch et Éditions Technip, 2000