可视化编程语言

我们大多数人都是使用“文本”编程语言（例如Basic，C / C ++和Java）学习编程的。我相信人类进行视觉思考会更加自然和有效。可视化编程允许开发人员通过操纵图形元素来编写程序。我猜想使用可视化编程应该可以提高代码质量并减少编程错误。我知道一些视觉语言，例如App Inventor，Scratch和LabView。

为什么开发人员没有主流的通用视觉语言？可视化编程的优缺点是什么？

通常，在编程语言设计中要在易用性和表达能力之间进行权衡。通常，用Scratch或App Inventor之类的初学者语言编写简单的“ Hello，world”程序要比使用Java或C ++等通用编程语言编写更为容易，输出到不同的字符集，更改语法，动态类型等的机会

在创建App Inventor（我曾经参加过）的过程中，我们的设计理念是使初学者的编程变得简单。一个简单的例子是将数组索引设为1而不是0，尽管这样会使高级程序员执行的计算稍微复杂一些。

但是，可视化编程语言倾向于为初学者设计的主要方式是通过使不可能创建语法无效的程序来消除语法错误的可能性。例如，块语言不允许您将右值作为赋值语句的目标。这种哲学倾向于产生更简单的语法和语言。

当用户开始使用块语言构建更复杂的程序时，他们发现拖放块比键入要慢。您是键入“ a * x ^ 2 + b * x + c”还是使用块创建它？

几个段落中（至少在我看来）无法对此主题给予公正，但是一些主要原因是：

1. 块语言往往是为初学者设计的，因此设计上没有那么强大。
2. 在通用编程语言中找不到表达某些复杂概念（如类型系统）的美观方法。
3. 对于复杂的程序，使用块是不方便的。

为什么开发人员没有主流的通用视觉语言？可视化编程的优缺点是什么？

视觉语言倾向于将其分为三大类：

1. 工具非程序员执行基本的自动化任务。在Mac上使用Automator。
2. 学习环境中不适合进行大量键入操作，或者显示逻辑流程的程序结构很重要。想想Scratch，Alice等。
3. 要解决的问题是数据流问题，该问题的解决方案通过模仿物理世界的独立包装箱之间的某种数据流进行了很好的建模。都可以想到LabView和Ableton。

可视化编程的优点是您可以获得系统结构的高级概述。这导致了紧迫的问题，即当您进行详细说明时，您的意大利面条代码确实看起来像意大利面条。视觉语言的常见组件是视觉元素的某种代码块或配置组件。问题是程序员需要弄清楚可能以奇怪的方式互连的断开连接的代码块。

尽管可视化编程没有什么错，但在大多数情况下，这可能并不是一个好方法。

有许多可视化编程语言，如以下两个书目所示：vlib.org和oregonstate.edu。

恕我直言，他们未能获得吸引力，因为尽管它们适合用作玩具示例，但它们无法管理大型项目所需的抽象，表示和粒度的多个级别。您将需要查看诸如AutoDesk Revit（建筑师和工程师使用的建筑信息管理系统）之类的系统，以了解如何管理视觉信息变得多么复杂。

可视化编程最适合作为专用领域中的配置工具，而不是着眼于通用编程。

文字是视觉的。

我们在代码中使用了各种视觉提示。每次使用空格（缩进，换行，空白行，行内间距）都旨在为代码的功能提供视觉提示。我们使用各种不同的语法来提供有关代码正在执行的可视信息。我们的编辑为我们的代码着色，使其脱颖而出。

数学是文本的。有各种各样的表示法，但最终可以归结为基本上是文本。他们已经做了数百年。

我的观点：代码的文本表示是在利用人类的视觉能力。我们可能可以更好地利用它，但是不能放弃文本。

[有关此回复的PDF版本，这些图或图表是交互式且动态的。]

网络元素和注释：通用的可视化编程语言

