Enseigner la programmation
Bret Victor par CUSEC, en cc-by.
, par
Notre nouveau collègue John Chaussard, m’a signalé un excellent essai web : Learnable Programming, qui vient d’être publié par Bret Victor.
Du même auteur, sur quasiment le même sujet, cela vaut vraiment le coup de regarder la présentation Inventing on Principle (vimeo), donnée à CUSEC 2012.
Je suis certain que cet essai fera date.
Bien qu’étant très critique, et à raison, envers Processing, Bret Victor illustre son propos avec des snippets de ce langage. Je ne sais pas quelle alternative il avait, mais son article est très clair sur les limitations de Processing comme langage d’apprentissage, au point qu’il m’a convaincu de ne pas en faire le premier langage à enseigner. Par contre, Processing reste certainement une expérience intéressante pour initier des étudiants à la visualisation de données, au milieu d’un cours sur un langage impératif proche.
Le vrai mérite de l’essai de Bret Victor est de contribuer à produire un appareil critique pour parler de cours de programmation et du choix des langages enseignés. Personnellement, sur la question des langages, je pense que puisqu’on a tant de mal à choisir un langage qui fasse consensus en enseignement, c’est qu’il faut certainement en enseigner plusieurs.
L’approche critique de Bret Victor
Pour comprendre l’apport de cet essai de Bret Victor à une approche critique de l’enseignement de la programmation, le mieux est de le lire. Après cette lecture le petit mémo suivant permettra de s’en souvenir.
L’environnement de programmation doit permettre de :
– acquérir le vocabulaire (rendre le sens facile d’accès, situer dans le contexte)
– suivre le flot de contrôle
– voir l’état courant (voir les données, pouvoir comparer, ne pas utiliser d’états cachés)
– créer par réaction (avoir un point de départ et le sculpter, obtenir quelque chose à l’écran rapidement, étaler la boîte de composants sur le sol)
– créer par abstraction (développer sa confiance dans les détails de bas niveau pour progresser vers un contrôle de haut niveau, commencer avec des constantes puis faire varier, commencer avec un seul élément puis passer à plusieurs).
Le langage de programmation doit permettre de :
– identifer et produire des métaphores (mettre en relation l’ordinateur et le monde)
– décomposer (découper les pensées en morceaux de taille pensable, mouth-sized bites selon une expression empruntée à Papert [1])
– recomposer (les possibilités de recomposition conditionnent la décomposition)
– améliorer la lisibilité.
Ce qui ne fonctionne pas en enseignement avec Processing
Selon Bret Victor, voilà ce qui ne va pas avec Processing.
– Comment fonctionne l’exécution de programme est invisible (malgré le système live coding de Resig / Kahn Academy) ;
– Processing utilise intensément l’état courant (pour la couleur de fond, la couleur et l’épaisseur du trait, le lissage, la transformation affine etc.), mais ne permet pas de le visualiser simplement. Pire l’état courant altère le sens des arguments des fonctions (Bret Victor prend l’exemple de la fonction fill() dont le résultat dépend du mode de rendu couleur).
– Toujours à cause de cet état courant, mais aussi du fait de la structuration d’un programme Processing, avec un corps de boucle principale draw(), il est très malaisé de récupérer des composants d’un programme pour les injecter dans un autre (un peu comme avec le web vs la facilité qu’offrait en cela hypercard). S’il est possible de procéder par décomposition sous forme de fonctions, on ne peut pas faire de modules indépendants.
– La convention de nommage est inconsistante (verbe, nom etc.). Le sens des arguments ne peut pas être obtenu à partir du contexte.
– En termes d’apprentissage, Processing ne permet pas au programmeur de s’identifier à une partie du système (comme la tortue en Logo), ou d’apprendre par assimilation au monde physique.
– Dans Processing le calcul est effectué de manière cachée pour prendre effet sous forme de dessin, l’aspect calculatoire de la programmation est ainsi masqué.
– Le fait que beaucoup de personnes utilisent les plateformes de découverte de la programmation avec Processing, avec des projets très créatifs, ne permet pas de conclure que Processing est un bon langage. On peut être créatifs dans des environnements très hostiles.
Quel(s) langage(s) enseigner et comment ?
Mon point de vue est que puisque nous ne tombons en général pas d’accord sur le meilleur langage pour commencer la programmation, c’est qu’il n’y en a pas un de meilleur. À mon avis il faut arriver à faire passer au moins trois langages :
– Enseigner un langage qui ne soit pas qu’un jouet limité mais qui puisse devenir un véritable outil pour des projets d’envergure. Quitte à se borner à un sous-ensemble de ce langage.
– Dans le même temps insister sur la capacité humaine à manipuler des algorithmes et inciter chacun à développer sa capacité d’expression d’algorithmes en langage naturel. Ceci ne passe pas par une codification du langage de description des procédures, mais par un impératif plus faible : s’exprimer pour être compris sans ambiguïté.
– Enfin (et mes cours commencent par là), produire un langage minimal représentant les actions de base de l’ordinateur (c’est l’objectif de mon langage amil).
Mais une fois ces trois niveaux de langage présentés, je crois qu’il ne faut pas hésiter à fonctionner par analogie et proposer des incursions dans des environnements de programmation différents. Ainsi une approche à la logo jouera sur la capacité de l’apprenant à se projeter dans les actions du programme, en même temps qu’un langage plus traditionnel lui permettra de transférer sa compréhension de la structure des programmes puis de monter en abstraction.
Merci John pour le lien !
Notes
[1] Seymour Papert, Mindstorms, Children, Computers, And Powerful Ideas. Papert tient l’expression mind-sized bites d’un enfant de 12-13 ans, Robert. See, now all my procedures are mind-sized bites. I used to get mixed up by my programs. Now I don’t bite off more than I can chew.