Faire usage des langages de programmation visuelle : une mauvaise idée ?

Faire usage des langages de programmation visuelle : une mauvaise idée ?
La question divise

S’il vous est arrivé de créer des programmes informatique en faisant uniquement usage d’éléments graphiques plutôt qu’en tapant sur un clavier pour saisir du texte, alors vous étiez en plein dans la programmation visuelle. L’image qui suit donne un aperçu de ce qui se fait avec le langage de programmation Scratch proposé sur de célèbres plateformes comme les ordinateurs monocarte Raspberry Pi.

Pièce jointe 416813

Scratch fait partie des applications les plus prisées de l’univers de l’enseignement. Les formateurs s’appuient sur la plateforme d’apprentissage de codage pour initier les plus jeunes à la programmation. La richesse de l’écosystème en matière de projets publiés y aide. On en dénombre plus de 38,6 millions sur des projets allant de l’animation à la simulation 3D. Les apprenants peuvent donc aller du plus simple au plus complexe sans avoir à saisir des lignes de code. Mais, la programmation visuelle n’est pas limitée au monde de la formation. Elle trouve des preneurs en industrie, notamment, dans le milieu du génie électrique. En 2018, des langages graphiques comme le langage à contacts (langage ladder) ou le grafcet demeurent les outils de premier choix dans l’arsenal de l’expert électricien pour programmer les automates – des ordinateurs destinés à la commande des processus industriels.

https://www.youtube.com/watch?v=7P4gGCvgNnk

On parle bien ici de développement d’applications industrielles. Il semble donc exagéré de conclure (comme l’a fait Mike Hadlow) que l’usage de langages de programmation visuelle est une mauvaise idée. « La programmation visuelle n’a pas réussi à s’imposer, sauf dans certains domaines très limités », reconnaît le développeur. D’ailleurs, pour allonger la liste, il faut souligner que les moteurs 3D tels qu’Unreal sont reconnus pour la qualité des outils de programmation visuelle qu’ils offrent aux développeurs. Mike Hadlow est d’avis que la facilité de création (et de compréhension) des programmes qui résulterait de l’usage d’outils de programmation visuelle n’est qu’un mirage. Il suggère ainsi que la programmation textuelle est la voie idéale, mais on pense qu’il est bon pour un développeur de savoir tirer parti du meilleur de chaque monde. Un moteur comme Unreal offre la possibilité d’étendre les capacités des outils de programmation visuelle intégrés à l’aide du langage C++. Alors, pourquoi s’en priverait-on ?

Source : billet de blog

Et vous ?

:fleche: Qu’en pensez-vous ?

:fleche: Je fais uniquement usage des langages de programmation textuels ; je n’utilise rien d’autre en dehors des langages de programmation visuelle ; je combine les deux façons de faire ; où est l’erreur ?

Voir aussi :

:fleche: Quel est l'effet du langage de programmation sur la qualité du logiciel ? Une étude tente de clarifier la situation

:fleche: Quel langage de programmation choisir pour débuter ? Un développeur donne son avis et compare neuf langages aux personnages du Seigneur des anneaux

Bonjour,

Les langages présentés ici ne me choquent pas: le premier est fait pour apprendre à programmer, le second nécessite déjà de savoir, euh "programmer de l'électricité" :p et existait déjà avant l'informatique (arrêtez-moi si je dis une bêtise?).
Le second obéit à un standard déjà existant, et le premier ressemble à un langage textuel dans lequel on n'a pas besoin de gérer les erreurs de syntaxe et autres fautes de frappe.

