Strumenti di programmazione visiva, perché non funzionano direttamente con lAST?

Molti di questi strumenti do funzionano direttamente con lalbero della sintassi astratto (o meglio, un -una visualizzazione di esso). Ciò include Blockly, che hai visto, e altri linguaggi basati su blocchi ed editor simili ( Scratch , Pencil Code / Droplet , Snap! , GP , Tiled Grace e così via).

Quei sistemi non “t mostrano una rappresentazione grafica tradizionale di vertici e spigoli, per ragioni spiegate altrove (spazio e anche difficoltà di interazione), ma rappresentano direttamente un albero. Un nodo, o blocco, è figlio di un altro se si trova direttamente, fisicamente allinterno del genitore.

Ho costruito uno di questi sistemi ( Tiled Grace , paper , paper ). Posso assicurarti che sta lavorando molto direttamente con lAST: ciò che vedi sullo schermo è una rappresentazione esatta dellalbero della sintassi, come elementi DOM annidati (quindi, un albero!).

Questo è lAST di un codice. La radice è un nodo di chiamata al metodo “for … do”. Quel nodo ha alcuni figli, che iniziano con “_ .. _”, che ha due figli, un nodo “1” e un nodo “10”. Ciò che appare sullo schermo è esattamente ciò che il backend del compilatore sputa nel mezzo del processo: è fondamentalmente così che funziona il sistema.

Se vuoi, puoi pensarlo come un layout ad albero standard con i bordi che puntano fuori dallo schermo verso di te (e occlusi dal blocco di fronte a loro), ma lannidamento è un modo valido per mostrare un albero come un diagramma dei vertici.

Lo farà anche ” il viaggio di andata e ritorno dalla sorgente al grafico del nodo e poi di nuovo alla sorgente quando necessario “. In effetti, puoi vedere che accade quando fai clic su” Vista codice “in basso. Se modifichi il testo, verrà re- analizzato e lalbero risultante renderizzato affinché tu possa modificare di nuovo, e se modifichi i blocchi, la stessa cosa accade con il sorgente.

Pencil Code fa essenzialmente la stessa cosa con, a questo punto, uninterfaccia migliore . I blocchi che utilizza sono una visualizzazione grafica di CoffeeScript AST.Così fanno gli altri sistemi basati su blocchi o tessere, in generale, anche se alcuni di essi non rendono laspetto della nidificazione altrettanto chiaro nella rappresentazione visiva, e molti non hanno un vero linguaggio testuale dietro di loro, quindi il ” albero della sintassi “può essere un po illusorio, ma il principio è lì.

Quello che ti” manca, quindi, è che questi sistemi stanno lavorando direttamente con il albero di sintassi astratto. Ciò che vedi e manipoli è un rendering efficiente in termini di spazio di un albero, in molti casi letteralmente lAST prodotto da un compilatore o parser.

Almeno due ragioni:

1. Perché il codice sorgente è una rappresentazione molto più concisa. Disposizione di un AST come grafico occuperebbe molto più spazio visivo.

   I programmatori apprezzano avere più contesto possibile, ovvero avere più codice presente tutto in una volta sullo schermo allo stesso tempo. Il contesto li aiuta a gestire meglio complessità. (Questo è uno dei motivi per cui molti progr ammers usa questi piccoli caratteri folli ed enormi schermi da 30 pollici.)

   Se provassimo a visualizzare lAST come un grafico o un albero, la quantità di codice che potresti inserire su un singolo schermo sarebbe molto inferiore rispetto a quando è rappresentato come codice sorgente. Questa è unenorme perdita per la produttività degli sviluppatori.

2. Gli AST sono intesi per la programmazione di compilatori, non per una facile comprensione da parte dei programmatori. Se prendessi una rappresentazione AST esistente e la mostrassi visivamente, probabilmente sarebbe più difficile da capire per gli sviluppatori, perché gli AST non sono stati progettati per essere facili da imparare per gli sviluppatori.

   Al contrario, il codice sorgente di solito è progettato per essere leggibile / comprensibile dagli sviluppatori; questo è normalmente un criterio di progettazione critico per il codice sorgente, ma non per gli AST. Gli AST devono essere compresi solo dagli autori del compilatore, non dagli sviluppatori di tutti i giorni.

   E, in ogni caso, la lingua AST sarebbe una seconda lingua che gli sviluppatori dovrebbero imparare, oltre alla lingua di partenza. Non una vittoria.

Vedi anche https://softwareengineering.stackexchange.com/q/119463/34181 per alcuni potenziali motivi aggiuntivi.

Commenti

• ” Al contrario, il codice sorgente è progettato per essere leggibile / comprensibile dagli sviluppatori ” – controesempio: la maggior parte degli esolang, Perl, Lisp
• ” Becaus Il codice sorgente è una rappresentazione molto più concisa. “; ” la lingua AST sarebbe una seconda lingua che gli sviluppatori devono imparare, oltre alla lingua di origine ” – questi sono argomenti contro tutti i PL visivi ma non aiuta a spiegare la distinzione di cui è preoccupato lOP.
• ” (che ‘ è uno dei motivi per cui molti programmatori utilizzano questi folli caratteri piccoli e 30 ” schermate.) ” – se hai bisogno di uno schermo grande per visualizzare un contesto sufficiente, forse ‘ stai codificando gli spaghetti? 😉
• @Raphael Forse, ma ‘ è meno faticoso spendere soldi che refactoring!
• @JanDvorak, .. .LISP è un controesempio perché lAST è il linguaggio – che è ciò che gli conferisce il suo potere espressivo; scrivere codice LISP che ricompili laltro codice LISP è facile come scrivere codice che modifica strutture dati LISP standard … che sono esattamente ciò in cui è scritto il codice LISP . ‘ una ragione per cui ‘ è durato più di mezzo secolo: la famiglia ‘ Il design è insolitamente espressivo. Go doveva far penetrare le sue estensioni asincrone in profondità nella lingua e nel runtime; per Clojure, è ‘ solo una libreria. Vedi anche: Battendo le medie .

Il tipico AST dei compilatori è piuttosto complesso e dettagliato. La rappresentazione grafica diretta diventerebbe rapidamente piuttosto difficile da seguire. Ma ci sono due grandi aree di CS in cui vengono utilizzati gli AST.

1. I linguaggi Lisp sono effettivamente scritti come AST. Il codice sorgente del programma viene scritto come elenchi e utilizzato direttamente dal compilatore e / o dallinterprete (a seconda della variante utilizzata).
2. Linguaggi di modellazione, ad es. UML e molti linguaggi specifici del dominio visivo utilizzano notazioni grafiche che sono grafici di sintassi astratti (ASG) efficaci a un livello di astrazione più elevato rispetto al tipico linguaggio generico AST.