La plupart d'entre nous ont appris la programmation à l'aide de langages de programmation "textuels" tels que Basic, C / C ++ et Java. Je crois qu'il est plus naturel et efficace pour les humains de penser visuellement. La programmation visuelle permet aux développeurs d’écrire des programmes en manipulant des éléments graphiques. J'imagine que l'utilisation de la programmation visuelle devrait améliorer la qualité du code et réduire les erreurs de programmation. Je connais quelques langages visuels tels que App Inventor , Scratch et LabView .
Pourquoi n'y a-t-il pas de langage visuel général à usage général pour les développeurs? Quels sont les avantages et les inconvénients de la programmation visuelle?
programming-languages
Mohammad Al-Turkistany
la source
la source
Réponses:
En général, la conception du langage de programmation présente un compromis entre facilité d'utilisation et expressivité (puissance). Écrire un programme simple "Hello, world" dans un langage débutant, tel que Scratch ou App Inventor, est généralement plus facile que de l'écrire dans un langage de programmation général tel que Java ou C ++, où vous pouvez choisir entre plusieurs flux: sortie vers, différents jeux de caractères, la possibilité de modifier la syntaxe, les types dynamiques, etc.
Lors de la création d'App Inventor (dont je faisais partie), notre philosophie de conception était de simplifier la programmation pour les débutants. Un exemple trivial consistait à baser les indices de nos tableaux à 1 plutôt qu'à 0, même si cela rend les calculs susceptibles d'être effectués par des programmeurs avancés légèrement plus complexes.
Cependant, les langages de programmation visuels ont tendance à être conçus pour les débutants en éliminant la possibilité d'erreurs de syntaxe en rendant impossible la création de programmes syntaxiquement invalides. Par exemple, les langages de blocage ne vous permettent pas de définir la valeur de destination d'une instruction d'affectation. Cette philosophie tend à produire des grammaires et des langues plus simples.
Lorsque les utilisateurs commencent à créer des programmes plus complexes dans un langage de blocs, ils s'aperçoivent que le glisser-déposer de blocs est plus lent que la saisie. Souhaitez-vous plutôt taper "a * x ^ 2 + b * x + c" ou le créer avec des blocs?
La justice ne peut pas être rendue sur ce sujet (du moins par moi) dans quelques paragraphes, mais certaines des raisons principales sont:
la source
Les langages visuels ont tendance à diviser en trois grandes catégories:
L'avantage de la programmation visuelle est que vous obtenez une vue d'ensemble de haut niveau de la structure du système. Cela pose le problème immédiat suivant: lorsque vous obtenez des détails, votre code de spaghetti ressemble vraiment à un spaghetti . Un composant commun des langages visuels est une sorte de bloc de code ou de composant de configuration pour l'élément visuel. Le problème est que le programmeur doit comprendre les blocs de code déconnectés qui peuvent être liés de manière étrange.
Bien qu'il n'y ait rien de mal avec la programmation visuelle, il se peut que ce ne soit tout simplement pas une bonne approche pour la plupart des tâches.
la source
Il existe de nombreux langages de programmation visuels, comme le montrent les deux bibliographies suivantes: vlib.org et oregonstate.edu .
À mon humble avis, ils n'ont pas réussi à gagner du terrain, car s'ils sont bons pour des exemples de jouets, ils ne parviennent pas à gérer les multiples niveaux d'abstraction, de représentation et de granularité requis par les grands projets. Vous devez examiner un système tel qu'AutoDesk Revit (un système de gestion des informations sur le bâtiment utilisé par les architectes et les ingénieurs) pour comprendre à quel point la gestion des informations visuelles peut devenir complexe.
Plutôt que de regarder la programmation générale, la programmation visuelle a plus de chances de réussir en tant qu'outil de configuration dans des domaines spécialisés.
la source
Le texte est visuel.
Nous utilisons toutes sortes de repères visuels dans notre code. Chaque utilisation d’espace (espaces, nouvelles lignes, lignes vides, espacement intralin) vise à fournir des repères visuels sur la fonctionnalité du code. Nous utilisons toutes sortes de syntaxes différentes pour fournir des informations visuelles sur ce que fait le code. Nos éditeurs colorient notre code pour le faire ressortir.
Les mathématiques sont textuelles. Il y a toutes sortes de notations, mais au final, il s'agit essentiellement de texte. Ils le font depuis des centaines d'années.
Mon point: la représentation textuelle du code exploite les capacités visuelles des humains. Nous pouvons probablement en faire un meilleur usage, mais pas en abandonnant le texte.
la source
[Pour la version PDF de cette réponse , les figures ou les diagrammes sont interactifs et dynamiques.]
Éléments nets et annotations: langage de programmation visuel polyvalent
J'utilise des graphiques pour organiser les programmes JavaScript ™ utilisant l'API Acrobat® / JavaScript. Chaque objet graphique représente un élément du réseau de Petri (lieu, transition, entrée ou sortie) ou représente plusieurs éléments du réseau de Petri. Chaque objet graphique est en fait une annotation de l'élément net correspondant. Cependant, si chaque objet graphique correspond à un et un seul élément net, il peut être utilisé pour générer l'élément net. Et si un objet graphique est mappé sur plusieurs éléments du réseau et que la mise en correspondance est bien définie, il peut également être utilisé pour générer les éléments du réseau. Les éléments standard du réseau de Petri sont représentés par certains types de graphiques: un cercle est un endroit, un carré ou un rectangle ou une ligne est une transition, une flèche d'un cercle à un carré est une entrée et une flèche d'un carré à un cercle est une sortie. En outre,
[Les types d'annotations dans un "réseau de Petri standard" figurent dans la version PDF de cette réponse.]
Carl Adam Petri a décrit la plupart de ces idées (y compris les types d'annotations dans un "réseau de Petri standard" dans sa thèse de doctorat (Petri, 1966). Il a également appliqué les éléments de réseau et les annotations à la description de plusieurs circuits logiques, tels que la Figure 6
Avantages et défis
Un langage de programmation visuel peut aider un programmeur informatique à développer des programmes informatiques (Menzies, 2002).
J'ai au moins trois raisons pour lesquelles je trouve les éléments nets et les annotations utiles (avantages?).
Première raison. La logique de processus peut être créée un élément à la fois. Cela signifie qu'un réseau peut être étendu en ajoutant des éléments au réseau existant (Petri, 1966). Par exemple, un modèle de contrôleur peut être divisé en composants internes et externes. Le composant interne régule le système. Le composant externe s'interface avec l'environnement en acceptant les entrées de l'environnement. La figure 1 est un modèle de Petri Net du composant interne. Il est possible d'ajouter un modèle Net du réseau de Petri du composant externe au modèle Net du réseau de Petri en ajoutant les emplacements et la transition appropriés (Figure 2).
Figure 1 Modèle de réseau de Petri d'une composante interne d'un contrôleur (Halloway, Krogh et Giua, 1997)
Figure 2 Modèle de réseau de Petri des composants internes et externes d'un contrôleur (Halloway, Krogh et Giua, 1997)
Deuxième raison. Les codes associés à chaque élément du réseau peuvent provenir de plus d’un «langage de programmation» (Petri, 1973). Ils peuvent provenir d'un langage informatique tel que JavaScript, COBOL, ADA et d'un langage d'assemblage. Ils peuvent provenir d'un langage mathématique tel que les symboles algébriques. Ils peuvent provenir de textes codés en anglais, allemand, français, grec, tagalog, chinois, etc. Ils peuvent donc servir de base à la communication et à la collaboration tout au long du cycle de vie du développement du logiciel ou du système; et parmi différents utilisateurs, développeurs et parties prenantes (Petri, 1973).
Troisième raison. Il est possible de se concentrer sur certains objets graphiques du réseau et d’écrire le code ou les annotations logiques des objets graphiques associés. Prenons un modèle de Petri Net d’un jeu de cartes illustré à la figure 3. Si la flèche pour l’entrée P7 T4 est un graphique standard pour une entrée dans un lieu / réseau de transition et si m_7 est le repère de l’emplacement P7, alors l’annotation logique pour la mise à jour de la marque du lieu d'entrée est m_7 = m_7-1. Si s_9 ^ - est le statut de l'entrée, l'annotation logique permettant de mettre à jour le statut de l'entrée est s_9 ^ - = ((m_7 <1)? False: vrai).
Figure 3 Un modèle de jeu de cartes Net Petri
J'ai au moins trois raisons pour lesquelles je trouve l'application des réseaux de Petri difficile (inconvénients?)
S'il y a trop d'objets graphiques, il sera difficile de créer ou de lire le net. La difficulté peut être atténuée en prenant un sous-ensemble des graphiques et en les représentant en utilisant un, deux ou trois symboles graphiques (Noe, 1973; Petri, 1966). Par exemple, si le modèle de jeu de cartes Petri Net de la figure 3 est considéré comme comportant trop d'objets graphiques dans le diagramme, il est possible de combiner une partie des graphiques tout en conservant suffisamment d'informations pour que le diagramme puisse être mappé dans un programme informatique. Prenons l'exemple de la figure 4, un modèle de Petri Net du même jeu que celui de la figure 3 avec des graphiques de haut niveau (Chionglo, 2016a).
Figure 4 Modèle de réseau de Petri d'un jeu de cartes utilisant des graphiques de haut niveau (Chionglo, 2016a)
Dans un autre exemple, les composants externes du contrôleur de la figure 2 peuvent être combinés pour créer une représentation graphique plus concise, comme illustré à la figure 5.
Figure 5 Modèle de réseau de Petri d'un contrôleur avec graphiques de haut niveau pour composants externes
Enfin, un ensemble de lieux mutuellement exclusifs ou un ensemble de transitions mutuellement exclusifs peut également être représenté à l'aide d'un objet graphique de haut niveau (Chionglo, 2015).
Deuxième raison. Même avec des graphiques standard, il peut être difficile de dessiner et de positionner des graphiques, en particulier si l'on s'attend à ce que le diagramme final soit convivial ou lisible. Parmi les décisions à prendre pour créer un diagramme convivial pour l'utilisateur ou le lecteur, citons: la disposition correcte des objets graphiques, les dimensions appropriées du canevas et des formes, la courbure des flèches, le type de têtes de flèches, la taille et la police du texte, et le choix des couleurs pour les graphiques et le texte.
Troisième raison. Il est facile de créer des annotations d’éléments du réseau de manière ordonnée car chaque annotation est directement ou indirectement liée à un élément du réseau. Cependant, l'affichage de chaque annotation avec les graphiques de chaque élément de réseau peut ne pas être une bonne idée car il pourrait y avoir trop d'informations présentées dans le diagramme. Par exemple, considérons le schéma d’un modèle de réseau de Petri d’un circuit logique incluant des références à toutes les annotations de propriété et de logique (Figure 6). [Le modèle d'origine incluait une condition de test pour le statut de pour chaque sortie (figure 31, page 78 de (Petri, 1966)); la condition de test a été omise ici car elle est équivalente au modèle d'origine pour le marquage initial donné. Ainsi, chaque sortie a une annotation logique pour calculer la marque de la place de sortie.]
Figure 6 Un lieu / réseau de transition avec annotations - basé sur la figure 31, page 78 d'une traduction anglaise de la thèse de Petri (1966)
Une façon de résoudre ce problème serait d'identifier les types d'annotations utilisés dans le modèle et de définir des objets graphiques qui incluent des annotations de ce type (Petri, 1966). Ainsi, lorsqu'un diagramme de Petri Net est composé d'objets graphiques issus des définitions, l'interprétation de ces objets doit inclure les annotations «invisibles». La Figure 7 doit être interprétée comme un réseau de Petri standard (voir les annotations d'un réseau de Petri standard pour les définitions); par conséquent, l'annotation logique peut être omise du diagramme.
Figure 7 Un lieu / réseau de transition - d'après la figure 31, page 78 d'une traduction anglaise de la thèse de Petri (1966)
Un autre moyen d'atténuer ce problème serait d'utiliser des vues de formulaire des annotations pour compléter ou compléter le (s) diagramme (s) (Chionglo, 2016b; 2014). Les vues peuvent être divisées en vues plus petites et chaque vue peut être affichée et masquée.
Les références
Chionglo, JF (2016a). Une réponse à “Comment concevoir un flux d’états pour un jeu de cartes flash réactif / redux?” Dans Stack Overflow. Disponible à l' adresse https://www.academia.edu/34059934/A_Reply_to_How_to_design_a_state_flow_for_a_react_redux_flashcard_game_at_Stack_Overflow .
Chionglo, JF (2016b). Deux vues de formulaire d'un réseau de Petri. Disponible à http://www.aespen.ca/AEnswers/CAPDissF31P78-form.pdf .
Chionglo, JF (2015). Réduire le nombre de graphiques d'éléments nets dans un diagramme de Petri Net à l'aide de graphiques de haut niveau. Disponible à http://www.aespen.ca/AEnswers/WjTpY1429533268 .
Chionglo, JF (2014). Éléments nets et annotations pour la programmation informatique: calculs et interactions en PDF. Disponible à l' adresse https://www.academia.edu/26906314/Net_Elements_and_Annotations_for_Computer_Programming_Computations_and_Interactions_in_PDF .
Halloway, LE; Krogh, BH et Giua, A. (1997). Enquête sur les méthodes de Petri Net pour les systèmes à événements discrets contrôlés [version électronique]. Systèmes dynamiques à événements discrets: théorie et applications, vol. 7. Boston: Kluwer Academic Publishers, p. 151 - 190.
Menzies, T. (2002). Problèmes d'évaluation pour les langages de programmation visuels. Dans SK Chang (Ed). Manuel de génie logiciel et d'ingénierie du savoir, vol. 2 Technologies émergentes. World Scientific Publishing co. Pte. Ltd., p. 93 - 101.
Noe, JD et Nutt, GJ (1973). «Macro E-Nets pour la représentation de systèmes parallèles», IEEE Transactions on Computers, vol. C-22, n ° 8, août 1973, p. 718 - 727.
Petri, CA (1973). Concepts de la théorie du réseau. Dans les fondements mathématiques de l'informatique: Proc. du symposium et des cours d’été, Hautes Tatras, du 3 au 8 septembre 1973, pages 137 à 146. Math. Inst. de la Slovaque Acad. des sciences, 1973.
Petri, CA (1966). Communication avec Automota [trans. CF Greene, Jr.]. Supplément I au rapport technique RADC-TR-65-377 (volume I). Base aérienne Griffiss, NY: Centre de développement aérien de Rome, Division de la recherche et de la technologie, Commandement des systèmes de la Force aérienne, Base aérienne de Griffiss. Extrait le 31 août 2011 sur http://www.informatik.uni-hamburg.de/TGI/mitarbeiter/profs/petri/doc/Petri-diss-engl.pdf .
la source
Johne Percival Hackworth :
Peut-être que les langages de programmation visuels sont à ce jour trop immatures? La notion selon laquelle les visualisations avancées ne peuvent pas être appliquées à des artefacts logiciels et qu’ils sont laissés entièrement à «l’imagination» de chaque développeur pour lancer leurs propres idées pourrait être une fausse hypothèse. Augmenter le niveau d'abstraction de manière uniforme et automatisée semble évident, aussi longtemps que la capacité d'effectuer des abstractions de bas niveau et des performances d'exécution élevées n'est pas sacrifiée. Cela pourrait en fin de compte conduire à une "programmation" d'experts en domaines, pas très différente de la manière dont les tableurs automatisaient la tâche des programmeurs COBOL pour manipuler les nombres. La principale différence ici consiste à remplacer les chiffres par la manipulation de «systèmes généraux».
la source
Vous pouvez regarder Programmation sans technologie de codage (PWCT)
PWCT est un langage de programmation visuel à usage général qui permet le développement de systèmes et d'applications en générant des étapes interactives au lieu d'écrire du code.
Voici un bon endroit pour commencer et est open source .
la source
une question délicate. la programmation visuelle ou basée sur les flux est certes de plus en plus utilisée, mais elle n’est pas largement utilisée par rapport à tous les langages de programmation. les facteurs importants sont la maintenance et la normalisation. Le code informatique peut être imprimé sur les pages. comment imprimer un programme visuel n’est pas toujours aussi clair.
Contrairement à la réponse actuelle, je dirais qu’il n’ya absolument aucune limite théorique inhérente au pouvoir de programmation visuelle par rapport aux langages textuels. en fait, la programmation visuelle peut être considérée comme plus facile à gérer un jour, basée sur une conceptualisation humaine plus rapide des nombreuses couches de l' abstraction . il semble donc y avoir un élément indéniable d' inertie sociale / culturelle / conservatisme dans son adoption.
les éditeurs visuels sont probablement beaucoup plus complexes dans leur code, ce qui est formidable étant donné que même les IDE basés sur du texte peuvent être très complexes, par exemple Eclipse . Notez qu'il existe des plugins orientés programmation visuelle dans certains IDE tels que eciplse, par exemple pour la construction d'interfaces graphiques. la programmation visuelle pour la construction d'interface graphique est maintenant assez répandue.
il me semble que l’utilisation de la programmation visuelle augmente dans certaines régions et qu’elle risque de devenir plus courante dans beaucoup de temps.
N'oublions pas que la programmation visuelle est inhérente à la conception de puces EE depuis des décennies, lorsqu'il ne s'agit pas d'une abstraction et que les (sous) systèmes sont disposés en conceptions 2D exactement comme prévu.
le kit Lego mindstorms , maintenant répandu et vieux de plus de dix ans, a toujours eu un logiciel de développement basé sur la programmation visuelle, maintenant considérablement simplifié dans de nombreuses versions.
Voici un article récent intéressant analysant l’histoire et les perspectives et suggérant qu’il pourrait devenir plus courant pour la programmation Web. La disposition dynamique de contrôles / widgets sur une page est une variante de la programmation visuelle.
Un autre domaine clé / émergent où il est largement utilisé dans de nombreux outils est le BPM, la modélisation des processus métiers.
Comment une méthode de codage arcanique du logiciel bancaire des années 1970 pourrait sauver la santé mentale des développeurs Web partout (Fast Company)
BPM, modélisation de processus d'entreprise wikipedia
la source
Je suppose que la raison pour laquelle ces solutions ne sont pas si populaires, parce que dans la plupart des cas, elles peuvent être ingérables et devenir un gâchis.
Presque tous les outils de programmation visuels disponibles aujourd'hui font partie d'applications plus grandes et sont utilisés dans un but spécifique (ex: Blueprint in UE4).
Quoi qu'il en soit, le nouveau Korduene que j'ai rencontré récemment pour la programmation générale est Korduene, ce qui n'est vraiment pas un objectif général, il s'agit plutôt de créer des applications Windows.
la source
Je pense que @Raphael et les autres ont tort quand ils disent qu'un programme est un texte. Ce n'est pas. C'est beaucoup de choses. Cela dit à l'ordinateur quoi faire ou comment le faire. (programmation imperative et déclarative) L'association de la programmation à l'édition de texte est un dogme historique et contre-intuitif. Qui a été créé par les entrées / sorties textuelles limitées des premiers ordinateurs. Les gens ne sont pas des analyseurs de texte!
Bien que je pense que les gens ont raison de dire qu’un langage entièrement visuel (où vous faites quelque chose de visuel, en connectant des éléments via une souris, etc.) est impraticable pour un langage à usage général, je pense que tous les langages actuels pourraient être et devraient être déplacés vers un langage intermédiaire. niveau. Où les éléments de langage ont une représentation visuelle, qui est enregistrée dans un fichier de langage binaire. Le programmeur ne taperait pas le texte comme un fou, ou ne vivrait pas sous le charme des lignes et de l’indentation.
Mais insère des éléments via la combinaison la plus productive de raccourcis clavier / commandes / éléments d'interface utilisateur. Et uniquement les types chaînes et autres données et identificateurs. Cela rendrait les erreurs de syntaxe impossibles et rendrait les langues plus productives avec la sécurité et l'exactitude (par exemple: ADA). Et rendrait également les autres plus sûrs et moins bogués, en rendant impossible des classes entières d'erreurs courantes. (Comme ceux que l'ADA empêche en étant encombrants)
Dans une certaine mesure, les choses se passaient ainsi. Par indentation automatique et coloration de la syntaxe. Malheureusement, personne ne s'est rendu compte (ou ne s'en est assez préoccupé) que c'est le concept fondamental de "l'analyseur de texte humain". Les arguments emacs vs vim sont drôles car les deux ont tort. Ce sont des "solutions" à un problème créé artificiellement.
la source