可视化编程工具，为什么不直接与AST一起使用？

我已经找到了一些开源的可视化编程工具，例如Blockly和friends，以及在Github托管的其他项目，但是找不到直接与抽象语法树配合使用的工具。

这是为什么？

我之所以问是因为，一旦我发现那里的每个编译器在编译过程中都有一个阶段，它将源代码解析为AST，对我来说很明显，某些可视化编程工具可以利用这一点为程序员提供方法直接以视觉方式编辑AST，还可以进行从源到节点图的往返，然后在需要时再次返回源。

例如，人们可能认为，从JavaScript AST Visualizer到实际的JavaSript可视化编程工具，两者之间并没有太大的区别。

那么，我想念什么？

这些工具中有许多确实可以直接与抽象语法树配合使用（或者直接对它进行一对一可视化）。其中包括您已经看到的Blockly，以及其他类似的基于块的语言和编辑器（Scratch，Pencil Code / Droplet，Snap！，GP，Tiled Grace等）。

出于其他原因（空间以及交互困难）的原因，这些系统没有显示传统的顶点和边缘图表示，而是直接表示树。如果一个节点或块直接位于父节点内部，则它是另一个节点的子节点。

我构建了这些系统之一（Tiled Grace，paper，paper）。我可以向您保证，它非常直接地与AST一起使用：您在屏幕上看到的是语法树的精确表示，如嵌套的DOM元素（所以就是一棵树！）。

这是某些代码的AST。根是“ for ... do”的方法调用节点。该节点有一些子节点，以“ _.._”开头，该子节点本身有两个子节点，即“ 1”节点和“ 10”节点。屏幕上显示的正是编译器后端在处理过程中吐出的内容-从根本上讲就是系统的工作方式。

如果愿意，可以将其视为标准的树形布局，其边缘朝着您的方向指向屏幕外（并被它们前面的块所遮挡），但是嵌套是将树显示为顶点的有效方法图。

它还将“从源到节点图进行往返，然后在需要时再次返回源”。实际上，单击底部的“代码视图”可以看到这种情况。如果修改了文本，则将重新解析该文本，并渲染结果树以供您再次编辑，如果修改了块，则源代码也会发生相同的情况。

到目前为止，Pencil Code所做的事情基本上是相同的，但界面更好。它使用的块是CoffeeScript AST的图形视图。总体上，其他基于块或图块的系统也是如此，尽管其中一些系统在视觉表示中并未使嵌套方面变得十分清晰，而且许多系统背后没有实际的文字语言，因此“语法树”可能有点虚幻，但是原理就在那里。

你错过了什么，然后，是这些系统确实是直接与抽象语法树工作。您所看到和操作的是树的空间高效渲染，在许多情况下，实际上是编译器或解析器生成的AST。

至少有两个原因：

1. 因为源代码是一个远更简洁表示。将AST布置为图形会占用更多的视觉空间。

   程序员希望获得尽可能多的上下文-即，同时在屏幕上一次显示尽可能多的代码。上下文可以帮助他们更好地管理复杂性。（这就是为什么许多程序员使用这些疯狂的小字体和巨大的30英寸屏幕的原因之一。）

   如果我们试图将AST显示为图形或树形图，那么您可以在单个屏幕上显示的代码量将远远少于将其表示为源代码时的数量。这是开发人员生产力的巨大损失。

2. AST用于编译器编程，而不是为了使程序员易于理解。如果您采用现有的AST表示形式并以可视方式显示它，那么开发人员可能会更难理解，因为AST的设计目的并不是让开发人员易于学习。

   相反，源代码通常是设计为开发人员可以读取/理解。这通常是源代码的关键设计标准，但对于AST则不是。AST只需要编译器作者理解，而无需日常开发人员理解。

   而且，在任何情况下，除了源语言之外，AST语言都是开发人员必须学习的第二语言。不是胜利。

另请参见/software//q/119463/34181，以了解其他一些潜在原因。

编译器的典型AST相当复杂且冗长。有向图表示将很快变得很难遵循。但是，在CS的两个大区域中都使用了AST。

1. Lisp语言实际上是作为AST编写的。程序源代码以列表形式编写，并由编译器和/或解释器直接使用（取决于所使用的变体）。
2. 建模语言（例如UML）和许多特定于视觉域的语言都使用图形表示法，这些表示法在比典型的通用语言AST更高的抽象级别上有效地实现了抽象语法图（ASG）。