IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

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

Le , par Patrick Ruiz

391PARTAGES

19  0 
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.


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.


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 ?

Qu’en pensez-vous ?

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 :

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

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

Une erreur dans cette actualité ? Signalez-nous-la !

Avatar de Guntha
Membre expérimenté https://www.developpez.com
Le 02/10/2018 à 15:50
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...
5  0 
Avatar de el_slapper
Expert éminent sénior https://www.developpez.com
Le 02/10/2018 à 15:51
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.
5  0 
Avatar de nuke_y
Membre émérite https://www.developpez.com
Le 02/10/2018 à 17:04
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
6  1 
Avatar de CoderInTheDark
Membre émérite https://www.developpez.com
Le 03/10/2018 à 13:28
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
3  0 
Avatar de pboulanger
Membre éprouvé https://www.developpez.com
Le 02/10/2018 à 16:13
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 ;-)
2  0 
Avatar de
https://www.developpez.com
Le 02/10/2018 à 17:19
Citation Envoyé par nuke_y Voir le message

  • 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.
2  0 
Avatar de _champy_
Membre régulier https://www.developpez.com
Le 02/10/2018 à 17:22
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.
2  0 
Avatar de
https://www.developpez.com
Le 02/10/2018 à 20:55
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 .
2  0 
Avatar de Cincinnatus
Membre expérimenté https://www.developpez.com
Le 04/10/2018 à 10:31
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 ?
2  0 
Avatar de abriotde
Membre chevronné https://www.developpez.com
Le 02/10/2018 à 17:44
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.
1  0