Bastien: > >> "Visual Programming Is Unbelievable ... Here’s Why We Don’t Believe In >> It" >> >> http://www.outsystems.com/blog/2015/03/visual-programming-is-unbelievable.html >> >> Pierre:
> Je trouve l'article un peu lapidaire pour un sujet important, il y aurait > tant à approfondir. > Charles: Et comment. L'article donne trois exemples qu'on peut juger comme etant "visual programming": Case tools, UML, ER modelling. Les trois sont des annees 80. Les trois sont encore en usage aujourd'hui; ce qui ne se fait plus, c'est d'utiliser systematiquement le code qu'ils generent. Apres ca, l'article fait le tour de critiques qui sont frequemment repetees sur toutes sortes de langages, pas juste visuels. Il ne donne aucun exemple pour montrer ce qu'il veut dire par lenteur, limite des applications, etc. Il ne separe pas non plus l'approche (les possibilite theoriques du champ de recherche) des applications (les instances particulieres de langages en usage). Et enfin, comme il manque une definition de "visuel", ses affirmations ne sont pas falsifiables: quoi qu'on dise, il sera toujours possible de trouver un langage qu'on appellera visuel, pour lequel l'affirmation sera vraie. Et vice-versa. Autrement dit, l'avantage des blogs sur les articles soumis a un comite editorial, c'est que le blog, n'a pas besoin d'etre d'abord juge publiable. L'inconvenient, c'est que du coup, c'est souvent de la m.... Pierre: > Pour revenir à Scratch, je pense qu'un des points essentiels est qu'il n'est pas offert > de générer le code textuel d'un programme Scratch En effet, et la, on va trouver pratique de separer l "approche" et l ' "instance". Parce que Scratch n'est qu'une instance parmi d'autres de l'approche qu'on pourrait appeler "programmer par blocs". Et justement, un autre exemple des blocs, est Google Blockly. Contrairement a Scratch, blockly ne cache pas le code, au contraire, la comprehension du code, son usage avec des langages differents, la recherche d'equivalences en code plus efficaces, est encouragee. Donc si on recherche un outil pour la classe, il faut se demander quels benefices on retire de characteristiques particulieres de chaque outil. Est ce que la lenteur de Scratch est un probleme? L'absence de variables locales? Est ce que le volume du site web et ses outils de partage sont un avantage? Vous n'aurez jamais tous les avantages de tous les langages dans un logiciel unique, donc vous devrez faire des choix. Par contre si vous vous posez des questions d'approche, on ne peut pas juger de la valeur d'une approche sur la base d'une version particuliere. C'est la qu'une definition stricte de "visual programming" peut servir. J'essaie: *Un meme programme peut etre presente de facon differentes. En plus du code du programme, et de l'execution elle-meme, il est possible de representer et de manipuler les instructions de facons multiples, pour faciliter la comprehension, l'edition et la modification d'un programme par des specialistes, des membres du public, ou meme des enfants. De nombreuses tentatives de representation et d'edition de programmes s'appuient sur des representations visuelles: pictogrammes (Hypercard), blocs (Scratch, blockly), diagrammes (rational rose), interface (editeur Microsoft de Visual .Net). D'autres ne sont generalement pas presentes comme visuels mais servent toujours l'objectif de faciliter l'accessiblite: outils de refactoring, analyseurs, coloration, indentation et documentation automatique du code. La programmation visuelle est l'usage de technique d'interaction qui facilitent l'accessibilite d'un large public a la programmation.* OK, si vous avez une meilleure definition, peut-etre qui discriminerait mieux les outils type scratch des autres, ne vous genez pas. Mais il me semble que le genie de "Scratch et cie", c'est l'usage tout a fait particulier de ces representations multiples d'un meme code. Et de par cette definition-la, je ne vois pas ou l'approche poserait probleme. Par contre les langages et logiciels specifiques posent chacun des problemes specifiques, et il faut les choisir en connaissance de cause. Le plus important est peut etre de reflechir a l'application des circulaires ministerielles. Si vous faites cours, plutot que d'appliquer Scratch a tout prix, considerez "des outils de type scratch", qui inclueraient blockly, byob, alice, et quelques autres. Vous pourrez alors choisir, par exemple, scratch pour son site web mais blockly pour sa compilation en Javascript, ou byob pour ses variables locales. 2 pence d'Angleterre, Charles > > Amha, ce qu'il considtoolsère comme de la complexité est une conséquence > de notre appétit à résoudre les problèmes des autres. > « Sugar c'est vraiment super pour les enfants tu devrais essayer dans ta > classe ! > — mais il faut un OLPC non ? > — non ! Tu peux utiliser Sugar on a stick il suffit de flasher une clé > - flasher une clé, cool tu peux m'expliquer ? > - ok je t'appelle ce soir > [deux heures de galère] > une semaine plus tard : > - j'ai testé la clé, chez moi ça marche mais à l'école, ça ne boot pas. Je > crois que l'ordinateur de la salle de classe est configuré pour refuser de > booter sur clé. > — ah oui c'est vrai c'est le conseil départemental qui impose ça ! Attends > il y a une solution il te faut un CD spécial qui passera le boot à la clé. > — hum, je veux bien essayer mais je ne sais pas si les enfants y > arriveront tout seuls. > […] > un mois plus tard : > - Les enfants s'en sortaient bien mais j'ai laissé tomber, le lecteur de > CD ne fonctionne plus. » > > Si tu formules dans le problème la nécessité d'avoir une solution simple à > mettre en œuvre et robuste (résiliente, pour suivre la mode), cette > complexité n'est plus le problème. > > Par contre, l'informatique ou la programmation ne forment pas un tout > cohérent et simple, il y reste même plein de questions très très vives. > > Il faut donc éviter de prétendre que les choses sont simples et que savoir > programmer en cobol c'est savoir programmer en erlang. Raison de plus pour > ne pas donner à des enfants des trucs qui ne fonctionnent qu'à moitié ou > qui ne tiennent pas compte de l'hétérogénéité des situations. > > Pour revenir à Scratch, je pense qu'un des points essentiels est qu'il > n'est pas offert de générer le code textuel d'un programme Scratch (alors > que rien ne s'y oppose dans la syntaxe visuelle) et de pouvoir l'utiliser > en mode texte dans un univers de programmation plus vaste. Difficile du > coup de passer de scratchJr (avant de savoir lire) à Scratch (avant de > savoir un peu taper et voir/corriger des typos) puis à un langage textuel > (communauté, REPL, débugage, etc.). > > Par exemple imagine deux minutes qu'on puisse extraire le code complet > d'un programme Scratch sous la forme d'un code Python (ou autre) > nécessitant un seul import pour fonctionner, on aurait fait un net progrès > pour le passage aux étapes suivantes de la découverte de la programmation. > > En tous cas ça fait écho chez moi à plein de doutes que j'ai quand je >> vois Scratch et cie être la norme de l'initiation à la programmation. >> > > Si tu veux partager ces doutes, de mon côté j'aimerai bien en discuter > sérieusement avec toi et éventuelle d'autres sur la liste. C'est un sujet > qui revient de plus en plus souvent avec des collègues plus ou moins > impliqués dans les programmes de l'option d'info au capes ou dans le > développement d'outils pour l'initiation à la programmation. > > > A+ > Pierre (université Paris 13) > > > _______________________________________________ > Discussion mailing list > [email protected] > http://listes.jecode.org/cgi-bin/mailman/listinfo/discussion >
_______________________________________________ Discussion mailing list [email protected] http://listes.jecode.org/cgi-bin/mailman/listinfo/discussion