我使用图形来组织使用Acrobat®/ JavaScript API的JavaScript™程序。每个图形对象代表一个Petri Net元素（位置，过渡，输入或输出）或代表多个Petri Net元素。每个图形对象实际上是相应网络元素的注释。但是，如果每个图形对象都映射到一个并且只有一个网元，则可以将其用于生成网元。并且，如果图形对象映射到多个网络元素，并且映射定义明确，则它也可以用于生成网络元素。标准Petri Net元素由某些类型的图形表示：圆形是一个位置，正方形或矩形或直线是过渡，从圆形到正方形的箭头是输入，从正方形到圆形的箭头是输出。此外，

[在此回复的PDF版本中找到“标准Petri网”中的注释类型。]

卡尔·亚当·皮特里（Carl Adam Petri）描述了大多数这样的想法（包括他的博士学位论文（Petri，1966年）中“标准Petri网”中注解的类型。他还将网元和注解应用于几种逻辑电路的描述，例如6。

好处与挑战

视觉编程语言可以帮助计算机程序员开发计算机程序（Menzies，2002年）。

至少有三个原因使我发现网络元素和注释很有用（优势？）。

冷杉的理由。可以一次创建一个元素的过程逻辑。这意味着可以通过在现有网络中添加元素来扩展网络（Petri，1966）。例如，控制器的模型可以分为内部和外部组件。内部组件调节系统。外部组件通过接受来自环境的输入来与环境交互。图1是内部组件的Petri Net模型。通过添加适当的位置和过渡，可以将外部组件的Petri Net模型添加到内部组件的Petri Net模型中（图2）。

图1控制器内部组件的Petri网模型（Halloway，Krogh和Giua，1997年）

图2控制器内部和外部组件的Petri网模型（Halloway，Krogh and Giua，1997）

第二个原因。与每个网络元素关联的代码可以来自一种以上的“编程语言”（Petri，1973）。它们可以来自计算机语言，例如JavaScript，COBOL，ADA和汇编语言。它们可以来自数学语言，例如代数符号。它们可以来自以英语，德语，法语，希腊语，他加禄语，中文等编码的散文。因此，它可以用作整个软件或系统开发生命周期中进行交流和协作的基础。在不同的用户，开发人员和利益相关者之间（Petri，1973）。

第三个原因。可以专注于网络中的某些图形对象，并为相关图形对象写出代码或逻辑注释。考虑图3中的纸牌游戏的Petri网模型。如果输入P7T4的箭头是放置/转换网中输入的标准图形，并且如果m_7是放置P7的标记，则用于的逻辑注释更新输入位置的标记是m_7 = m_7-1。如果s_9 ^-是输入的状态，则用于更新输入状态的逻辑注释为s_9 ^-=（（m_7 <1）？false：true）。

图3纸牌游戏的Petri Net模型

我至少有三个原因使我发现Petri Nets的应用具有挑战性（缺点？）

如果图形对象太多，则将很难创建或读取网络。可以通过获取一部分图形来缓解这种困难，并使用一个，两个或三个图形符号来表示它们（Noe，1973； Petri，1966）。例如，如果认为图3中的纸牌游戏的Petri Net模型在图中有太多图形对象，则可以组合一些图形，并且仍然保持足够的信息以将图映射到计算机程序中。考虑图4，它是图3中具有高级图形的同一游戏的Petri Net模型（Chionglo，2016a）。

图4使用高级图形的纸牌游戏的Petri网模型（Chionglo，2016a）

在另一个示例中，可以将图2中控制器的外部组件组合起来，以创建更简洁的图形表示，如图5所示。

图5具有外部组件高级图形的控制器的Petri Net模型

最后，也可以使用高级图形对象来表示一组互斥的位置或一组互斥的转换（Chionglo，2015年）。

第二个原因。即使使用标准图形，绘制和定位图形也可能具有挑战性，特别是如果人们希望最终图对用户或读者友好的话。制作对用户或读者友好的图表的一些决定包括：图形对象的正确布局，画布和形状的适当尺寸，箭头的曲率，箭头的类型，文本的大小和字体，以及图形和文本的颜色选择。

