Le code…

Voilà, c’est comme le muguet, ça revient régulièrement : on veut introduire une initiation au codage informatique dans les enseignements fondamentaux (ceux qui sont maîtrisés au brevet, donc acquis en primaire ou au collège).

Bon.

Première chose : ça n’a rien de nouveau.

En 1987, j’ai souvenir d’avoir fait des dessins sur un écran de télé avec un TO7/70. Ça ressemblait à ça :

logo
« Cercle » (en fait un triacontakaihexagone) en Logo — ici l’implémentation de LibreOffice, qui supporte le multilingue.

La tortue Logo, symbole du plan Informatique pour tous, c’était ludique et mine de rien, ça implémentait plein de choses utiles comme bases de la programmation : les nombres, les opérations sur les nombres (y compris des opérations que, à l’époque, je voyais que très succinctement : l’addition en CP, c’était le maximum qu’on nous demandait), les boucles et mêmes les fonctions.

Est-ce que ça a fait de moi un bon programmeur ? Non. Je suis pas un bon programmeur, et c’est pas seulement parce que je n’ai plus touché un programme entre Informatique pour tous et mes premiers pas de Basic à domicile.

Je suis pas un bon programmeur, parce que je pense trop comme l’ordinateur : je réfléchis trop en suite d’instructions et pas assez en fonction d’abstractions utiles. L’exemple caricatural, c’est la difficulté éternelle que j’ai à employer des langages à objets : j’ai tendance à multiplier les fonctions et à gérer des variables innombrables, là où de simples classes d’objets feraient l’affaire beaucoup plus lisiblement, et c’est sans doute parce que je reste très attaché à ce que va faire l’ordinateur avec mes données et son processeur — c’est pas un hasard si, à la fac, un des rares domaines où je brillais était… l’assembleur !

Mine de rien, ça rejoint mon deuxième point : apprendre le code sera-t-il utile ?

Dans un premier temps, il y eut le binaire. Puis il y eut l’assembleur, qui permettait d’écrire des instructions vaguement lisibles qu’un programme allait transformer en langage binaire exécutable. Puis, il y eut des langages de relativement bas niveau, encore proches de la machine, avec des variables simples ressemblant vaguement aux registres, des instructions rappelant encore des emplacements mémoire (en Basic par exemple, on débutait les lignes de code par un numéro et les instructions de branchement étaient de simples goto), mais déjà plus lisibles. Puis les langages de plus haut niveau, avec des variables typées, des opérations plus variées, des fonctions, des objets, qui ouvraient des concepts inconnus de la machine¹. Parmi ceux-ci, certains n’avaient plus rien à voir avec la façon dont opérait l’ordinateur, je pense par exemple au Prolog et au Lisp.

Aujourd’hui, la programmation d’applications simples n’est quasiment plus affaire de code. On dessine des fenêtres et des objets, on ajoute des bouts de codes appelés par des événements sur ces objets.

Bien sûr, je simplifie et je caricature le propos, mais quand on demande dans l’évolution des programmes scolaires que « L’élève [soit] capable de réaliser de petites applications utilisant des algorithmes simples », j’ai juste envie de dire : c’est bon, des petites applications et des algorithmes simples, y’a pas besoin de savoir coder. Il suffit de savoir cliquer, dessiner, et savoir écrire un for ou un while.

Aujourd’hui, une bonne part de l’algorithmique n’a plus rien à voir avec l’ordinateur. Il y a des types qui pensent l’algorithme, parfois avec des outils bien plus proches des mathématiques que du codage — je me suis arrêté au λ-calcul, mais je suppose qu’il y a d’autres trucs du même genre. Puis ces algorithmes sont transformés par le programmeur dans un langage de haut niveau (Lisp, PHP, C♯ ou autre) adapté au problème du moment, puis l’ordinateur compile tout ça pour obtenir le fichier exécutable. Le programmeur peut d’ores et déjà être considéré comme une sorte de pré-compilateur, qui transforme un algorithme abstrait ou purement mathématique en langage formel que l’ordinateur puisse compiler ou interpréter.

