Herramientas de programación visual, ¿por qué no trabajan directamente con el AST?

Muchas de estas herramientas hacen funcionan directamente con el árbol de sintaxis abstracto (o más bien, un directo uno a -una visualización del mismo). Eso incluye Blockly, que has visto, y otros lenguajes basados en bloques y editores similares ( Scratch , Código de lápiz / Droplet , Snap! , GP , Tiled Grace , y así sucesivamente).

Esos sistemas no muestran una representación gráfica de vértice y borde tradicional, por razones explicadas en otro lugar (espacio y también dificultad de interacción), pero representan directamente un árbol. Un nodo, o bloque, es hijo de otro si está directamente, físicamente dentro del padre.

Construí uno de estos sistemas ( Tiled Grace , papel , papel ). Puedo asegurarle que está trabajando mucho con el AST directamente: lo que ve en la pantalla es una representación exacta del árbol de sintaxis, como elementos DOM anidados (¡entonces, un árbol!).

Este es el AST de algún código. La raíz es un nodo de llamada de método «for … do». Ese nodo tiene algunos hijos, comenzando con «_ .. _», que a su vez tiene dos hijos, un nodo «1» y un nodo «10». Lo que aparece en la pantalla es exactamente lo que el backend del compilador escupe en medio del proceso, así es fundamentalmente como funciona el sistema.

Si lo desea, puede pensar en él como un diseño de árbol estándar. con los bordes apuntando fuera de la pantalla hacia usted (y ocluidos por el bloque frente a ellos), pero anidar es una forma tan válida de mostrar un árbol como un diagrama de vértice.

También «servirá el viaje de ida y vuelta desde la fuente al gráfico de nodos y luego de vuelta a la fuente cuando sea necesario «. De hecho, puede ver que eso sucede cuando hace clic en» Vista de código «en la parte inferior. Si modifica el texto,» se volverá a analizado y el árbol resultante renderizado para que lo vuelva a editar, y si modifica los bloques, lo mismo sucede con la fuente.

El código de lápiz hace esencialmente lo mismo con, en este punto, una mejor interfaz . Los bloques que utiliza son una vista gráfica del CoffeeScript AST.También lo hacen los otros sistemas basados en bloques o mosaicos, en general, aunque algunos de ellos no hacen que el aspecto de anidamiento sea tan claro en la representación visual, y muchos no tienen un lenguaje textual real detrás de ellos, por lo que el » árbol de sintaxis «puede ser un poco ilusorio, pero el principio está ahí.

Lo que te estás perdiendo, entonces, es que estos sistemas realmente están trabajando directamente con el árbol de sintaxis abstracta. Lo que ve y manipula es una representación de un árbol que ahorra espacio, en muchos casos literalmente el AST que produce un compilador o analizador.

Al menos dos razones:

1. Porque el código fuente es una representación mucho más concisa. Trazar un AST como un gráfico ocuparía mucho más espacio visual.

   Los programadores valoran tener tanto contexto como sea posible, es decir, tener la mayor cantidad de código presente de una vez en la pantalla al mismo tiempo. El contexto les ayuda a administrar mejor complejidad. (Esa es una de las razones por las que muchos programas Los ammers usan estas locas fuentes pequeñas y enormes pantallas de 30 «.)

   Si intentáramos mostrar el AST como un gráfico o árbol, entonces la cantidad de código que cabría en una sola pantalla sería mucho menor que cuando se representa como código fuente. Eso es una gran pérdida para la productividad del desarrollador.

2. Los AST están diseñados para la programación de compiladores, no para que los programadores los entiendan fácilmente. Si toma una representación AST existente y la muestra visualmente, probablemente sería más difícil de entender para los desarrolladores, porque las AST no fueron diseñadas para que los desarrolladores las aprendan fácilmente.

   Por el contrario, el código fuente generalmente está diseñado para ser legible / comprensible por los desarrolladores; ese es normalmente un criterio de diseño crítico para el código fuente, pero no para los AST. Los AST solo deben ser entendidos por los redactores del compilador, no por los desarrolladores de todos los días.

   Y, en cualquier caso, el lenguaje AST sería un segundo idioma que los desarrolladores deberían aprender, además del lenguaje fuente. No es una victoria.

Consulte también https://softwareengineering.stackexchange.com/q/119463/34181 para conocer algunas posibles razones adicionales.

Comentarios

• » Por el contrario, el código fuente está diseñado para que los desarrolladores lo puedan leer y comprender » – contraejemplo: la mayoría de esolangs, Perl, Lisp
• » Becaus El código fuente es una representación mucho más concisa. «; » el lenguaje AST sería un segundo idioma que los desarrolladores deben aprender, además del idioma fuente » – estos son argumentos en contra de todos PL visuales, pero no ayuda a explicar la distinción que preocupa al OP.
• » (Eso ‘ es una de las razones por las que muchos programadores usan estas locas fuentes pequeñas y enormes 30 » pantallas.) » – si necesitas una pantalla grande para ver suficiente contexto, ¿tal vez ‘ eres codificación espagueti? 😉
• @Raphael Quizás, pero es ‘ menos esfuerzo invertir dinero que refactorizar.
• @JanDvorak, .. .LISP es un contraejemplo porque el AST es el lenguaje – que es lo que le da su poder expresivo; escribir código LISP que recompile su otro código LISP es tan fácil como escribir código que modifica las estructuras de datos estándar de LISP … que son exactamente en lo que está escrito el código LISP . Hay ‘ una razón por la que ‘ duró más de medio siglo: la familia ‘ El diseño de s es extraordinariamente expresivo. Go tuvo que tener sus extensiones asincrónicas integradas profundamente en el lenguaje y el tiempo de ejecución; para Clojure, ‘ es solo una biblioteca. Consulte también: Superando los promedios .