编程语言之争：LabVIEW还是C语言？

“为什么LabVIEW优于C语言？” 作为LabVIEW产品经理，我被很多次问到这个问题。

老实说，这么提问实际上是错误的。必须要有具体的应用环境，这么提问才有意义（例如，“在这些限制条件下，哪一种语言更适合这个任务？”） 若没有这些细节，这个问题就像为什么面包比面粉好一般无意义。

如果您想创建一个测控系统，不同于C语言等低级语言，使用NI LabVIEW系统设计软件能够帮助您降低风险、节省开支并免除不必要的麻烦。在这里我并非暗示LabVIEW是比C语言“更好”的编程语言——特别是考虑到LabVIEW大部分内容不仅仅由G语言编写，还由C和C语言组成。 恰恰相反，这两种语言各自具有不同的优势，程序员应合理择取才能达到自己的目的。

为什么要把LabVIEW比作面包？

LabVIEW和C语言相比起来就好比面包和面粉的关系。 如果您想做一个三明治，就必须先选用面包。 如果您想做一个蛋糕，先用的自然是面粉。 如果用面粉从头烘烤面包，即昂贵又费时（尤其是当你只想吃些小点心时），但若做的是蛋糕，面粉就必不可少了。 同样的，你会发现，要选择最适合的编程语言并非易事，它归结为使用正确的工具来完成适合的工作。

C语言提供了低级别的控制
当应用资源有限，必须严格管理时，C语言的使用效果更好。 由于C语言是相对低级别的语言，因此，即便是最细微的细节，如内存分配和线程，都必须考虑周全。优秀的程序员能够使用低级别的控制，省去大部分高级别应用带来的间接开销。此外，还能充分利用目标体系构架或主机操作系统属性，实现更高的性能。

正是由于上述原因，NI程序员使用C或C编写了LabVIEW库中的大部分内容。LabVIEW与C语言在文件I/O和分析等操作的运行速度上旗鼓相当，因为这些操作都是基于低级语言编写的，并对LabVIEW支持的不同平台和操作系统进行了优化。

效率Vs控制
有时，若开发人员的效率足够高的话，就无需手动优化代码了。 减少一点控制，借鉴类似问题的解决方案，可极大地促进项目的高质量开发。 编程语言不断朝更高级抽象方向发展，让您更专注于手头的问题，而不是被计算细节所困扰。

LabVIEW: 并行执行和真实I/O
无论使用何种语言，高级系统设计与低级执行都是独立的。
在测控应用中，编程只是系统设计者的任务之一。 工程师很少有时间为了计算和测量硬件，或是操作系统上的改进，去更新或重写旧版本软件。 他们通过获取、处理和呈现真实数据进行改进——而不是去挖掘新方法处理内存分配和线程池。 使用LabVIEW，您可以使用经测试、支持、维护的NI底层代码库来创建应用。 而选择C语言意味着您需要实现、支持和维护自己的底层库，或从供应商处购买（NI提供NI LabWindows/CVI 软件与NI Measurement Studio）

从语法角度来说， C语言指令连续执行的能力非常强，CPU能以最快的速度处理它们。 对于纯粹的数据计算，在执行单一任务且指令相对基本的情况下，C语言非常适用。 而LabVIEW采用的是图形化语法，更适用于有真实时间约束的并行执行任务。

使用LabVIEW，您可以跳过基础构建的步骤，直接进行自定制。

LabVIEW不仅仅是一种编程语言及相关的代码库。 结合使用LabVIEW集成开发环境（IDE）与NI硬件，由此所带来的开发体验是各个部分的总和无法企及的。LabVIEW可以准确识别可用的硬件资源，并以下拉菜单和项目名称显示可用的I/O通道与执行目标。 在编辑过程中，您可以防止或察觉错误的配置，以避免代价高昂、又难以调试的运行时错误。 新一代测量硬件（如NI PXIe-5644R矢量信号收发器）甚至可以允许LabVIEW对其固件进行重新定义，达到传统、不同的编程语言和仪器无法实现的性能水平。

有很多项目都会延期或超预算完成，主要是因为工程师低估了聚集所有资源所需的开销。 若您使用LabVIEW，硬件驱动程序会以与数据分析库相同的格式返回数据，UI小部件则以相同的格式显示技术数据，无需再拼凑不同组件。

到底哪个更好: LabVIEW还是C语言？
这个问题的最佳答案是：“一切皆有可能。” 正如《银河系漫游指南》中所说的， 除非您明确自己的问题或了解正试图解决的问题，否则得到的答案也是无意义的。 对于熟练的用户来说，LabVIEW和C都是非常有用的工具，几乎可以解决任何问题： LabVIEW适用于高级测试、测量和控制应用，而C更容易实现低级计算密集型任务。

若再有人问起LabVIEW好还是C语言好，您就回答一切皆有可能。 这也许是将问题朝着正确的方向引导的唯一途径了。