Ce qui m'a dérangé avec des langages visuels auxquels j'ai été confronté professionnellement (uScript pour Unity et Blueprints pour Unreal), c'est qu'ils sont promus comme permettant à un non-programmeur de faire un programme complet, alors que si on les regarde deux minutes... Ils nécessitent d'avoir autant de logique qu'un langage textuel: il y a des boucles, des branches, des conditions... En Blueprint, on se retrouve même souvent à faire des cast (un sujet qui fait déjà débat chez les programmeurs, alors comment le faire assimiler à un non-programmeur?). Et ils ont en plus besoin d'artifices dont les langages textuels n'ont pas besoin: il faut gérer les "liens" entre les instructions (alors qu'on sait qu'en texte, une instruction est grosse-modo toujours liée à celle qui se trouve en-dessous, d'ailleurs un éditeur de texte ne permet pas de faire autrement :p ), il faut gérer la mise en page de son "code" pour qu'il soit lisible (alors qu'en texte, à part qu'on doit suivre des règles d'indentation, ça se fait tout seul)...

Bizarrement, le post de blog original ne parle pas de ceux-ci (qui sont vraiment mauvais) et prend Scratch comme unique exemple (qui n'est même pas un langage fait pour créer des produits finis mais un outil pédagogique pour apprendre la programmation en général), je ne comprends donc pas comment il en arrive à cette conclusion...

nous ne sommes pas égaux devant la cognition. Je suis très mal à l'aise devant un mur de graphiques, d'autres seront aussi mal à l'aise devant un mur de texte. Donc : Pourquoi pas les deux? Que chacun puisse attaquer le code à sa manière.

Dans le temps on créait un programme via des organigrammes (http://robert.cireddu.free.fr/SI/Cou...origrammes.pdf).
Au lieu de les faire sur du papier, on va le faire via une interface avec une génération de code (masquée)... rien de bizarre, le vintage revient à la mode ;-)

Au début j'avais pensé à des programmes tels que Scratch pour faire découvrir la programmation à mes enfants mais finalement j'ai préféré ne pas le faire.

Je pense que l'intervalle de temps entre le moment où il peuvent vraiment apprendre Scratch et le moment où il peuvent apprendre des langages plus avancés est très court, peut-être 3 ou 4 ans (disons de 5/6 à 8/10 ans) mais en gros arrivés au CM1 ils peuvent tout à fait programmer avec des langages qui, une fois acquis, leur serviront toute leur vie.

Donc aucun intérêt à rusher le Scratch trop tôt à moins de vouloir en faire des bêtes de concours:

• Si c'est pour l'amusement il y a plein de trucs au moins aussi amusant, et si c'est pour l'amusement ce n'est pas pour l'apprentissage donc le débat n'est pas là (chacun s'amuse comme il en a envie, je ne juge pas)
• Si c'est pour l'apprentissage, mieux vaut apprendre d'autres choses : vélo, roller, escalade, musique, il y aura bien le temps pour la programmation plus tard

Citation:

---

Envoyé par nuke_y

• Si c'est pour l'amusement il y a plein de trucs au moins aussi amusant, et si c'est pour l'amusement ce n'est pas pour l'apprentissage donc le débat n'est pas là (chacun s'amuse comme il en a envie, je ne juge pas)
• Si c'est pour l'apprentissage, mieux vaut apprendre d'autres choses : vélo, roller, escalade, musique, il y aura bien le temps pour la programmation plus tard

---

Ma fille utilise Scratch pour faire des compos musicales avec une danseuse qui fait des mouvements en rythme. C'est de l'amusement, c'est de l'apprentissage, c'est de la programmation, c'est de la musique. C'est ce qui est appréciable avec Scratch je trouve : chaque enfant y trouve de l'intérêt selon ses préférences.

Perso, je préfère la programmation en texte également. J'ai aimé très jeune passer 15 h à programmer un chifoumi. Par contre, quand je veux faire un formulaire, j'apprécie énormément l'outil graphique (sachant que je fais du bricolage et non de la programmation pro). Donc, je rejoins l'avis d'El Slapper, une fois encore : les deux.

Cela peut-être très pratique pour la programmation de petit automate, mécanique de précision sur machine numérique (tour, fraise, ...) , truc a la con genre la porte du garage de la boite qui reste fermer le 1er mai de chaque année.

Bref je vois l'utilité pour des automates programmables (une formation et tu peut être utile) mais pas pour LA programmation a part pour l'enseigner évidemment.

Scratch me parait très adapté à l'apprentissage. Mais Scratch, même s'il est graphique ne cache pas vraiment la complexité du code. Il fais plus de la décomposition. Le code reste sous forme textuel. Il évite surtout la "syntaxe error" ou l'oublie basic.
Le problème de fond de la pluspart des languages graphique autrement est que le code produit est généralement ignoble et qu'il ne permettent pas de tout bien faire (Je pense à WinDev). Autrement dis on a une IHM graphique joli qui permet de faire la partie visualisation très facilement et assez proprement... Mais dès que l'on veux peaufiner un peu le programme, optimiser les choses ou faire des choses un peu avancer, il faut se plonger dans le code générer et là c'est très galère.
C a réussi à s'imposer face a l'assembleur car il permettait vraiment de se passer d'assembleur (ou alors de l'intégrer dans le code C) tout en produisant quelque chose d'a peu près propre. Et il en est de même pour les autres language (PHP, Python...) qui permettent généralement de s'interfacer facilement avec le C. Si un language graphique (Open-Source de préférence pour une large diffusion) permet de tout faire facilement et que le code généré est a peu près propre et lisible alors il y a de l'avenir.

