Dans un récent article, la Technology Review se penche sur un vieux « serpent de mer » : l’apprentissage de la programmation pour les non-spécialistes.

Depuis l’apparition du micro-ordinateur, le statut de la programmation au sein de la culture générale fait débat : simple connaissance technique, comme la plomberie ou la mécanique auto, ou au contraire nouvelle forme de littératie ? Cet anglicisme va bien plus loin que la simple notion d’alphabétisme pour inclure celle de compétence, de culture. « Programmez ou soyez programmé », assène par exemple Douglas Rushkoff dans son dernier ouvrage, tandis que de nombreuses recherches et travaux cherchent à rendre cette discipline accessible aux non-spécialistes. Mais l’idée ne plait pas à tous. Le professeur d’informatique et de linguistique Jean Veronis affirmait par exemple, lors d’une table ronde à la BPI : « Je peux utiliser une voiture, ou prendre l’avion, mais je n’ai pas besoin de savoir les fabriquer. Pourquoi cela devrait-il être différent avec les ordinateurs ? ».

La Technology Review cite notamment une étude qui jette le doute sur la capacité de tous à devenir programmeurs. Ce travail de Saeed Dehnadi, Richard Bornat et Ray Adams (.pdf) porte sur les « modèles mentaux » utilisés par les gens face à une simple question de programmation. Selon les auteurs, il existe deux classes de personnes : celles qui utilisent pour y répondre un modèle mental précis, puis l’appliquent de manière consistante. Et celles qui sont incapables de construire un tel modèle ou en changent constamment.

Par exemple, la première question posée à des novices complets (avant leur premier cours de programmation) était la suivante :
soit :
int a=10 ;
int b=20 ;
a=b ;
Que va-t-il se passer ?

La seule chose que savaient les sujets était que le programme effectuait des changements dans les valeurs de a et b ; ils ne connaissaient pas la syntaxe utilisée, pas même le sens du signe « = » qui n’a pas la même signification en informatique qu’en mathématiques. Plusieurs questions du même acabit suivaient. Le but n’était pas tant de trouver la bonne réponse que voir si les étudiants appliquaient le même « modèle mental » dans toutes leurs réponses. Les chercheurs établirent que ceux qui avaient, lors de ce pré-test, montré des capacités de cohérence se révélaient bien meilleurs à la fin de leur cours de programmation. A noter que cette étude a connu son lot de réfutations et de contre-réfutations, et que le débat n’est apparemment pas clos…

Mais la Technology Review ne se concentre pas tant sur cette question. Elle fait surtout mention des idées de Bret Victor, ancien concepteur d’interfaces chez Apple. Selon lui, s’il est si difficile d’apprendre à programmer, c’est avant tout parce que les interfaces et les méthodes d’apprentissage sont complètement défectueuses.

Les langages pour « non-programmeurs  » en prennent ainsi pour leur grade :
« JavaScript et Processing sont des langages mal conçus qui encouragent des manières erronées de penser et ignorent des décennies d’apprentissage sur l’apprentissage ».

Il s’en prend particulièrement au cours de la Khan Academy, lui reprochant l’usage d’une méthode contre-intuitive et peu susceptible d’enseigner le domaine à des débutants. Son exemple est le suivant :

Une personne normale se demanderait alors : que signifie fill, quels sont les chiffres après ellipse, fill et rect ? Mais que demande alors la Khan Academy ? De découvrir ce que signifient ces nombres en les changeant aléatoirement. Imaginez, continue Victor, un micro-ondes plein de boutons dénués de toute légende ou explication, et que la doc vous dise simplement : touchez ces boutons pour voir ce qu’ils font ?

Il donne un autre exemple. Imaginons, explique-t-il, l’interface graphique d’un programme de dessin, qui ressemblerait à ceci :

