为什么说可视化编程是糟糕的想法？

可视化编程语言可以让程序员通过操纵图形元素来创建程序，而无需键入文本命令。

众所周知的例子是 Scratch，这是一种麻省理工学院开发的可视化编程语言，用来教孩子们学编程。

该语言的优势在于新手和普通用户可以更容易接触编程。二十世纪九十年代曾经有一种非常流行的运动，即通过所谓的 CASE 工具将这类工具带入企业，这些企业的系统可以通过 UML 进定义和生成，而无需雇佣训练有素的软件开发人员。

这涉及“round tripping”的概念，即通过可视化的手法为系统建模，根据模型生成程序代码，而且任何代码的变更都可以反向反映到模型上。但最终这些工具未能兑现承诺，而且大多数这类尝试现在也已基本放弃了。

因此，除了一些非常有限的领域外，可视化编程都未能成功。其中的原因基本上可以归于以下几种对编程的误解：

文本编程语言混淆了本质上很简单的过程。

抽象和解耦是外围问题，对编程的意义不大。

为支持编程而开发的工具并不重要。

误解一：文本编程语言混淆了编程本质

第一个误解认为软件开发的门槛很高，因为文本编程语言混淆了编程的本质。Scratch 在教育学家中的流行就属于这种误解。

该观点认为编程实际上非常简单，我们只需通过清晰的图形来表现，就可以大大降低创建和阅读软件所需的学习曲线和努力程度。

我认为这种误解是因为有些人未能真正读懂用标准的文本编程语言编写的程序，并想象可以将程序转换成盒子和箭头等图形元素。

如果你这样做，很快就会发现一行代码经常需要映射到多个盒子上，一个简单的程序包含数百行代码的情况是常态，因此这将转化为成百上千个图形元素。在头脑中理解如此复杂的图形往往比阅读同等的文本更加困难。

在这个问题上，大多数可视化编程语言的解决方案是使用“块”来代表更为复杂的操作，从而可以让每个可视化元素都代表一大段文本代码。可视化流程工具是罪魁祸首。

问题是我们需要在某个地方定义这些代码。于是，这就成了“属性对话编程”。可视化元素本身仅代表最高级别的程序流程，而大多数的工作是通过隐藏在盒子中的标准文本代码完成。这种做法酿成了现如今两边皆难堪的局面。一边的文本编程语言没有现代工具支持。

属性对话编程通常是低配版的标准开发环境，而且你必须选择特定的语言，通常是某种脚本语言。而在另一边，可视化元素只能等待有经验的程序员创建，而且只有通过阅读底层的代码才能读懂程序，所以大多数视觉化表现手法的优势都丧失了。

视觉上的“代码”和文本代码之间存在着阻抗失配，而且程序员必须不断在两者之间来回切换，时间都浪费在满足图形编程工具的需求上，而不是解决手头的问题。

误解二：抽象和解耦是外围问题

因此才有了第二个误解，即抽象和解耦是外围问题。可视化编程假设大多数程序都是简单的程序序列，有点像流程图。实际上，这也是大多数新手程序员想象的软件工作原理。

然而，一旦程序的规模超出了简单的示例，新手程序员很快就会被复杂性压垮。他们发现很难推断程序的代码库，而且常常难以大规模地创建稳定又高效的软件。

编程语言中的大多数创新都是为了管理复杂性，最常见的是通过抽象、封装和解耦。面向对象和函数式编程中所有类型的系统和装置实际上都是为了努力控制这种复杂性。大多数专业程序员会持续不断地抽象和解耦代码。

实际上，好代码和差代码之间的本质区别也在于此。可视化编程工具很少拥有有效的机制来执行这些操作，而开发人员也必将陷入二十世纪七十年代 BASIC 的漩涡中。

误解三：为支持编程而开发的工具并不重要

最后一个误解是即使没有现代编程工具的支持，可视化程序员也可以编程。想想代码编辑器和 IDE 漫长的演变过程。

例如，Visual Studio 支持高效的智能感知，可以单独查找基类库中数千个 API。缺乏良好的源代码控制是绝大多数可视化编程工具的另一个主要的缺点。即使这些可视化工具的布局保存为文本的格式，代码的差异也毫无可读性可言，因此毫无意义。

我们很难从大块的 XML 或 JSON 找出每行代码的修改来源。一些对程序的功能执行没有任何影响的因素，比如图形元素的位置和大小，也会导致元数据的变化，这让解析差异变得更加困难。

文本编程语言知道将不同的代码保存到不同的源代码文件中，因此系统某一部分的变更很容易与另一部分的变更合并。

可视化编程工具通常会将每个图表保存在一个文件中，这意味着合并也会成问题，当遇到难以解析差异的语义时，难度会更大。

总之，可视化编程工具提供的优势，即简化程序的创建和理解只是一个海市蜃楼。

只有在非常简单的编程中才可行，在这种不理想的形势下，最好的结果也不过是说：可视化元素是具有混淆副作用的文本代码的容器。

补充说明

可能在第一段中加上 Scratch 的截图并用作主要示例是错误的做法。我不是一名教育工作者，我不知道 Scratch 是否可以作为一种有效的教学工具。

许多人提到，Scratch 在编程教学方面非常有用，特别是对儿童而言。任何可以引导人们进入精彩纷呈的编程世界的东西，我都欢迎。

我并不想通过这篇文章抨击 Scratch，提到它只是因为它是大多数人都听过的最有名的可视化编程系统。

有人在 Reddit 上提到的另一个反面例子是静态结构工具，例如 UI 设计工具、数据库模式设计工具或类设计工具。

我同意这些工具非常有用。任何有助于可视化数据结构、或程序的大规模结构的工具都是好东西。

但这些不足以支撑他们的论点。PowerBuilder 等 90 个试图通过在图形可视化之上构建工具，来开发出一个完全不用写代码的开发环境，可是最终都失败了，这恰恰证明了我的观点。

你如何看待可视化编程？

针对可视化编程并不是理想的想法，评论区的不少网友也发表了不一样的看法：

评论1：

你混淆了图形数据流语言（带有隐藏选项框和连接这些框的箭头）与Scratch。Scratch 是一种文本语言，里面的程序语句和类型是预定义的形状，可以消除语法错误。

你无法在 Scratch 中犯语法错误，因为这些框无法组合在一起。 除了这种语法帮助之外，Scratch 不会隐藏任何内容，并且格式也与纯文本语言没有差别。

也就是说，我同意你说的有关其他教学语言的大部分内容，例如用于 Lego Mindstorms 机器人套件的语言。

该语言源自 LabView，大多数初学者发现很难超越几个块或连接变量之类的东西。我的猜测是，一种能够通过变量赋值来达到复杂性障碍的语言并不能很好地扩展:-)。

评论 2：

我认为你的文章的出发点不正确，因为可视化编程根本不是为程序员准备的。