注意事项
该出版物的初始版本以超过300条评论的形式在Reddit上获得了好评。 在那之后，我决定对它进行一些小的更新，以解决收到的许多批评。
视觉编程语言是一种语言，它允许程序员通过操纵图形元素而不是键入文本命令来创建程序。 一个著名的例子是
Scratch ，这是一种MIT原生的可视化编程语言，用于教育孩子。 它的优点是使初学者和非程序员都可以更容易地进行编程。
在1990年代，发生了一种非常流行的运动，即使用所谓的
CASE工具将可视化程序引入公司环境，其中可以使用
UML定义公司系统并生成（其代码），而无需吸引训练有素的软件开发人员。 这是由于“往返”（“ round trip”）的概念所致，在该系统中，可以对系统进行可视化建模，将从接收到的模型中生成程序代码，对代码的任何更改都可以返回给模型。 遗憾的是，此类工具无法完成其任务，并且大多数[关于其实施的]实验目前基本上都已被放弃。
因此，除了一些非常有限的区域外，视觉编程还没有得到普及。 这种情况主要是由于以下关于编程的误解：
- 文本编程语言使本质上简单的过程变得混乱。
- 抽象和解耦（ 解耦，减少连接性 ）在编程中起着很小的外围作用。
- 设计用来帮助编程的工具并不重要。
第一个误解坚持认为软件开发具有很高的入门门槛，因为文本编程语言使编程的真实本质变得复杂。 Scratch在学术教育者中的流行与这种误解并存。 想法是编程实际上非常简单，如果我们只能以清晰的图形格式显示它，它将大大减少创建和读取程序代码所需的学习曲线和精力。
我认为这种误解源于无法实际阅读以标准文本编程语言编写的典型程序，并且无法想象如何将其从立方体和箭头转换为图形元素。 如果您仍然可以想象得到，那么很明显，一行代码通常与多个“块”匹配。 由于即使对于最简单的程序，数百或两行代码的存在也不是少见的，因此其代码将变成数百甚至数千个图形元素。 试图从心理上解析如此复杂的图片比仅阅读等效的程序文本要困难得多。
大多数视觉编程语言的解决方案是使“块”更加复杂，以使每个视觉元素都等效于大块的文本代码。 工作流程的可视化工具是一个直接的绊脚石。
问题是，仍应在某处定义代码。 因此，[在大型视觉元素上的]编码过程变成了“编程对话框属性”。 可视元素本身仅代表执行过程中程序的最高级别，现在大多数工作是通过隐藏在可视“立方体”中的标准文本代码完成的。 结果，我们两全其美，并获得了现代工具无法支持的文本编程。
属性对话框通常是非标准的开发环境，并且会使用特定的语言选择，通常是某种类型的脚本语言。 基本的视觉元素本身只能由经验丰富的程序员创建，并且只有通过阅读基本代码才能完全理解它们，因此在这里失去了可视化表示的大多数所谓好处。
视觉“代码”和文本代码之间存在阻抗失配（
一系列概念和技术难题 ），程序员必须在它们之间的界面上进行导航，与解决原始任务（编写程序）相比，通常需要花费更多的精力来改进图形编程工具本身。
现在我们来第二个误解，即抽象和去重复在编程中起着很小的作用。 可视化编程基于以下假设：大多数程序都是简单的过程序列，有点类似于流程图。 通常，大多数新手程序员都认为软件就是这样工作的。
但是，一旦程序不仅仅是一个简单的例子，它的复杂性就会很快淹没新手程序员。 初学者发现很难谈论大型程序代码库，并且常常陷入尝试创建稳定高效的大型软件的困境。 编程语言的主要创新是尝试通过抽象，封装和减少连接来控制复杂性。 所有类型的系统以及面向对象和功能性编程语言的构造实际上只是试图控制这些语言的复杂性。
大多数专业程序员将不断地对代码进行抽象和解耦。 实际上，好的和坏的代码之间的区别基本上是程序员设法做到这一点的程度。 视觉编程工具很少有有效的机制来处理这些事情；结果，“视觉”开发人员陷入了可用的功能中，相当于1970年代的BASIC。
最终的误解是，视觉程序员应该可以不需要几十年来开发的所有编程支持工具。 看一下代码编辑器和IDE的长期发展。 例如，Visual Studio支持有效的智能感知工具，使您可以仅查看基类库中的数千个API。 缺乏良好的版本控制是大多数可视化编程工具中的另一个主要缺陷。
即使它们以文本格式保存其布局，“ diff”也没有或几乎没有含义。 在很大的XML或JSON块中很难做出“责备”（查找提交并负责更改特定行）。 对于程序的功能执行没有意义的事情（例如图形元素的位置和大小）会不断导致元数据发生变化，这使得diff解析变得更加困难。
文本编程语言已经学会了将代码的结构块分成单独的源文件，因此可以很容易地将一个系统中的更改与另一部分中的更改合并。 可视化工具通常根据“每个文件一个图”的原理保存结果，这意味着合并变得有问题，如果难以分析“ diff”的语义，则合并会更加困难。
更新资料当我在第一段中拍摄了Scratch屏幕截图并将其用作主要示例时，我可能会误解。 我不是老师，对于Scratch作为学习工具的有效性，我没有自己的见解。 许多人说，它在教授程序设计方面非常有用，特别是对儿童而言。 凡能帮助人们进入精彩而令人兴奋的编程世界的事物，都应受到赞扬。 我真的不打算现在专门批评Scratch，这只是一个可视化编程系统的例子，在我看来，我的大多数读者至少应该听过。
Reddit提供的另一个反例是静态结构工具，例如UI设计器，数据库模式设计器或类设计器。 我同意他们会非常有帮助。 任何有助于可视化程序的数据结构或规模结构的东西都是红利。 但是它们永远不够。 这可以从90年代的工具（例如Power Builder）完全失效来证明，该工具基于图形化可视化来创建开发环境而无需使用代码。
关于作者：
笔记，大声念头，清晰可见的学习，误解，错误，纯正的见解。 我是传教的开发人员Mike Hadlow。 我住在英格兰南海岸的布莱顿附近。
该翻译得到专业软件 开发和测试公司EDISON Software的支持。