LabVIEW是一种通用的编程语言吗？

作者：美国NI公司 Jeff Kodosky

欢迎访问e展厅 展厅 6 电子测量仪器展厅 万用表, 示波器, 电子测试仪器, 信号发生器, 信号分析仪, ... 我们经常会听到关于LabVIEW的争论，即LabVIEW是一种通用的语言？还是一种用于测量和自动化的特定应用程序的开发环境？一方面，有经验的程序员认为LabVIEW缺乏流行编程语言所具有的特性，但是另一方面，一些用户详细阐述了他们使用LabVIEW所建立的通用应用程序，完全没有使用任何数据采集或分析。 这一调查结果与最近一个对开发者团队的调查结果差不多一致，这个团队中的绝大多数人都认为LabVIEW已具有足够的功能，可以被归为通用语言类。被调查者认为LabVIEW最大的不足是常用的递归和递归式数据类型，以及面向对象的结构，但是这些都不是建立通用应用程序的严重障碍。 错误的问题 尽管有了调查结果，但是这应该是一个错误的问题，而且试图回答它会导致错误的方向。一个较好的问题是：LabVIEW可以被用作通用编程语言吗？或者更好的是：LabVIEW能够被用来创建通用的应用程序吗？ 一些人并不认为LabVIEW是一种编程语言，因为它不是基于文本的而且它不是顺序化的。更为奇怪的是，关于什么被看作是一种编程语言的这个问题上，那些具有计算机科学背景的人持有最为狭隘的观点。 如果工具A和工具B可以被用于一定的任务集，但是工具B具有更多的功能有助于它完成额外的任务，那么哪一种工具是事实上更为通用的呢？这正是我们关于LabVIEW问题。通常，测量和自动化的程序必须处理所有与通用程序一样的问题，如数据结构和算法、文件I/O、网络I/O、用户I/O和数据库存取、打印等等这些常见的问题。而且，测量和自动化程序也必须处理比通用程序更多的问题，例如物理I/O、实时性约束和硬件配置。它们也可以具有一些最为苛刻的用户界面要求。LabVIEW适于测量和自动化应用程序的能力不是因为其基本编程能力受某种方式所限制，而是因为它们经过了增强和扩展。 这就是为什么有必要提出“LabVIEW能够被用来创建通用的应用程序吗？”而不是“LabVIEW是一种通用编程语言吗？”。我们不希望通过把LabVIEW仅视为一种编程语言而限制了它的范围或它将来的发展。LabVIEW不仅仅是一种编程语言。它是一种高度交互式的开发环境，用来快速设计原型和应用程序的渐进式开发，从测量和自动化到实时嵌入式系统，再到通用场合。而且现在LabVIEW具有了对FPGA编程下载的能力，所以LabVIEW也是一个硬件设计工具。 数据流 LabVIEW的核心是结构化的数据流图。数据流已存在了很长一段时间而且深入人心。事实上，它是一个比流行的基于文本语言的控制流更为丰富的计算模型，因为它的本质是并行的，而C/C++和BASIC则不是——它们必须依赖于对操作系统的库函数调用来实现并行机制。因此，编译器不能确保代码的共享部分被适当地保护，这使得它难以建立并行程序。这些问题在LabVIEW中则不存在。甚至一个初学者都可以设计一个高度并行的应用程序，而且无需额外的知识就可以自动地将它扩展至多个紧密连接的处理器。 数据流一直被视为一个用于商业应用程序的设计工具。它被改进为一种备选的计算机体系结构来避免冯·诺依曼（Von Neumann）瓶颈。数据流分析是优化编译器的核心。为什么应用程序不使用数据流？一个数据流的自然表示是一个图形或图表，因此在鼠标和计算机图形产生之前，它几乎是不实际的；一个数据流图的文本描述与对一个街道地图的文本描述类似，既耗时又容易产生错误。但是现在，计算机速度不断加快，存储容量不断增长，计算机屏幕不断加大，直接进行交互式的数据流图编辑是十分简单的。 有时当显示一个LabVIEW程序流图时，我听到一个问题，“代码在哪里？”，似乎如果不生成文本代码，图表就是不真实的。事实上，必须生成文本代码是一个严重的缺点，限制了程序编辑器和程序编译器之间的连接以生成一个简单的ASCII流。人们在手拿一个音乐CD之时不会询问文本在哪里。我们不会拥有或不需要一个CD的文本版本，因为我们拥有可以直接从一个的二进制存储格式（适合于工具）来编辑和播放音乐的工具。视频也是这样。录像机记录和播放视频时无需任何作为中介的文本表示。 传统来讲，拥有一个单独的编辑器和编译器是有必要的，而且最早完成的事情是将它们通过最底层的通用点连接起来，即ASCII字符。随着机器越来越大，速度越来越快，集成开发环境随之出现，但最底层的通用点却仍然存在。例如，一个程序文本缩进形式中的有价值的信息完全被编译器忽略。许多对设计基于语法编辑器的尝试最终都失败了，因为按字符编辑是如此的根深蒂固，以至于不可能达到按结构编辑的更高层次。编译器只是接受使用编辑器直接汇编而成的7位ASCII字符流。我们在制作为文本的时候使用不同的字体和颜色及类型，但是却没有尝试将这些方面应用到我们的编程语言编辑器或编译器。更为有趣的是，一些尝试过图形化和图像式编程模型的研究人员具有相似的有局限性的观点。编辑器生成了编译器所解析的图像。这个2D图像是程序而且它打印在纸上与显示在屏幕上一样容易理解。关于图像是如何构造的知识在编译器开始解析图像之时完全被它忽略。 LabVIEW采取了不用的方式。LabVIEW的数据流图比2D多一点，具有在需要时可弹出的有价值信息，例如接线头，但是不会一直出现而混乱了图表。您可以打印出一个LabVIEW应用程序，但是更容易在LabVIEW中观察和浏览它。编译器并不需要解析图表，因为它已经被解析了。编辑器在图表被交互式构造时就构造了解析树。所有构造图形的用户行为也构造了解析树。传送至编译器或保存在文件中的信息比屏幕上可视的图形更加丰富。因此，从这个角度来说LabVIEW更像VCR模式而不是文本编辑器模式。而且传送到编译器的数据越丰富，编译图表的速度就可能越快，以至于用户几乎可以忽略它正在进行。这就意味着改动和试验之间的周期可以非常短。 编译器的速度只是用户使用LabVIEW感受高效率的众多原因之一。因为编辑器构造了解析树，所以它能够立即给出语法和语义的反馈，从而可以更早、更快地检测和改正错误。编辑器具有一个丰富的操作集，可以通过直接操作来快速创建详细的用户界面。每个模块或VI都拥有一个用户界面，即意味着每一阶段的交互式测试都易于完成，而无需编写任何额外的代码。与传统编程工具相比，在LabVIEW中，那些在有意义的测试之前必须完成的应用程序部分更少了，这使得设计过程更加迅速。甚至图表中的数据类型也易于使用，无需担心存储分配的细节即可安排和操作字符串和数组，这意味着许多错误如丢失或重写内存都不存在。 LabVIEW中所有这些能力的最终结果就是极大地提高了效率。许多方面的证据表明，它相对于传统编程工具效率提高了4－10倍。因此，这可能是LabVIEW不被视为一种通用的编程语言的最主要原因。因为它是一个更高级的设计工具，从台式机器到嵌入式处理器，再到FPGA。对整个LabVIEW社区来说，简单地将它称之为一种计算机语言也许是不公平的。(end)

文章内容仅供参考 (投稿) (7/27/2005)