La tendance est toujours à développer non seulement des langages plus « humains », mais aussi des briques logicielles plus puissantes, permettant d’appeler des fonctions toujours plus complexes avec des écritures toujours plus intelligibles. Je prends un exemple tout bête juste parce que c’est chez des potes (et que pour une fois j’ai compris à quoi ça sert), mais y’a des mecs qui développent une librairie d’expressions régulières lisibles pour .Net, Magex. Il n’y a pas si longtemps, vérifier si un texte est une adresse internet HTTP ou FTP, pour valider un formulaire par exemple, demandait de taper un truc du genre :

m/(http(s)?|ftp)://(www.)?[a-zA-Z0-9!#$%&'*+/=?^_`{|}~-]+/

qui est, disons-le, d’une lisibilité assez médiocre (d’ailleurs je vais même pas m’emmerder à taper du Perl juste pour voir si ça marche, c’est là à titre d’illustration) ; Magex permet d’écrire :

const string allowedChars = @"!#$%&'*+/=?^_`{|}~-";
magicWand.Alternative(
Magex.New().String("http").Character('s').Repeat.AtMostOnce(),
Magex.New().String("ftp"))
.String("://")
.Group(Magex.New().String("www.")).Repeat.AtMostOnce()
.CharacterIn(Characters.Alphanumeric, allowedChars);

ce qui est tout de même légèrement plus clair : même sans avoir étudié Magex ou le langage utilisé, si vous lisez l’anglais, vous avez des chances de comprendre globalement de quoi ça parle.

Maintenant, prenons le temps de voir à long terme. Les mioches d’aujourd’hui, à qui on va inculquer des bases de code, ils vont vivre leur vie à la fin des années 2020, voire plutôt dans les années 2030. D’ici là, de nouveaux progrès auront été faits, de nouvelles librairies auront été développées, de nouvelles abstractions formelles auront été mises au point. Souris-clavier, ils ne connaîtront probablement pas : ils auront toute leur vie employé des appareils tactiles où ils auront manipulé directement des objets à l’écran, et ils auront probablement des machines capables de reconnaître des gestes faits dans le vide au milieu d’une pièce. Pour tout ce qui est modélisation, les tablettes graphiques sont déjà autant utilisées que la programmation ; demain, ça se fera directement avec les doigts.

Mieux : ces temps-ci, la reconnaissance vocale progresse spectaculairement — dictez une adresse à Google Maps aujourd’hui et comparez avec ce qu’on faisait il y a ne serait-ce que cinq ans, tiens. D’ici à ce que ces jeunes soient en âge d’utiliser leurs compétences, il n’est pas délirant d’imaginer qu’après avoir dessiné un formulaire du bout du doigt, tout ce qu’ils auront à faire pour vérifier qu’il contient une URL, c’est dire à haute voix (et même pas forcément en articulant) :

Vérifie que la chaîne commence par http puis peut-être s, ou ftp, puis deux-points slash slash, puis des caractères alphanumériques, ponctuation, opérateurs mathématiques, carré, dollar, pour cent, esperluette, chapeau, souligné, accent grave, accolades, barre verticale ou tilde.

Le code leur sera-t-il vraiment utile ? Pour ceux qui feront de vrais programmes, sans doute, ne serait-ce que parce que c’est une école de la rigueur appliquée, indispensable pour apprendre à s’exprimer sans ambiguïté (« les gens intelligents auront compris » marche mal avec les ordinateurs, au moins pour l’instant et probablement encore dans un futur proche).

Pour ceux qui seront simples utilisateurs ou qui ne feront que des applications simples comme gérer un portefeuille de vente en ligne, franchement, j’en doute.