Des collègues automaticiens utilisent LabView et MathLab/Simulink pour créer des simulateurs permettant tester des automates programmables (simulation des entrées / sorties, ...).
Et c'est assez bien adapté à leurs besoins. Car c'est assez orientés automatisme et électronique (ban de tests, ...), peut être à cause des schémas de câblage et de la programmation LADDER (ou schéma à contacts en français).

Pour ma part, j'ai un peu de mal avec ces langages de programmation. Je trouve ça frustrant (une bonne ligne de code vaut mieux qu'un dessin :mrgreen:), et presque illisible quand il y en a plein l'écran.
Mais c'est surement un conditionnement du à mon métier de développeur en informatique de gestion :)

Tiens personnes ne sembles avoir encore mentionné le "Logo" et sa tortu(r)e ? Moi ça m'a plus à l'époque. Ca restait du code textuel, mais ça me fait penser a ce que certains logiciels avec interface graphique actuels font.

Scratch permet de se concentrer sur la logique d'un programme en éliminant les problèmes liés à la syntaxe. J'ai un peu essayé, le temps de faire un petit pong, et j'ai trouvé ça amusant.
Par contre, ce n'est pas un langage magique et comme n'importe quel autre, il fait ce que vous lui dites, pas ce que vous voulez qu'il fasse pour vous :mouarf: .

Bonjour

