Re: [jecode] Visual Programming Is Unbelievable
> Je trouve l'approche combinée entre mode visuel et mode texte vraiment très > intéressante. Chacun à ses avantages en termes d'expressivité et pour moi il > y a du sens à mélanger les deux. En tout cas ça a bien fonctionné pour moi. Oui c'est le principe d'ailleurs je crois bien adopté par NodeBox, nodeRED. D'une certaine manière aussi VisiCalc / Excel est un mode de programmation visuel qui mêle texte (les formules) et le visuel (la grille). ___ Discussion mailing list Discussion@jecode.org http://listes.jecode.org/cgi-bin/mailman/listinfo/discussion
Re: [jecode] Visual Programming Is Unbelievable
Bonjour, - Mail original - > De: "Julien Dorra" > Envoyé: Mardi 22 Mars 2016 08:37:53 > > À titre d'information j'ai pu assisté ce weekend (lors des #AdamiCED) > a au moins deux (et peut-être trois ou quatre) projets sur 11 dont > un composant était créé en programmation visuelle avec > respectivement Max/MSP et PureData. > Une des créatrices, Suzanne au conservatoire en "musicologie et > informatique", qui avait créé un patch complexe avec gestion du son > et interface graphique sous Max/MSP a tout de même émis l'idée > qu'elle aurait mieux géré la complexité en Python (qu'elle connait > très peu, donc en réalité ce n'est pas certain !). J'ai pratiqué un peu PureData et Max/MSP (pour être plus précis avec Max4Live, mais peu importe). Et j'ai aussi était confronté à cette limite de la programmation visuelle avec la sémantique à la Max. Arrivé à un moment ce que je voulais faire était pour moi trop compliqué à faire avec les outils de Max/MSP alors qu'avec un langage en mode texte je savais que je serai plus à l'aise. Et il se trouve que Max/MSP offre la possibilité de faire du JavaScript ! Cool. J'ai donc pu faire un mix entre blocs Max/MSP et code JavaScript. Et c'est suivant ce que je devais manipuler que j'ai choisi l'un ou l'autre. En gros les blocs pour tout ce qui est lié à l'audio/MIDI/OSC et à l'interface ou aux outils spécifiques Max/MSP, et le JavaScript pour tout ce qui est manipulation de données plus classique. Je trouve l'approche combinée entre mode visuel et mode texte vraiment très intéressante. Chacun à ses avantages en termes d'expressivité et pour moi il y a du sens à mélanger les deux. En tout cas ça a bien fonctionné pour moi. a+ Nicolas ___ Discussion mailing list Discussion@jecode.org http://listes.jecode.org/cgi-bin/mailman/listinfo/discussion
Re: [jecode] Visual Programming Is Unbelievable
Bonjour,
J'ai bien quelques remarques à ajouter ou questions à poser, mais je manque de
temps.
Je vous pose ça là sinon :
- www.emojicode.org
- Logibox.gaelgouault.com
Samuel Chalifour
> Le 17 mars 2016 à 11:15, Bastien Guerry a écrit :
>
> Hello Pierre,
>
> merci pour les retours.
>
> Un point important : j'aurais dû préciser que l'article considère la
> question des langages visuels hors de la question pédagogique, qui est
> celle qui nous intéresse ici.
>
> Pierre Boudes writes:
>
>> Je trouve l'article un peu lapidaire pour un sujet important, il y
>> aurait tant à approfondir.
>
> "Le plus long voyage commence par le premier pas" :)
>
> @Charles: je serais heureux que la blogosphère francophone produise
> autant d'articles de m... rapides, superficiels, etc. sur ces sujets!
> Le mérite d'exister est tout de même un sacré mérite !
>
>> De ce que je lis les griefs principaux sont ceux qu'on pourrait avoir
>> contre n'importe quel autre type de langage dont les outils (IDE,
>> debug etc.) ne sont pas au point, dont la communauté est trop petite,
>> les applications ne sont pas visibles au premier plan (car réservés à
>> certaines industries) :
>
> Je ne suis pas d'accord. Chaque grief peut s'appliquer à d'autres
> langages ("non-visuels") mais l'ensemble des griefs *réunis* est
> propre aux langages visuels -- ou du moins présenté comme tel.
>
> Je reprends les arguments :
>
> (1) Visual Languages Aren’t Extensible
> (2) Visual Languages Generate Slow Code
> (3) Visual Language Tools Can Be Terrible
> (4) Visual Languages Lock You In
> (5) You Are Neurologically Programmed to Reject It
>
> (1) Vaut dans un cadre classique, moins dans un cadre pédagogique.
>
> (2) Pareil, et je suis d'accord que c'est trop général de toutes façons.
>
> (3) Ça j'y suis très sensible : AMHA Scratch doit son succès à une
>implémentation très simple des concepts _et_ de l'interface... si
>on compare par exemple à Etoys, qui repose sur des briques un peu
>plus complexes, mais surtout sur une interface moins intuitive.
>
> (4) Redondant avec (1)
>
> (5) C'est le point qui m'intéresse et qui est le plus fragile dans ce
>post, mais ça me semble pointer vers quelque chose d'intéressant:
>c'est une même qualité (l'approche « visuelle ») qui rend Scratch
>facilement appréhensible par les enfants, et pour difficilement
>représentatif du travail ordinaire de l'informaticien, qui est
>_d'écrire_ du code. D'où une forme de paradoxe... qu'on pourrait
>explorer plus à fond tous ensemble un jour :)
>
> En fait je suis sensible au décalage qu'il y a entre l'engouement
> provoqué par des réflexions comme celle de Brett Victor, et le peu de
> retombées concrètes dans l'activité de programmation.
>
> À très peu de choses près, programmer aujourd'hui se fait de la même
> façon qu'il y a 20 ans, voire 40 ans.
>
> Même si régulièrement, le sujet de la programmation visuelle lance de
> nouvelles promesses.
>
> Donc qu'est-ce qui bloque ? À vue de nez (et mon nez n'est pas très
> scientifique), je dirais qu'il y a une contrainte cognitive cachée.
>
> Turing ne joue pas aux dés.
>
> :)
>
> Bonne semaine à tous !
>
> --
> Bastien
> ___
> Discussion mailing list
> Discussion@jecode.org
> http://listes.jecode.org/cgi-bin/mailman/listinfo/discussion
___
Discussion mailing list
Discussion@jecode.org
http://listes.jecode.org/cgi-bin/mailman/listinfo/discussion
Re: [jecode] Visual Programming Is Unbelievable
Hello Pierre,
merci pour les retours.
Un point important : j'aurais dû préciser que l'article considère la
question des langages visuels hors de la question pédagogique, qui est
celle qui nous intéresse ici.
Pierre Boudes writes:
> Je trouve l'article un peu lapidaire pour un sujet important, il y
> aurait tant à approfondir.
"Le plus long voyage commence par le premier pas" :)
@Charles: je serais heureux que la blogosphère francophone produise
autant d'articles de m... rapides, superficiels, etc. sur ces sujets!
Le mérite d'exister est tout de même un sacré mérite !
> De ce que je lis les griefs principaux sont ceux qu'on pourrait avoir
> contre n'importe quel autre type de langage dont les outils (IDE,
> debug etc.) ne sont pas au point, dont la communauté est trop petite,
> les applications ne sont pas visibles au premier plan (car réservés à
> certaines industries) :
Je ne suis pas d'accord. Chaque grief peut s'appliquer à d'autres
langages ("non-visuels") mais l'ensemble des griefs *réunis* est
propre aux langages visuels -- ou du moins présenté comme tel.
Je reprends les arguments :
(1) Visual Languages Aren’t Extensible
(2) Visual Languages Generate Slow Code
(3) Visual Language Tools Can Be Terrible
(4) Visual Languages Lock You In
(5) You Are Neurologically Programmed to Reject It
(1) Vaut dans un cadre classique, moins dans un cadre pédagogique.
(2) Pareil, et je suis d'accord que c'est trop général de toutes façons.
(3) Ça j'y suis très sensible : AMHA Scratch doit son succès à une
implémentation très simple des concepts _et_ de l'interface... si
on compare par exemple à Etoys, qui repose sur des briques un peu
plus complexes, mais surtout sur une interface moins intuitive.
(4) Redondant avec (1)
(5) C'est le point qui m'intéresse et qui est le plus fragile dans ce
post, mais ça me semble pointer vers quelque chose d'intéressant:
c'est une même qualité (l'approche « visuelle ») qui rend Scratch
facilement appréhensible par les enfants, et pour difficilement
représentatif du travail ordinaire de l'informaticien, qui est
_d'écrire_ du code. D'où une forme de paradoxe... qu'on pourrait
explorer plus à fond tous ensemble un jour :)
En fait je suis sensible au décalage qu'il y a entre l'engouement
provoqué par des réflexions comme celle de Brett Victor, et le peu de
retombées concrètes dans l'activité de programmation.
À très peu de choses près, programmer aujourd'hui se fait de la même
façon qu'il y a 20 ans, voire 40 ans.
Même si régulièrement, le sujet de la programmation visuelle lance de
nouvelles promesses.
Donc qu'est-ce qui bloque ? À vue de nez (et mon nez n'est pas très
scientifique), je dirais qu'il y a une contrainte cognitive cachée.
Turing ne joue pas aux dés.
:)
Bonne semaine à tous !
--
Bastien
___
Discussion mailing list
Discussion@jecode.org
http://listes.jecode.org/cgi-bin/mailman/listinfo/discussion
Re: [jecode] Visual Programming Is Unbelievable
Le 16/03/2016 07:09, Pierre Boudes a écrit : Je ne connais pas d'analyseur syntaxique qui ne fonctionnerait pas sur un flux (même brainfuck). Oups, je voulais dire même *Befunge* (et non brainfuck) peut être parsé en flux. Par contre ce sera incompréhensible pour un humain. https://fr.wikipedia.org/wiki/Befunge P. ___ Discussion mailing list Discussion@jecode.org http://listes.jecode.org/cgi-bin/mailman/listinfo/discussion
Re: [jecode] Visual Programming Is Unbelievable
Le 15/03/2016 23:01, Charles Boisvert a écrit : C'est la qu'une definition stricte de "visual programming" peut servir. J'essaie: /Un meme programme peut etre presente de facon differentes. note de base de page : un même arbre syntaxique abstrait peut être représenté et vu de plusieurs façons. 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./ Pour continuer dans cette direction : la plupart des langages ont une représentation en flux d'éléments syntaxique. Je ne connais pas d'analyseur syntaxique qui ne fonctionnerait pas sur un flux (même brainfuck). On peut donc toujours passer par une représentation en flux (textuelle) d'une syntaxe. Par contre un langage visuel peut apporter une compréhension à l'humain qui est inaccessible en version flux (je pense aussi à la lecture à haute voix de programmes). mes 2 centimes ;) P. ___ Discussion mailing list Discussion@jecode.org http://listes.jecode.org/cgi-bin/mailman/listinfo/discussion
Re: [jecode] Visual Programming Is Unbelievable
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
Re: [jecode] Visual Programming Is Unbelievable
Hello Bastien, Le 15/03/2016 13:52, Bastien Guerry a écrit : "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 Je trouve l'article un peu lapidaire pour un sujet important, il y aurait tant à approfondir. Évidemment, il manque une sorte de définition de "Visual programming", ou même une liste des logiciels implicitement visés. ça on l'a sur wikipedia ;) De ce que je lis les griefs principaux sont ceux qu'on pourrait avoir contre n'importe quel autre type de langage dont les outils (IDE, debug etc.) ne sont pas au point, dont la communauté est trop petite, les applications ne sont pas visibles au premier plan (car réservés à certaines industries) : “most visual languages generate unreadable lower level code, only target niche segments, are supported by suicidal startups, or haven’t left the research lab yet (where amazing recent work, like Bret Victor’s, is being done). Real success stories, of people using it in large projects, are still rare, and these communities are still growing.” > que la réflexion sur les limites de l'extensibilité et notre amour de > la complexité sont intéressantes. Je crois que la question de l'extensibilité n'est pas spécifique aux langages visuels. Amha, ce qu'il considè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 Discussion@jecode.org http://listes.jecode.org/cgi-bin/mailman/listinfo/discussion
