关于LabVIEW的一些争论

我经常听到，甚至有时关注于对LabVIEW的争论，即LabVIEW是一种通用的语言还是一种用于测量和自动化的特定应用程序的开发环境。一方面，有经验的程序员指出了LabVIEW缺乏的流行编程语言所具有的特性，但是另一方面，一些用户详细阐述了他们使用LabVIEW所建立的通用应用程序， 而完全没有使用任何数据采集或分析。

对LabVIEW用户的调查可能与最近一个非正式的对一个团队中的开发者的调查一致，这个团队中的绝大多数人都认为LabVIEW已具有足够的功能来被归为通用语言类，而且事实上，正是以这种方式在使用它。LabVIEW被提到次数最多的不足是常用的递归和递归式数据类型，以及面向对象的结 构，但是这些都不是建立通用应用程序的严重障碍。

错误的问题尽管有了调查结果，但是我认为这是一个错误的问题而且试图回答它会导致错误的方向。对我来 说，这有点像在问：汽车是不是用来就座的地方？当然你可以在汽车里就座，但是如果那是你利 用它所做的全部，那么你失去了拥有它可以得到的主要用途。一个较好的问题是：LabVIEW可以被用作通用编程语言吗？或者更好的是:LabVIEW能够被用来创建通用的应用程序吗？

这个问题的新表述在什么被视为通用这个方面仍然是同样模糊的，但是它没有强调有时显得严谨的争论，即LabVIEW是不是一种编程语言？一些人并不认为它是一种语言，因为它不是基于文本的而且它不是顺序化的。更为奇怪的是，关于什么被看作是一种编程语言的这个问题上，那些具有 计算机科学背景的人持有最为狭隘的观点。

但是，经过改正后的问题最为重要的一个方面是它将包容性转换到了正确的方向。换一种方式来表达，即最初的问题间接地暗示了通用编程语言在某种程度上是一个更大的问题或者是测量和自动化编程的一个父集，然而，实际上子集却在其他的方向。

通常，测量和自动化的程序必须处理所有与通用程序一样的问题，如数据结构和算法、文件I/O、网络I/O、用户I/O和数据库存取、打印等等这些常见的问题。但是测量和自动化程序也必须处理比通用程序更多的问题，例如物理I/O、实时性约束和硬件配置。它们也可以具有一些最为苛刻的用户界面要求。测量和自动化程序处理了一个通用程序所处理问题的父集。

如果工具A和工具B可以被用于一定的任务集，但是工具B具有更多的功能可使它益于完成额外的任务，哪一种工具是事实上更为通用的呢？这正是我们关于LabVIEW问题。LabVIEW适于测量和自动化应用程序的能力不是来自于它的基本编程能力被某种方式所限制，而是因为它们经过了增强和扩展。

这就是为什么有必要提出“LabVIEW能够被用来创建通用的应用程序吗？”这个问题而不是“LabVIEW是一种通用编程语言吗？”。我们不希望通过把LabVIEW仅视为一种编程语言而限制了 它的范围或它将来的发展。

LabVIEW不仅仅是一种编程语言。它是一种高度交互式的开发环境用来快速设计原型和应用程序的 渐进式开发，从测量和自动化到实时嵌入式系统，再到通用场合。而且现在，LabVIEW具有了对 FPGA编程下载的能力，所以LabVIEW也是一个硬件设计工具。

数据流
LabVIEW的核心是结构化的数据流图。数据流已存在了很长一段时间而且已被深入地理解。事实上，它是一个比流行的基于文本语言的控制流更为丰富的计算模型，因为它的本质是并行的，而 C/C++和BASIC则不是——它们必须依赖于对操作系统的库函数调用来实现并行机制。因此，编译器不能确保代码的共享部分被适当地保护，这使得它难以建立并行程序。这些问题在LabVIEW中则不存在。甚至一个初学者都可以设计一个高度并行的应用程序，而且无需额外的努力或知识就可 以自动地将它扩展至多个紧密连接的处理器。

数据流一直被倡导为一个用于商业应用程序的设计工具。它被改进为一种备选的计算机体系结构来避免冯·诺依曼（von Neumann）瓶颈。数据流分析是优化编译器的核心。为什么应用程序不使用数据流？一个数据流的自然表示是一个图形或图表，因此在鼠标和计算机图形产生之前，它几乎是不实际的；一个数据流图的文本描述与对一个街道地图的文本描述类似，既耗时又容易产生错误。但是现在，计算机速度不断加快，存储容量不断增长，计算机屏幕不断加大，直接进行交 互式的数据流图编辑是十分简单的。

有时当显示一个LabVIEW程序流图时，我听到一个问题，“代码在哪里？”，似乎如果不生成文本代码那么图表就是不真实的。我不得不惊叹于我们整个工业是如何成功地让世界确信：我们对传统编程工具的限制实际上是一个优点。事