我常常听到，乃至有时重视于对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程序流图时，我听到一个问题，“代码在哪里？”，好像假如不生成文本代码那么图表便是不真实的。我不得不惊叹于咱们整个工业是怎么成功地让国际坚信：咱们对传统编程东西的约束实际上是一个长处。实际上，它是一个严峻的缺陷，约束了程序修改器和程序编译器之间的衔接以生成一个简略的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能够被用来创立通用的运用程序吗？肯定能够。
