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 :

Apprendre à programmer : où est le problème ?
Article mis en ligne le 25 octobre 2004
dernière modification le 5 août 2017

par Laurent Bloch
logo imprimer

Beaucoup de gens croient qu’apprendre à programmer est chose facile : je pense que c’est une erreur. Un texte de Peter Norvig fait un petit tour d’horizon des livres aux titres du genre Apprenez à programmer en 10 jours, et explique en quoi cette illusion expose à la déception. Vous trouverez ci-dessous un exposé de mes propres idées sur la difficulté d’apprendre à programmer (accessible ici au format HTML simple). Et là Michel Volle explique pourquoi c’est intéressant.
Ne soyez donc pas surpris d’éprouver vous-même des difficultés, c’est normal !

 Enseigner « l’informatique seconde langue »

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.

À 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 site 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.

 Sempiternelle querelle des langages

Gustave Flaubert 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. Un collègue me disait un jour : « Ce qu’il y avait de bien avec Cobol, c’était que cela s’apprenait en trois jours ». C’est bien là le problème de tous les langages « faciles » : on écrit du Cobol sans savoir programmer, les résultats sont des kilomètres de programme illisible, impossible à maintenir, au bout du compte faux. 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 donc é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.

Cet article 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.

 Expérimenter sans vergogne

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.


Forum
Répondre à cet article


pucePlan du site puceContact puceMentions légales puceEspace rédacteurs puce

RSS

2004-2017 © Site WWW de Laurent Bloch - Tous droits réservés
Site réalisé sous SPIP
avec le squelette ESCAL-V3
Version : 3.87.15