Site WWW de Laurent Bloch
Slogan du site

ISSN 2271-3905
Cliquez ici si vous voulez visiter mon autre site, orienté vers des sujets moins techniques.

Pour recevoir (au plus une fois par semaine) les nouveautés de ce site, indiquez ici votre adresse électronique :

Encore la question des langages de programmation :
Scheme ou Python ?
Pour des biologistes...
Article mis en ligne le 1er novembre 2019
dernière modification le 4 septembre 2021

par Laurent Bloch

Cet article est suivi d’un article d’application qui donne des exemples pratiques d’utilisation de Biopython.

*Un enseignement d’informatique pour biologistes

Depuis une quinzaine d’années, avec deux collègues, j’enseigne la programmation informatique au Cnam dans un cursus de bioinformatique, destiné (en principe) à des biologistes désireux d’élargir leurs compétences, et par là leurs perspectives d’emploi. Ce cursus peut déboucher sur un certificat de compétence, puis une licence professionnelle et un diplôme d’ingénieur. Auparavant j’avais, avec William Saurin et Frédéric Chauveau, créé un cours d’informatique en biologie à l’Institut Pasteur, donné chaque année de 1994 à 2008 (les sept dernières années sous la direction de Catherine Letondal et de Katja Schuerer). Dans ces deux circonstances, nous avions choisi, comme langage d’initiation, un dialecte moderne et simple de Lisp, Scheme, pour des raisons exposées ici et , étant entendu qu’un tel cursus doit comporter au moins deux langages de programmation (dans les deux cas le second langage étant Java).

**Querelle des langages

Bien sûr, ces enseignements donnent lieu à l’éternelle querelle des langages, et chacun y va de sa suggestion en faveur du langage à la mode du moment ; j’ai vu ainsi défiler Fortran (si !), C, Perl, Java... Depuis quelque temps Python revient de manière insistante. Nous avons quelques bonnes raisons de nous en tenir à Scheme, et cette année encore nous avons été entendus, mais afin d’assurer nos arrières, et aussi par curiosité, j’ai décidé d’explorer ce que pourrait devenir notre cours avec Python, et pour cela d’écrire un manuel de programmation à l’usage des biologistes, basé sur Python. Entendons-nous, il s’agit d’enseigner la programmation, avec ses concepts et ses notions, pas de dispenser quelques recettes de Python qui donnent des résultats sans la compréhension de la façon dont ils sont calculés : tout le malentendu est là.

**Choisir un manuel existant ?

J’aurais aussi pu choisir un manuel existant, j’en ai d’ailleurs trouvé un excellent, celui de Benjamin Wack, Sylvain Conchon, Judicaël Courant, Marc de Falco, Gilles Dowek, Jean-Christophe Fillâtre et Stéphane Gonnord chez Eyrolles, destiné aux classes préparatoires, mais les exemples proposés au lecteur relèvent de mathématiques trop ardues pour un public de biologistes, du pivot de Gauss à la résolution numérique d’équations différentielles. Le manuel conçu sous la direction de Gilles Dowek pour l’option Informatique et sciences du numérique (ISN) des lycées ne manquait pas lui non plus de qualités, mais le programme ministériel de cet enseignement comportait un choix que je désapprouve, et que je commenterai ci-dessous. Bref, il me fallait écrire.

*Arguments pour Python

**Le pouvoir d’influence des hommes système

Python est un langage très populaire depuis plusieurs années, et il y a à cela quelques raisons. Sous l’impulsion initiale donnée par Guido van Rossum, c’est un langage de script, conçu par et pour des administrateurs système et réseau, et parfaitement adapté aux besoins de cette corporation. Or ceux qui conçoivent et administrent les systèmes d’exploitation disposent d’un pouvoir d’influence considérable dans la sphère informatique, parce que c’est vers eux que l’on se tourne, en dernier recours, quand on ne sait plus ce qu’il faudrait faire pour que « ça marche ». C’est ainsi que les auteurs de diverses versions d’Unix ont assuré le succès du langage C, y compris dans des domaines auxquels il n’était pas particulièrement bien adapté, comme la bioinformatique. Et, a contrario, si Java n’a pas réussi à supplanter C, malgré des qualités indéniables, c’est parce que les administrateurs système le détestent, pour de mauvaises raisons d’ailleurs.

**Langages de script

