背景
像 Godot 或 Unity 这般的游戏引擎，它们准许编写普通代码，同期亦能够创建和编辑场景。
Godot游戏引擎是一款制作游戏的软件，能够制作2D和3D游戏
咱们都爱好运用图表来处理繁杂编程任务，将图表做为一种工具，与代码并行运用。
代码与图表的关系，通常能够分为以下四个层次。
Level 0：图表与代码分离存在
咱们能够在一个专门的工具里绘制这些图表，而后用它们来辅助编写代码。
能够把图表放在wiki或知识库里，供项目成员查看。
不外，这般做有有些缺点：图表可能难以被发掘，况且容易过时。
Level 1: 图表与代码并行存在
有一个简单的办法能够处理图表难以发掘的问题：试试在文本文件中插进ASCII图像。
这般，咱们就能够更方便地查看和运用这些图表了。
日前，这可能是咱们能做到的最佳处理方法。
但火速就会变得杂乱无章。
这个办法有几个优点：容易实现（只要大众同意怎么做），况且很通用（可能有非常多其他用途）。
但亦有缺点：图表还是可能会过时。况且，正如“注释不是代码”那样，这儿亦同样。
另一，倘若你是在终端里编写代码，这个办法就更不适用了。
Level 2: 由代码生成图表
代码和图表应该共存，图表能够由代码生成。
其实，从代码生成图表完全是咱们常用的集成研发环境（IDE，Integrated Development Environment ）能够做到的事。
优点： 总是保持最新。非侵入性：能够集成到IDE中，不影响代码的存储方式。
缺点： 这能够帮忙你理解，但真不确定能否真正帮忙你思考？可能不太吸引人，由于这些自动生成的图表常常欠好看。布局一个好看的图表很难。
Level 3: 图表本身便是代码
图表即代码，能够直接执行，这才是咱们追求的将来目的。
我认为这便是最后目的。有些东西用文本表达更好，而有些则最好以视觉方式呈现。
咱们应该按照详细状况选取最合适的办法来混合运用。
别试图可视化简单的代码，亦不要在图表更合适时还试图编写代码。
Luna便是一个尝试。她们尝试了双重暗示：所有内容同期以代码和图表的形式存在，你能够在两者之间切换。
但这般做，你不仅能享受到两种方式的好处，还会同期受到文本和视觉媒介的限制。
你可能没法处理哪些难以可视化的内容（例如循环、递归、抽象），亦不可处理哪些难以编码的内容。
我认为文本编码还是应该用在适合的地区，但咱们亦应该能切换到图表工具中，绘制状态机，并像执行文本代码同样执行它。
当我说“绘制”时，我指的是实质的图形绘制。
亦便是说，你能够直接操作图形，而不必须把它们转换回文本。
图表不该该替代或“加强”文本，它们应该和文本并存，做为一个独立的工具存在。
想象它像游戏引擎，例如 Godot 或 Unity。你能够编写代码，亦能够创建和编辑场景。
这些场景存储在自己的文件中，有专门的编辑器处理它们，不必须代码暗示。
由于在这种状况下，视觉呈现更合适。
非目的：图表取代代码
最后强调的是：
不是在说用图形方式来编写代码。
针对文本已然能完成的任务来讲，图形方式其实只是一个不太方便的选取。
这个亦回答了低代码平台为啥推广的欠好，有时代码更好。
将图表用于适当的场景，如状态转换、内存布局和网络请求，而不是全面替代代码。
参考
https://tonsky.me/blog/diagrams/
| 
发表于 2024-8-20 13:01:54