为什么人们不将LabVIEW用于数据获取和虚拟化之外的其他目的？

Question

这是一个主观的问题，我希望我不会得到太多的反对票。

LV似乎为传统的基于文本的编程提供了一个很好的图形替代方案。据我所知，它不仅仅是一种虚拟化/数据采集编程语言。尽管如此，它似乎已经将这种范式与其创造者的名字联系在一起。

我的问题出现是因为它似乎没有被广泛用于多用途应用程序。我不是任何类型的LV专家，我更像是一个学习者。我还在适应LV呢。

Answer 1

如果你有National Instruments的硬件，并且想要做一些事情，如采集，绘图和记录数据，Labview是很棒的。

当您开始连接到自定义设备时，模块之间的连接变得复杂起来，必须执行输入和输出到设备的所有字符串操作工作。

在我工作的地方，我们发现我们对不得不制作大量复杂的VI来连接设备感到恼火，于是开始用.NET编写它们，并将它们连接到Labview。

最后，我们放弃了Labview，使用NI测量工作室for Visual Studio为我们提供了所有外观可爱的NI控件(波形图、水箱、仪表、开关等)，并具有C#的灵活性。

总而言之，即使只有几个24英寸的屏幕，有时Labview代码的连接也会变得太复杂，变得不可能对未来的任何更改进行注释、调试和扩展。我建议您查看面向Visual Studio的测量工作室，并使用您最喜欢的.NET语言和漂亮的NI控件。

Answer 2

我在“传统文本编程的图形替代”方面的两次经验非常糟糕。我发现这样的语言使用起来很慢，很难编辑，而且缺乏表现力。调试它们是一场噩梦。而且它们也没有提供真正的优势。

可以肯定的是，我已经很长时间没有看过它了，但我询问过的其他人对它们的看法只有luke热情，所以我从来没有花时间再看一次。再次寻找的理由是欢迎的，并将被带到船上。

Answer 3

Labview可用于编写大型、复杂的软件项目。毫无疑问，使用Labview比使用基于语法的语言有趣得多。我已经使用labview编写了数学密集的动态模拟程序。较新版本的Labview包含许多激动人心的特性，尤其是对于使用多处理器的特性。我非常喜欢Labview。但我不推荐给任何人。

不幸的是，除了简单的获取和显示之外，这绝对是一场噩梦。有一天，它可能会得到充分的发展，被认为是基于文本的语言的一个可行的替代方案。然而，NI的开发人员一直选择忽略困扰labview的三个基本问题。

1)它不稳定，充满了bug。有数以千计的bug已经发布到labview支持论坛，但尚未修复。其中一些问题非常严重，例如内存泄漏或基本函数中的数学错误。

2)文档很糟糕。通常，当您在本地帮助文件中查找labview函数的帮助时，您会发现一句话，它只是重申了您要查找的详细信息项的名称。例如，用户查找有关纹理过滤器模式设置的帮助文件，帮助文件中唯一写入的内容是“纹理过滤器模式-选择用于纹理过滤的模式”。天啊，谢谢。这就把事情搞清楚了，不是吗？问题更深层次；通常，当您要求national instruments的技术代表提供有关labview功能或数学函数的特定行为的关键细节时，他们根本不知道他们自己的库中的函数是如何工作的。这听起来可能有点夸张，但相信我，事实并非如此。

3)虽然保持图形代码干净并有良好的文档记录并不是不可能的，但Labview的设计使这些任务既困难又低效。为了让你的代码不会变得乱七八糟，你必须经常(每隔几次操作)使用像集群、子可视化和巨型定义控件这样的结构(在一个大型项目中，这些控件可以跨越多个屏幕)。这些结构会消耗内存，并通过强制labview在内存中制作多个数据副本并执行不必要的操作来破坏性能-所有这些都是为了防止图形图表看起来像彩虹色的意大利面，看不到任何注释或文本。在labview中编程就像与魔鬼玩pictionary一样。想象一下，你的大型软件项目写成一面墙大小的流程图，上面根本没有文字。现在想象一下，所有的线彼此相交一千次，所以追踪数据流是完全不可能的。您已经设想了在labview中进行编程的最自然、最有效的方法。

Labview很酷。Labview在每个新版本中都变得越来越好。如果National Instruments不断改进它，总有一天它会成为一种通用的编程语言。现在，作为大型或逻辑复杂项目的软件开发平台，它是一个非常糟糕的选择。