Si le langage C était destiné à écrire le système d’exploitation, les langages de script, tels que Perl, Ruby ou Python, ont trouvé leur terrain d’utilisation privilégié dans la gestion et l’administration du système d’exploitation (même s’ils avaient été conçus au départ pour de tout autres usages). Le fonctionnement quotidien d’un système, surtout s’il s’agit d’un serveur destiné à rendre un service fiable à des milliers d’utilisateurs, repose sur le lancement à intervalles réguliers de multiples programmes de gestion. L’automatisation de ces tâches répétitives est impératif : le précurseur en fut Louis Pouzin, créateur en 1963 du premier shell, suivi de Stephen Bourne et d’autres auteurs de shells Unix, qui réunissaient sous une seule interface deux fonctions, la commande du fonctionnement de l’ordinateur et du système, et un langage de programmation minimum. Avec l’augmentation de la puissance des ordinateurs et de la taille de leur mémoire, il fut possible de créer les langages de script plus puissants que nous connaissons.

Un langage de script n’est pas destiné à effectuer des calculs lourds, puisqu’il sert surtout à lancer et à ordonnancer des programmes écrits dans d’autres langages. De ce fait il n’a pas besoin d’être très efficace en termes de performances, ni même d’être compilé (un programme compilé, c’est-à-dire traduit en langage machine, est plus rapide de deux ordres de grandeur qu’un programme interprété, dont les lignes de code sont exécutées une à une ; les langages de script sont interprétés). Python, Perl, Ruby ne sont pas des langages efficaces, mais ils sont commodes et bien adaptés au travail des administrateurs système, qui en ont vanté les mérites aux utilisateurs sur lesquels ils exerçaient un certain pouvoir. Leur influence a même atteint le ministère français de l’Éducation nationale, qui impose Python pour les enseignements d’informatique au lycée, idée qui ne me semble pas particulièrement géniale.

*Apprendre à programmer

Functional programming is a radical and elegant attack on the whole enterprise of writing programs. It’s very different from the ’do this and then do that’ programming mentality. You have to rewire your brain in quite a different way.” – Simon Peyton-Jones

La réussite d’un enseignement de la programmation ne se mesure pas à la capacité de l’étudiant à taper vite des lignes de programmes cryptiques, mais à son aptitude à raisonner sur des programmes. Construire des programmes sur lesquels on puisse raisonner, raisonnables même, suppose qu’ils soient intelligibles, et pour cela il faut suivre Descartes, le Discours de la Méthode : « diviser chacune des difficultés que j’examinerois, en autant de parcelles qu’il se pourroit, et qu’il seroit requis pour les mieux résoudre ». En d’autres termes, diviser son programme en sous-programmes. C’est ce à quoi nous invitent les langages dits fonctionnels, comme Scheme ; et s’il est possible de procéder de même avec Python, disons que ce n’est pas la pente naturelle du langage, qui va plutôt vers « faire ci, et puis ensuite faire ça », ce qui mène inévitablement à de mauvais programmes.

Lorsque j’ai eu entre les mains le manuel destiné à l’option Informatique et sciences du numérique (ISN) des lycées mentionné plus haut, j’ai traduit les programmes du livre en Scheme, le plus possible de façon juxtalinéaire. Or le programme officiel intime de n’introduire la notion de sous-programme qu’assez tard dans la progression, ce qui oblige à écrire des programmes monolithiques assez laids, vite critiqués par mes lecteurs. J’ai tenté de corriger selon les principes énoncés ici, voici le résultat.

*Biopython

L’argument principal en faveur de la conversion à Python de nos enseignements était l’existence de la bibliothèque Biopython. Cette bibliothèque de programmes n’est pas écrite en Python, elle est constituée de programmes en C, dont l’usage est grandement facilité par un système de classes (au sens de la programmation par objets) Python qui permettent de manipuler les données pour les soumettre aux calculs désirés. La plupart des programmes classiques de la bioinformatique, tels que BLAST, Phylip, etc., sont ainsi très faciles à utiliser. Biopython permet au biologiste d’effectuer à peu près toutes les opérations informatiques dont il peut avoir besoin.

La chose dont il convient d’avoir conscience, c’est que Biopython donne un moyen d’accomplir ces opérations sans acquérir les connaissances correspondantes, c’est-à-dire sans savoir « comment ça marche », comment se programment les algorithmes mis en œuvre ; ce défaut de connaissances peut être toléré pour un emploi de technicien qui travaille en routine, mais quiconque aspire aux fonctions d’ingénieur ou de chercheur, ou en un mot de bioinformaticien, ne saurait se dispenser de ces apprentissages, ne serait-ce que pour utiliser Biopython en connaissance de cause.

Un autre point qui mérite attention : nous avons suggéré ci-dessus qu’il était souhaitable, pour la qualité du logiciel, d’écrire des sous-programmes et de structurer ses programmes par appels de sous-programmes. Biopython, comme nous venons de le voir, par sa facilité d’usage, incline au style de programmation plus relâché des langages de script. Nous ne saurions trop encourager à la vigilance contre cette facilité à laquelle chacun, un jour ou l’autre, sera tenté de succomber.