第三个原因。因为每个注释都直接或间接与网络元素相关，所以以有序方式创建网络元素的注释很容易。但是，显示每个注释以及每个网络元素的图形可能不是一个好主意，因为图中可能会显示太多信息。例如，考虑逻辑电路的Petri Net模型图，其中包括对所有属性和逻辑注释的引用（图6）。[原始模型包括每个输出状态的测试条件（（Petri，1966年，第78页图31）；在此省略了测试条件，因为它相当于给定初始标记的原始模型。因此，每个输出都有一个用于计算输出位置标记的逻辑注释。]

图6带有注释的地方/过渡网-基于Petri论文（1966）的英文翻译的第31页第78页

减轻这一挑战的一种方法是识别模型中使用的注释的类型，并定义包括这些类型的注释的图形对象（Petri，1966）。因此，当Petri Net图由定义中的图形对象组成时，这些对象的解释应包括“不可见”注释。图7应该解释为标准Petri网（有关定义，请参见标准Petri网的注释）；因此，逻辑注释可以从图中省略。

图7放置/转换网–基于Petri论文（1966年）的英文翻译第78页的图31

缓解此挑战的另一种方法是使用批注的表单视图来补充或补充图（Chionglo，2016b； 2014）。可以将视图进一步划分为较小的视图，并且可以显示和隐藏每个视图。

参考文献

J.Chionglo（2016a）。在Stack Overflow上回复“如何为React / Redux抽认卡游戏设计状态流？”。可从https://www.academia.edu/34059934/A_Reply_to_How_to_design_a_state_flow_for_a_react_redux_flashcard_game_at_Stack_Overflow获取。

J.Chionglo，JF（2016b）。Petri网的两种形式的视图。可在http://www.aespen.ca/AEnswers/CAPDissF31P78-form.pdf上获得。

Chionglo，JF（2015）。使用高级图形减少Petri Net图中的网元图形数量。可从http://www.aespen.ca/AEnswers/WjTpY1429533268获得。

Chionglo，JF（2014）。用于计算机编程的网络元素和注释：PDF中的计算和交互。可在https://www.academia.edu/26906314/Net_Elements_and_Annotations_for_Computer_Programming_Computations_and_Interactions_in_PDF上获得。

LE，Halloway；Krogh，BH和Giua，A.（1997）。受控离散事件系统的Petri网方法综述[电子版]。离散事件动态系统：理论与应用，第1卷。7.波士顿：克鲁维尔学术出版社，第151至190页。

Menzies，T。（2002）。视觉编程语言的评估问题。在SK Chang（Ed）。软件工程与知识工程手册，第1卷。2新兴技术。世界科学出版公司 Pte。有限公司，第93 – 101页。

Noe，JD和Nutt，GJ（1973）。“用于并行系统表示的宏E-Net”，IEEE计算机事务，第1卷。C-22，第8号，1973年8月，第718 – 727页。

佩特里，加利福尼亚（1973）。网络理论的概念。在计算机科学的数学基础：过程。数学和暑期学校，高塔特拉地区，1973年9月3日至8日，第137至146页。研究所 斯洛伐克学院。科学学士，1973年。

佩特里，加利福尼亚（1966）。与Automota通信[trans。CF Greene，Jr.]。技术报告RADC-TR-65-377的补编I（第I卷）。纽约州格里菲斯空军基地：格里菲斯空军基地空军系统司研究和技术部罗马空中开发中心。从2011年8月31日从http://www.informatik.uni-hamburg.de/TGI/mitarbeiter/profs/petri/doc/Petri-diss-engl.pdf检索。

Johne Percival Hackworth：

尽管可视化编程没有什么错，但在大多数情况下，这可能并不是一个好方法。

