Outils de programmation visuelle, pourquoi ne fonctionnent-ils pas directement avec lAST?

Beaucoup de ces outils font fonctionnent directement avec larborescence de syntaxe abstraite (ou plutôt, un one-to -une visualisation de celui-ci). Cela inclut Blockly, que vous avez vu, ainsi que les autres langages et éditeurs basés sur des blocs ( Scratch , Code du crayon / Droplet , Snap! , GP , Tiled Grace , et ainsi de suite).

Ces systèmes ne « t montrent une représentation graphique traditionnelle des sommets et des arêtes, pour des raisons expliquées ailleurs (espace, et aussi difficulté dinteraction), mais ils représentent directement un arbre. Un nœud, ou bloc, est un enfant dun autre sil est directement, physiquement à lintérieur du parent.

Jai construit lun de ces systèmes ( Tiled Grace , papier , papier ). Je peux vous assurer que cela fonctionne directement avec lAST: ce que vous voyez à lécran est une représentation exacte de larbre de syntaxe, sous forme déléments DOM imbriqués (donc, un arbre!).

Ceci est lAST dun code. La racine est un nœud dappel de méthode « for … do ». Ce nœud a des enfants, commençant par « _ .. _ », qui lui-même a deux enfants, un nœud « 1 » et un nœud « 10 ». Ce qui apparaît à lécran, cest exactement ce que le backend du compilateur crache au milieu du processus – cest fondamentalement comment le système fonctionne.

Si vous le souhaitez, vous pouvez le considérer comme une arborescence standard avec les bords pointant hors de lécran vers vous (et occlus par le bloc en face deux), mais limbrication est une manière aussi valable de montrer un arbre quun diagramme de sommets.

Cela va aussi « faire laller-retour de la source au graphe de nœuds, puis de nouveau à la source si nécessaire « . En fait, vous pouvez voir que cela se produit lorsque vous cliquez sur » Affichage du code « en bas. Si vous modifiez le texte, il » sera re analysé et larbre résultant rendu pour que vous puissiez le modifier à nouveau, et si vous modifiez les blocs, la même chose se produit avec la source.

Pencil Code fait essentiellement la même chose avec, à ce stade, une meilleure interface . Les blocs quil utilise sont une vue graphique de CoffeeScript AST.Tout comme les autres systèmes basés sur des blocs ou des tuiles, dans lensemble, bien que certains dentre eux ne rendent pas laspect dimbrication tout aussi clair dans la représentation visuelle, et beaucoup nont pas de langage textuel réel derrière eux. larbre de syntaxe « peut être un peu illusoire, mais le principe est là.

Ce quil vous manque, cest que ces systèmes fonctionnent directement avec le arbre de syntaxe abstraite. Ce que vous voyez et manipulez est un rendu efficace de lespace dun arbre, dans de nombreux cas littéralement lAST quun compilateur ou un analyseur produit.

Au moins deux raisons:

1. Parce que le code source est une représentation beaucoup plus concise. Disposer un AST sous forme de graphique prendrait beaucoup plus despace visuel.

   Les programmeurs apprécient davoir autant de contexte que possible – cest-à-dire davoir autant de code présent en même temps sur lécran en même temps. Le contexte les aide à mieux gérer complexité. (Cest une des raisons pour lesquelles de nombreux progr les ampères utilisent ces petites polices folles et ces énormes écrans de 30 pouces.)

   Si nous essayions dafficher lAST sous forme de graphique ou darbre, alors la quantité de code que vous pourriez insérer sur un seul écran serait bien moindre que lorsquil est représenté sous forme de code source. Cest une énorme perte pour la productivité des développeurs.

2. Les AST sont destinés à la programmation de compilateurs, pas à une compréhension facile par les programmeurs. Si vous prenez une représentation AST existante et laffichez visuellement, ce serait probablement plus difficile à comprendre pour les développeurs, car les AST nont pas été conçus pour être faciles à apprendre pour les développeurs.

   En revanche, le code source est généralement est conçu pour être lisible / compréhensible par les développeurs; cest normalement un critère de conception critique pour le code source, mais pas pour les AST. Les AST ne doivent être compris que par les rédacteurs du compilateur, pas par les développeurs ordinaires.

   Et, dans tous les cas, le langage AST serait une deuxième langue que les développeurs doivent apprendre, en plus de la langue source. Ce nest pas une victoire.

Voir aussi https://softwareengineering.stackexchange.com/q/119463/34181 pour dautres raisons potentielles.

Commentaires

•  » En revanche, le code source est conçu pour être lisible / compréhensible par les développeurs  » – contre-exemple: la plupart des esolangs, Perl, Lisp
•  » Becaus Le code source est une représentation beaucoup plus concise. « ;  » la langue AST serait une deuxième langue que les développeurs doivent apprendre, en plus de la langue source  » – ce sont des arguments contre tous les PL visuels mais ne permet pas dexpliquer la distinction qui préoccupe lOP.
•  » (Cela ‘ est lune des raisons pour lesquelles de nombreux programmeurs utilisent ces petites polices folles et ces 30 écrans « .)  » – si vous avez besoin dun grand écran pour afficher suffisamment de contexte, peut-être ‘ êtes-vous en train de coder des spaghettis? 😉
• @Raphael Peut-être, mais ‘ fait moins defforts pour y jeter de largent que de refactoriser!
• @JanDvorak, .. .LISP est un contre-exemple car lAST est le langage – cest ce qui lui donne son pouvoir expressif; écrire du code LISP qui recompile votre autre code LISP est aussi simple que décrire du code qui modifie les structures de données LISP standard … qui sont exactement ce que le code LISP est écrit . ‘ une raison pour laquelle cela ‘ a duré plus dun demi-siècle – la famille ‘ La conception de s est rarement expressive. Go devait avoir ses extensions asynchrones profondément intégrées au langage et à lexécution; pour Clojure, ‘ nest quune bibliothèque. Voir aussi: Battre les moyennes .

LAST typique des compilateurs est assez complexe et verbeuse. La représentation graphique dirigée deviendrait rapidement assez difficile à suivre. Mais il y a deux grands domaines de CS où les AST sont utilisés.

1. Les langages Lisp sont en fait écrits comme AST. Le code source du programme est écrit sous forme de listes et directement utilisé par le compilateur et / ou linterpréteur (selon la variante utilisée).
2. Langages de modélisation, par ex. UML et de nombreux langages spécifiques au domaine visuel utilisent des notations graphiques qui sont des graphes de syntaxe abstraite (ASG) efficaces à un niveau dabstraction plus élevé que le langage à usage général typique AST.