关于LabVIEW的一些争论

实上，它是一个严重的缺点，限制了程序编辑器和程序编译器之间的连接以生成一个简单的ASCII流。人们在手拿一个音乐CD之时不会询问文本在哪里。
我们不会拥有或不需要一个CD的文本版本，因为我们拥有可以直接从一个的二进制存储格式（适合于工具）来编辑和播放音乐的工具。视频也是这样。录像机记录和播放视频时无需任何作为中介的文本表示。

因此为什么它不同于编程语言？历史上，拥有一个单独的编辑器和编译器是有必要的，而且最早完成的事情是将它们通过最底层的通用点连接起来，即ASCII字符。随着机器变的越来越大和越来越快，集成开发环境随之出现，但最底层的通用点却仍然存在。例如，一个程序文本缩进形式中的有价值的信息完全被编译器忽略。许多对设计基于语法编辑器的尝试最终都失败了，因为按字符编辑是如此的根深蒂固，以至于不可能达到按结构编辑的更高层次。编译器只是接受使用编辑器直接汇编而成的7位ASCII字符流。我们在制作为人们使用的文本的时候使用不同的字体和颜色及类型，但是却没有尝试将这些方面应用到我们的编程语言编辑器或编译器。

更为有趣的是，一些尝试过图形化和图像式编程模型的研究人员具有相似的有局限性的观点。编辑器生成了编译器所解析的图像。这个2D图像是程序而且它打印在纸上与显示在屏幕上一样容易理解。关于图像是如何构造的知识在编译器开始解析图像之时完全被它忽略。

LabVIEW采取了不用的方式。LabVIEW的数据流图比2D多一点，具有在需要时可弹出的有价值信息，例如接线头，但是不会一直出现而混乱了图表。您可以打印出一个LabVIEW应用程序，但是更容易在LabVIEW中观察和浏览它。编译器并不需要解析图表，因为它已经被解析了。编辑器在图表被交互式构造时就构造了解析树。所有构造图形的用户行为也构造了解析树。传送至编译器或保存在文件中的信息比屏幕上可视的图形更加丰富。因此，从这个角度来说LabVIEW更像VCR模式而不是文本编辑器模式。而且传送到编译器的数据越丰富，编译图表的速度就可能越快，以至于用户几乎可以忽略它正在进行。这就意味着进行改变和试验之间的周期可以非常简短。

编译器的速度只是用户使用LabVIEW感受高效率的众多原因之一。因为编辑器构造了解析树，所以它能够立即给出语法和语义的反馈，从而可以更早、更快的检测和改正错误。

编辑器具有一个丰富的操作集，可以通过直接操作来快速创建详细的用户界面。每个模块或VI都拥有一个用户界面这个事实意味着每一阶段的交互式测试都易于完成，而无需编写任何额外的代码。与传统编程工具相比，在LabVIEW中那些必须在有意义的测试之前完成的应用程序部分更少了，这使得设计过程更加迅速。

甚至图表中的数据类型也易于使用。无需担心存储分配的细节即可安排和操作字符串和数组，这意味着许多错误如丢失或重写内存都不存在。LabVIEW中所有这些能力的最终结果就是极大地提高了效率。许多方面的证据表明相对于传统编程工具效率提高了4到10倍。因此，这可能是导致不将LabVIEW视为一种通用的编程语言的最主要的原因。它是一个更高级的设计工具，从台式机器到嵌入式处理器，再到FPGA。对整个LabVIEW社区 来说简单地将它称之为一种计算机语言也许是不公平的。

概要
随着LabVIEW的不断发展和进化，我们会继续提高效率和性能、扩展功能，并扩展可能在其上应用的目标的数量。然而，我们不会被语言、编辑器、编译器、调试器、设备驱动器等之间的传统界线所限制，因为我们相信通过从基本原理中重新思考这些情形可能在提高性能的同时减少复杂性。而且通过与LabVIEW用户团体紧密合作，我们将会把这些可能变成现实。

所以，结论就是，LabVIEW是一个通用的编程语言吗？不，它的含义远远超越于此。LabVIEW能够被用来创建通用的应用程序吗？绝对可以。