Re: [EDUC] Codage à l'école : Snap! ou Scratch

[Stéphane Zuckerman <stephane.zuckerman AT gmail.com>]

Bonjour, 

2016-03-09 9:22 GMT-05:00 Nicolas George <ngeorge AT april.org>:

> Et qui va s'amuser à faire un jeux vidéo en assembleur ?

Au hasard, à peu près tous les développeurs de jeux des années 1980...

Mais plus personne de nos jours (sauf pour les parties qui demandent une réelle optimisation). En fait, la plupart du temps, les jeux vidéo emploient plusieurs langages (C/C++ pour les parties réclamant de bonnes performances, Lua pour scripter une partie de l'intelligence artificielle de l'ordinateur et choisir comment enchaîner les scènes dans un jeu, etc.).

>                                                          Un langage a ses
> atouts et ses défauts.

Oui, bien sûr. Sauf que les pseudo-langages graphiques n'ont in fine aucun
atout qui en fasse un choix adapté au développement d'une application un
tant soit peu complexe.

On utilise des langages graphiques dans les outils de conception numérique : on « dessine » les boites noires, en décrivant les ports d'entrée/sortie, etc., et le vrai code (VHDL ou Verilog par exemple) est généré automatiquement. De même, on peut décrire graphiquement comment relier des composants entre eux, et le code généré sera synthétisable. La seule raison qui fait qu'on va malgré tout décrire le comportement interne de ces boites noires dans un langage textuel plutôt qu'en jouant avec des portes logiques graphiques est lié à la productivité : décrire les boites noires graphiquement va généralement plus vite que l'écrire à la main, alors que décrire le comportement du composant graphiquement prendra souvent plus de temps (déplacement à la souris pour connecter les composants internes, etc.) que si l'on l'écrit directement sous forme de code. 

Bref. Les langages graphiques ont une réelle place dans l'industrie, et ne sont pas de simples « pseudo-langages ». J'ajouterai qu'il existe tout un tas de langages de flot de données (dataflow languages) qui permettent de décrire des circuits électriques et électroniques et qui assez populaires dans des domaines spécifiques. 

La seule chose qui compte selon moi est de savoir si un langage (graphique ou non) permet d'inculquer les bons réflexes en termes de raisonnement et/ou de méthodologie chez les élèves. Pour des élèves dans le supérieur, très clairement je favoriserais un langage textuel, même si le résultat lui-même pourrait être graphique (c'est ce que fait l'université de Versailles Saint-Quentin-en-Yvelines pour son cours de L1 : programmation en C couplée à l'utilisation de bibliothèques graphiques fournies par les enseignants, avec des primitives de haut-niveau pour simplifier la tâche des élèves). Pour des élèves de primaires ou de collège (ou lycée), je ne sais vraiment pas. 

 

Après, est-ce que ça veut dire qu'il ne faut pas les employer, c'est une
autre question.

Pour ma part, j'ai de grosses réticences vis-à-vis des outils qui ne sont
utilisés QUE pour l'enseignement. Au mieux, ça a tendance à donner des
jouets déconnectés des réalités pratiques, mal généralisables. Au pire, ce
sont des élucubrations du niveau du « référentiel bondissant ».

Je voulais éviter de parler d'anecdotes liées à mon expérience perso (j'enseigne dans le supérieur, donc mon expérience avec des élèves du primaire ou du secondaire est quasi-nulle), mais quand même : ma première expérience en programmation était en LOGO au primaire. Certes, il fallait taper des commandes, mais c'était pour obtenir un résultat graphique. Et si au début on passait par une boucle interactive, ceux qui se débrouillaient assez bien étaient encouragés à passer en mode « pur texte », et essayer d'imaginer comment faire bouger le trian…euh, la tortue plusieurs étapes à l'avance. Je pense que cette première expérience de programmation a été essentielle pour moi. De ce que j'ai pu voir de Snap!, les choses sont relativement identiques. Par contre, la multitudes d'écrans pour gérer les variables, les structures de contrôle, les mouvements de la tortue, etc., me semblent pouvoir mener à une « saturation sensorielle » pour l'élève (je me doute qu'on ne va pas tout présenter à la fois, mais bon…). Mais comme je le disais, je n'ai pas de vraie expérience d'enseignement au collège/lycée.

Bref, le graphique pour programmer, c'est partout pareil : au début c'est super pratique pour comprendre certains concepts et voir le résultat directement, et puis, à mesure qu'on devient bon avec l'outil graphique, lorsqu'on veut devenir plus productif, on s'aperçoit que la ligne de commande ou bien passer par un éditeur de texte finit par être plus efficace. Mais il me semble que cette conclusion devrait arriver graduellement chez les élèves (encore une fois, je me trompe peut-être).