也许，迄今为止的可视化编程语言还太不成熟？先进的可视化无法应用于软件工件，而完全由每个开发人员的“想象力”来决定自己滚动的想法可能是错误的假设。只要不牺牲执行低级抽象和高执行性能的能力，以统一和自动化的方式提高抽象级别似乎是显而易见的。这最终可能导致领域专家进行“编程”，这与电子表格自动使COBOL程序员处理数字的任务的方式没有太大不同。这里的主要区别是用“通用系统”来代替数字。

您可以查看无编码技术编程（PWCT）

PWCT是一种通用的可视化编程语言，它通过生成交互步骤而不是编写代码来实现系统和应用程序的开发。

这是一个很好的起点，并且是开源的。

一个棘手的问题。可视化或基于流的编程确实已得到越来越多的使用，但是与所有编程语言相比，它并未得到广泛使用。重要因素是维护和标准化。可以在页面上打印计算机代码。如何打印视觉程序并不总是很清楚。

与当前的最佳答案相反，我认为视觉编程能力和文本语言之间绝对没有内在的理论限制。实际上，基于人类对多个抽象层的更快概念化，可视化编程可能会被认为更容易维护。因此，在吸收社会/文化惯性/保守主义方面似乎有明确的要素。

可视化编辑器的代码可能要复杂得多，考虑到即使是基于文本的IDE也会非常复杂，例如Eclipse，这是非常艰巨的，请注意，某些IDE（例如eciplse）中有可视化编程的插件，例如用于GUI的构建。用于GUI构建的可视化编程现在相当普遍。

在我看来，视觉编程在某些领域的使用正在增加，从很久以后，它可能会变得越来越普遍。

数十年来，视觉编程并不是EE 芯片设计所固有的，它并不是一种抽象，并且（子）系统完全按照预期的二维布局进行布置，这一点请不要忘记。

Lego头脑风暴套件现已广泛使用，并且已有十多年的历史了，它一直拥有基于可视化编程的开发软件，现在已大大简化了许多版本。

这是一篇有趣的近期文章，它分析了历史和前景，并暗示了它对于基于Web的编程可能会变得更加普遍。在页面上动态布置控件/小部件是基于视觉的编程的一种变体。

在许多工具中广泛使用的另一个关键/新兴领域是BPM，业务流程建模。

• 1970年代银行软件的奥秘编码方法如何拯救无处不在的Web开发人员（快速公司）的理智

• BPM，业务流程建模维基百科

我想这些解决方案之所以不那么受欢迎的原因是，在大多数情况下，它们可能无法管理，并且变得一团糟。

如今，几乎所有可用的可视化编程工具都是大型应用程序的一部分，并且用于特定目的（例如：UE4中的蓝图）。

无论如何，我最近遇到的用于通用编程的新工具是Korduene，它确实不是通用的，因为它更多地用于创建Windows应用程序。

我认为@Raphael和其他人说程序是文本时是错误的。不是。有很多东西 它告诉计算机该做什么或如何做。（无效的，声明性的编程）编程与文本编辑的关联是历史性和违反直觉的教条。这是由早期计算机的有限文本输入/输出创建的。人不是文本解析器！

虽然我认为人们是对的，对于通用语言来说，完全可视化的语言（通过鼠标等连接元素来进行可视化操作是不切实际的）是可行的，但我认为所有当前语言都可以并且应该移至中间语言。水平。语言元素具有视觉表示形式，并保存在二进制语言文件中。程序员不会以疯狂的方式键入文本，也不会以行和缩进的方式生活。

但是可以通过最有效的热键/命令/ UI元素组合来插入元素。并且仅键入字符串以及其他数据和标识符。这将使语法错误成为不可能，并使具有安全性和正确性的语言（例如：ADA）更加高效。通过使整个类别的常见错误都变得不可能，也将使其他人更安全，减少错误。（例如ADA通过累赘来避免的行为）

在某种程度上，事情正在朝着这种方向发展。通过自动缩进和语法着色。可悲的是，没有人意识到（或足够关心）这是“人工文本解析器”的核心概念。emacs vs vim参数很有趣，因为两者都是错误的。它们是人为制造的问题的“解决方案”。