Vouloir généraliser l’apprentissage du code au temps du plan Informatique pour tous, c’était osé : les ordinateurs coûtaient cher, personne n’en avait ou presque et rares étaient ceux qui en avaient l’utilité. On a beaucoup raillé Informatique pour tous : « mon fils a appris à dessiner un cercle sur une télé avec une « tortue », ils feraient mieux de lui apprendre les divisions et le passé simple » était une opinion facile, mais répandue. C’était une ère où il fallait un esprit visionnaire pour imaginer qu’on aurait tous, aujourd’hui, accès à un ordinateur et que beaucoup d’entre nous pourrions avoir un jour ou l’autre l’utilité de bases de programmation — que ce soit pour modifier un élément d’un blog, pour analyser des images ou pour supprimer automatiquement les Raw après avoir fait son editing sur des Jpeg. Mais beaucoup d’entre nous avons appris quelques fondements de la programmation, mine de rien, en faisant une fonction « rectangle » avec largeur et hauteur en paramètres, et en l’appelant quatre fois pour faire une fenêtre.

Vouloir généraliser l’apprentissage du code aujourd’hui, je n’arrive pas à me défaire du sentiment que c’est appliquer une solution des années 80 aux problèmes des années 2020. C’est comme si, dans ma génération, on avait dit « bon, l’ordinateur se développe, ça va être important de comprendre comment ça marche, on va faire une initiation à l’assembleur et au Basic ». Les railleries de l’époque ne doivent pas masquer une chose : Logo était un langage de haut niveau, plutôt intelligible et déconnecté de la machine, et les programmeurs d’aujourd’hui utilisent principalement ce type de langages.

Version très simplifiée de l'évolution des langages : compter les secondes jusqu'à un événement, version avant-hier (assembleur), hier (Basic), aujourd'hui (C) et peut-être demain.
Version très simplifiée de l’évolution des langages : compter les secondes jusqu’à un événement, version avant-hier (assembleur), hier (Basic), aujourd’hui² (C) et peut-être demain.

Vouloir enseigner les bases de code, qui vont sans doute se faire avec l’application bête et méchante de petits algorithmes en Ada ou en C, c’est une idée de dirigeants sexagénaires dépassés, qui demandent à leurs enfants trentenaires ce qu’ils font et ce qu’ils auraient dû avoir à l’école pour être efficaces au bureau ; ça n’est pas la vision à long terme de celui qui essaye d’imaginer ce que les enfants qui naissent aujourd’hui auront sur leur plan de travail dans vingt ans.

C’est vouloir enseigner à nos enfants ce qui nous a manqué pour maîtriser nos outils, au lieu de leur apprendre ce qui leur sera utile pour maîtriser les leurs.

¹ À ma connaissance, le plus haut niveau de programmation implémenté directement sur un processeur (et donc disponible en assembleur) s’est trouvé sur le Sparc, capable grâce à son système de fenêtres de registres de faire des appels de fonctions directement en interne, sans empiler les paramètres en mémoire vive.