Ce qui serait considéré comme inadmissible pour une interface est pourtant la norme dans un langage de programmation, s’indigne Victor. Ce qu’il faudrait c’est que chaque instruction d’un programme voie sa signification matérialisée par une explication dans l’environnement. Il en donne ainsi une possible illustration :

Après cette entrée en matière, il multiplie les critiques. Par exemple, la plupart des enseignements de la programmation se contentent de nous donner le résultat d’une séquence d’instructions. Il faudrait plutôt organiser un programme de manière à ce que l’on puisse voir se dérouler sous nos yeux le processus de construction d’une image.

C’est dans les vieux pots qu’on fait les meilleures soupes

Notre programmeur se penche ensuite sur les langages les plus propices à l’apprentissage. Et pour lui, les plus récents ne sont pas forcément les plus efficaces. Hypercard, le système promu dans les premiers Apple, reste à ses yeux un modèle. De même que le Logo, le fameux langage « pour enfants » inventé au MIT.

Hypercard a été révolutionnaire, explique-t-il, parce qu’avec lui on programmait des objets physiques, dessinés sur de petites cartes virtuelles.

Logo est intéressant, car il place le programmeur au sein du programme. Il est représenté par la tortue, une entité virtuelle qui doit effectuer plusieurs actions (avancer, tourner à droite, etc.). Au contraire, dans la plupart des langages de programmation classiques, le programmeur apparaît comme un agent extérieur.

Enfin, Victor parle de Smalltalk (que nous avons déjà évoqué, avec ses deux « enfants », Etoys et Scratch). Pour Victor, Smalltalk est un excellent langage, car il enseigne aux novices l’art de la modularisation, ou décomposition d’un problème. Dans Smalltalk, on est obligé de créer une multitude de petits programmes indépendants interagissant entre eux, ce qu’on appelle les « objets ». La programmation orientée objet constitue une partie de la boite à outils des autres grands langages de programmation depuis longtemps, mais aucun ne respecte cette philosophie comme Smalltalk (comme Alan Kay l’a dit une fois, « je vous garantis que lorsque j’ai inventé la notion de langage orienté objet, ce n’est pas le C++ que j’avais en tête »). Une note personnelle, j’avoue que tous les langages auxquels je me suis frotté (en amateur de bas niveau), aucun ne m’a paru aussi élégant que Smalltalk, dans sa dernière version, nommée Squeak.

En adoptant systématiquement cette philosophie de modularisation, il devient facile de perfectionner ces programmes et les rendre plus complexes, explique Victor :
« Imaginez un programmeur ayant créé une animation d’une balle rebondissante. Comment va-t-il passer d’une balle à deux, puis à cent ? Comment les balles peuvent-elles interagir les unes avec les autres ? Comment peut-on manipuler les balles avec la souris ? Dans un véritable environnement comme Etoys (c’est-à-dire Squeak – NDT), cette progression serait considérée comme naturelle et encouragée. En Processing, chacune de ces étapes devient un cauchemar d’une complexité inutile. Un langage qui décourage le processus de décomposition est un langage qui handicape la meilleure manière de penser d’un programmeur ».

Encore une petite observation personnelle pour conclure ; autant des systèmes comme Scratch, Squeak, Logo et peut être Hypercard (que je ne connais pas) sont des rêves pour les débutants, autant ils deviennent très compliqués (et mal documentés) quand on passe au niveau intermédiaire, quand on veut réaliser sa première application un peu sophistiquée.
La communication avec l’extérieur est loin d’être simple, et les « librairies » sont en trop petit nombre et restent bien souvent largement expérimentales.

Il me semble que l’une des meilleures manières d’encourager un programmeur débutant serait lui donner l’assurance que la formation qu’il acquiert avec son premier langage sera susceptible de le mener très loin, sans qu’il doive, à regret, abandonner son environnement favori pour se frotter à des langages plus professionnels. Même si ceux-ci sont en fait moins bien construits et peu sympathiques, ils disposent de librairies bien plus complètes et d’une documentation plus abondante.

Rémi Sussan