Je vais parler de ce que je connais dans mon domaine Bio et chemo informatique. Nous avons également ces 2 modèles.
1) programmation "graphique": connaissez-vous Pipeline Pilot (http://accelrys.com/products/collabo...ipeline-pilot/) ou son pendant libre Knime (https://www.knime.com/). Et bien, ils sont largement utilisés dans le domaine pharma et chimie. Vous pouvez faire ainsi des campagnes de screenings ou des calculs physico chimiques très évolués avec ces outils. L'avantage est de pouvoir obtenir des interfaces web ou des web services également. MAIS (il en faut bien un), cela se fait évidemment au detriment de la flexibilité et si un composant n'est pas present, vous devrez le faire vous meme avec les API existantes
2) programmation "classique": vous aurez recours à des librairies tierces. Les Perl monks du forum verront notamment BioPerl (https://bioperl.org/INSTALL.html), les statisticiens R pour les DNA chips auront Bioconductor (https://www.bioconductor.org/) et les chimistes en C# verront Indigo (http://lifescience.opensource.epam.com/indigo/). Le mot ici est "up to you". Vous ferez ce que vous voudrez avec ces libraries. MAIS, à vous de tout faire jusqu'aux unit tests, validation etc, etc.

Des entreprises se spécialisent pour fournir des paquets de fonctionnalités dans le cas 1. Cependant, cela n'égalera jamais la souplesse et 'liberté' que vous aurez dans le 2ème cas.
N'étant pas orthodoxe, je dirais que cela dépendra de la question à répondre. Nous sommes armés pour :-)

@++

Citation:

---

Envoyé par survivals

Faux débat, chaque langage a son usage.

---

tout à fait !

Pour ma part, je vais bientôt m'amuser avec Scratch avec mini moi qui est en CM1 afin d'apprendre en s'amusant et inversement aussi. L'avantage est de faire de l'algo et de la logique visuelle en s'amusant.

Je pense le contraire de l'auteur.
Les langages graphique sont assez évoluées et comme pour l'exemple de Scratch permettent de bien appréhender les algorithmes.
J'utilise Matlab Simulink pour créer des applications d'électronique embarquées (prof.).
Ce langage est bien plus facile à lire et à écrire que du texte.
Le code généré est performant et très bon (certifié aux normes de sécurité Aéronautiques).
Donc dans mon expérience, on peut faire des choses très pointues et de meilleurs qualité qu'en écrivant du texte avec ces outils.

Je ne suis pas objectif vis à vis des ces trucs visuels, et pour cause ;P
Je suis pour les deux, car sinon je suis exclu.

On m'a fait une bonne blague une fois
On a voulu me coller sur une mission RPA(Robot process automation), on n'en a pas encore parlé directement.
C'est très à la mode chez les banques et les assureurs
J'ai fait remarqué que cela allait être problématique.
Car je ne peux pas utiliser le drag and drop

J'arrive à faire quand même des diagrammes avec des magnettes velleda découpés.
Cela me permet d'échanger avec les autres développeurs ou non développeurs

Un diagramme est plus parlant pour les client en général.
J'ai appris les organigrammes ou ordinogrammes à mes débuts avec le basic au débuts des années 90

Ce serai pratique de générer des diagrammes depuis le code avec des metas informations ou les commentaires ou le nom des fonctions.
On pourrait s'appuyer sur les branchements.
Cela pourrait donner une idée aux client, si le diagramme généré est pas trop moche

Doit-on, pour ces langages, parler de programmation ou de configuration ? Ces langages sont, généralement particulièrement orienté vers un secteur particulier (Industrie, formation...)
Ils répondent à un besoin, et sont surtout connus par beaucoup de professionnels qui ne sont pas formés aux autres langages.

Concernant les langages d'automatisme, ils sont, de plus, accompagnés par une ribambelle d'outils de compréhension, de simplifications et d'optimisation.

Si les langages visuels permettent à certains, d’affûter leur logique sans le côté syntaxique, pourquoi s'en priver....

Comme d'autres plus haut, je dirais que les deux types de langages de programmation, visuelle et bien sûr "textuelle", sont utiles.

Dans le cas du Ladder, je l'ai utilisé en complément du GRAFCET. Le second permet de définir l'enchaînement des opérations et le Ladder permet de définir les lectures de capteurs simples et de commander les actions en "logique câblée", proche des schémas électriques. Ces langages permettent aux automaticiens/développeurs et aux électriciens de mieux communiquer et comprendre le fonctionnement des systèmes automatisés.

Il y a aussi les outils comme Talend qui génèrent du code d'après une description graphique des traitements souhaités. Mais globalement, le développement de type MDA (Model-Driven Architecture), censé générer du code à partir de diagrammes UML, a-t-il percé ? Je n'en entends plus parler. La mode serait-elle passée ?

Citation:

---

Envoyé par nuke_y

Au début j'avais pensé à des programmes tels que Scratch pour faire découvrir la programmation à mes enfants mais finalement j'ai préféré ne pas le faire.

---

Moi c'est mon fils 11 ans qui m'a fait découvrir ce site https://studio.code.org/courses c'est du scratch like (mais on peut voir le code généré en javascript).
Ils se sont bien amusé avec sa soeur pendant quelques heures le temps d'un week-end puis ayant fini tous les niveaux ils sont retournés jouer au LEGO.
Mais c'était un jeu de "casse tête" pour eux.
Ils n'ont pas compris qu'ils faisaient de la programmation.

Mais moi je me suis dit que c'était bien qu'ils mettent un pied dedans sous forme de jeu.

Personnellement, je n'utilise que la programmation visuelle. Sans nul doute pour éviter d'apprendre à exprimer sans erreur de syntaxe (dépendant du langage, évidemment) une chose que je sais parfaitement vouloir obtenir. Concentré sur l'aspect créatif, je conçois une logique, et demeure focalisé sur le résultat final (gameplay, graphismes et sons) sans redouter une inversion d'entrée de données, ou l'oubli d'une parenthèse (par exemple). Lorsque l'outil est très bien pensé, comme c'est le cas pour Clickteam Fusion par exemple, la limitation des possibilités ne dépend que de la limitation du concepteur (un peu comme en programmation textuelle). Loin d'un Scratch ou autre logiciel essentiellement dédié à l'éveil en programmation, Fusion m'a permis déjà de réaliser de nombreux petits jeux présentables pour des gamejams, et je doute pas qu'il est possible d'en faire de vrais jeux pros en insistant un peu. Seule la 3D demeure en reste sur Fusion, mais pour la 2D, pour rien au monde je me passerai de cet outil de programmation visuelle qui a déjà tellement fait ses preuves pour moi, au profit de langages spécifiques qui me prendraient un temps fou pour les apprendre et obtenir malgré tout tellement moins bien à la fin.

C'est marrant comme rapidement on retrouve une critique de WinDev :) .. pourquoi ne pas critiquer "VISUAL" studio qui comme son nom l'indique permet de faire une partie de la programmation de l'IHM et des évènements tournant autour en mode graphique.
On ne parle pas de la même chose avec scratch qui pour moi me fait penser à ce qui est proposé pour programmer les briques lego Mindstorm.
les anglais se posent moins de questions avec les micros cartes proposées avec la BBC et là aussi une programmation en mode graphique.
Enfin bref.