² Je me suis rendu compte en relisant que j’ai fait une erreur. Si le break est présent dès le début de l’exécution, les versions assembleur et Basic renvoient 1, alors que la version C renvoie 0 (elle fait le test avant la boucle, les deux autres le font en fin de boucle). J’aurais dû faire un do{}while() et pas un while(){} pour que ça soit vraiment le même programme. Oui, je viens de déboguer une simple image d’illustration dont on a rien à foutre. Non, j’ai même pas honte.

  • Tim

    Cool, ca parle de nous 🙂

    Certes appliquer des méthodes d' »hier » n’est pas idéal. Mais l’impact que la maitrise de la prog et des outils informatique a sur la capacité a être autonome et se forger ses propres convictions est tel qu’il faut bien commencer qqpart, non?

  • La vision de ce que pourrait être la « programmation » de demain est assez intéressante. Même si je ne suis pas sûr qu’elle soit si accessible et si idéale que ça. Le langage naturel est en effet très puissant, mais il est aussi plein d’ambiguïtés. Or pour écrire un programme, c’est ce qu’on veut éviter.

    Je n’aime pas trop le terme « code », qui est assez réducteur et que je trouve péjoratif. C’est plus un détail, mais je préfèrerai qu’on se focalise sur le but (apprendre à faire faire des trucs à un ordinateur), plutôt que sur le moyen (écrire des machins dans un fichier texte). C’est peut-être un détail.

    Ensuite, le parallèle qui me chagrine le plus concerne celui fait entre le programme et l’algorithme.

    C’était peut-être vrai il y a quelques dizaines d’années, mais aujourd’hui, l’algorithme en tant que tel ne représente pas le principal du travail. Non, aujourd’hui, le code ne ressemble pas plus à des maths qu’avant. C’est même plutôt l’inverse. On passe beaucoup de temps à créer ou manipuler des concepts plus abstraits. Certes l’algorithmique est un point de départ nécessaire, mais ça ne suffit clairement pas à créer quelque chose d’utilisable.

  • J’ai employé « code » parce que c’est le mot qui est sur toutes les langues ces temps-ci. « Programmation » m’aurait, pour être franc, beaucoup moins inquiété : tant qu’il s’agira de faire faire des trucs à un ordinateur, ça restera de la programmation. « Code » renvoie beaucoup plus directement à la partie bête et méchante du boulot : implémenter un algorithme dans un langage en tapant des instructions dans un fichier.

    En y repensant, je pense que l’exemple du Logo peut être intéressant à reprendre. On nous a appris à dessiner un carré, puis on nous a montré « pour carré [répète 4 [av 50 td 90]] », on nous a montré qu’on pouvait dessiner un deuxième carré en tapant « carré td90 carré », et on nous a laissé extrapoler pour inventer « répète 4 [carré td90] » et obtenir une fenêtre, et ainsi de suite pour dessiner une maison autour.
    J’ai pas souvenir qu’on nous ait fait prendre les choses dans ce que je considère comme le bon sens : « Okay, c’est quoi une maison ? Un toit et une façade. C’est quoi une façade ? Un carré avec une porte et une fenêtre. C’est quoi une fenêtre ? On va dire que c’est quatre carrés. C’est quoi un carré ? Quatre côtés à 90° les uns des autres. »
    On nous a encouragé à coder, à expérimenter un code, mais pas à réfléchir à l’architecture générale de ce qu’on veut faire. Évidemment, l’algorithmique est utile, mais on ne nous a pas vraiment fait toucher du doigt qu’il pouvait exister des langages où il y aurait directement une primitive « fenêtre » : on nous a attachés à l’implémentation finale, au lieu de nous faire réfléchir à la construction qui pourrait y mener.

    File-nous un langage où, au lieu d’avoir une tortue qui fait des « avance » et des « tourne », on a une fonction « ligne(xo, yo, xd, yd) », et on doit tout réapprendre. Alors que si on sait comment la maison est faite, on a juste à refaire le bout qui s’occupe effectivement de dessiner les lignes mais ce qu’on aura appris sur la structure de la maison restera valable.
    Aujourd’hui, on sait pas quels outils seront disponibles dans vingt ans. Mais j’ai peur qu’on parte sur un truc très basique, qui ne pousse pas à la compréhension mais à l’application, bref, qui ne soit pas une initiation à la programmation au sens large (structuration d’une idée, qu’on implémente une fois définie), mais une initiation au codage bête et méchant (pondre des lignes correspondant à un truc déjà établi et bricoler jusqu’à obtenir le résultat escompté).

    Encore une fois, je suis peut-être pessimiste. Peut-être qu’on aura droit à une vraie vision prospective pour se détacher de « taper des instructions dans un fichier texte » et s’attacher à ce qui restera valable et utile quelle que soit l’évolution des outils.