LabVIEW 的哪些具体功能令您感到沮丧？
请耐心听我说：这不是语言辩论或火焰。 这是一个真正的意见征求。
有时，我必须帮助教育传统文本编码人员如何在 LabVIEW (LV) 中进行思考。 经常在这个过程中，我听到LV有多烂。 除了“X 语言真是好得多！”之外，这种洞察很少伴随着理性的观察。 虽然这个说法让他们感到满意，但这并不能帮助我理解是什么让他们感到沮丧。
那么，对于那些拥有 LabVIEW 和文本语言经验的人来说，LV 的哪些具体事情会让您抓狂呢？
------ 摘要 ----------
感谢您的所有回答！ 有些问题在下面的评论中得到了解答，有些存在于其他网站上，有些只是 LV 的真正问题。 本着最初问题的精神，我不会尝试在这里回答所有这些问题：检查 LAVA 或NI 的网站，您会惊喜地发现有很多问题是可以克服的。
- 无意识的并发
- 无法访问传统的文本操作工具
- 仅二进制源代码控制
- 难以分支和合并 打开
- 的窗口太多
- 文本具有更清晰/更清晰/更具表现力的语法
- 干净的编码需要大量时间和操作
- 大型且难以访问 API/调色板系统
- 需要鼠标
- 文件命名空间：内存中没有同名的重复文件
- LV 对象本身只是按值
- 计算 需要开发环境来查看代码
- 缺乏缩放
- 启动缓慢
- 内存猪
- “巨型”代码很难工作，
- UI 锁定很容易 字符串
- 触控板和 LV 不能很好地混合在一起
- 操作在图形上显得臃肿
- 有限的 UI 定制
- “隐藏”原语（是的，这些存在）
- 缺乏官方元编程能力（不过不会太久）
- 缺乏 unicode 支持
Please bear with me: this isn't a language debate or a flame. It's a real request for opinions.
Occasionally, I have to help educate a traditional text coder in how to think in LabVIEW (LV). Often during this process, I get to hear about how LV sucks. Rarely is this insight accompanied by rational observations other than "Language X is just so much better!". While this statement is satisfying to them, it doesn't help me understand what is frustrating them.
So, for those of you with LabVIEW and text language experience, what specific things about LV drive you nuts?
------ Summaries -------
Thanks for all the answers! Some of the issues are answered in the comments below, some exist on other sites, and some are just genuine problems with LV. In the spirit of the original question, I'm not going to try to answer all of these here: check LAVA or NI's website, and you'll be pleasantly surprised at how many of these things can be overcome.
- Unintentional concurrency
- No access to tradition text manipulation tools
- Binary-only source code control
- Difficult to branch and merge
- Too many open windows
- Text has cleaner/clearer/more expressive syntax
- Clean coding requires a lot of time and manipulation
- Large, difficult to access API/palette system
- Mouse required
- File namespacing: no duplicate files with the same name in memory
- LV objects are natively by-value only
- Requires dev environment to view code
- Lack of zoom
- Slow startup
- Memory pig
- "Giant" code is difficult to work with
- UI lockup is easy to do
- Trackpads and LV don't mix well
- String manipulation is graphically bloated
- Limited UI customization
- "Hidden" primitives (yes, these exist)
- Lack of official metaprogramming capability (not for much longer, though)
- Lack of unicode support
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（19）
LabVIEW 使实现并发/并行编程变得更容易，这是事实。 然而，它并没有使调试、测试或思考并发/并行变得更加容易。 您仍然可以在 LabVIEW 中编写有缺陷的并发代码，并且（与任何语言、平台或工具集一样）没有任何灵丹妙药或魔杖可以使并发“正常工作”。
如果有的话，您必须更加小心并发性，因为如果您不明确考虑（并声明）它，LabVIEW可能会使事情发生您不期望的并发情况。
其他牛肉：这不是文字。 以有意义的方式表示数据流意味着使用图形语言，这意味着您无法使用我们几十年来使用的工具来操作文本，从 sed 到 emacs。 这也意味着源代码控制应用程序必须将您的代码视为不透明的二进制文件，而不是...源代码。 这反过来又使得分支和合并成为一项痛苦的工作。
LabVIEW makes implementing concurrency/parallel programming easier, true. It does not, however, make debugging, testing, or thinking about concurrency/parallelism any easier. You can still write buggy, concurrent code in LabVIEW, and (as with any language, platform, or toolset) there's no silver bullet or magic wand that makes concurrency "just work".
If anything, you have to be more careful about concurrency, because if you don't think about (and declare) it explicitly, LabVIEW may make things concurrent that you weren't expecting to be.
Other beefs: It's not text. Representing dataflow in a way that makes sense means a graphical language, which means you can't use the tools that we've had for decades to manipulate text, everything from sed to emacs. It also means that source code control apps have to treat your code as opaque binaries, instead of as...source code. This, in turn, makes branching and merging an exercise in pain.
我在很多方面都很欣赏 LabView，尤其是轻松驱动硬件的能力（当然，当它是 National Instruments 的硬件时）以及并发编程功能。 但是，在代码导航中，这与基于文本的编程语言相比很糟糕：
if error return； 否则做一些事情代码。I appreciate LabView in many ways, especially the ability to easily drive hardware (well, when it's National Instruments' hardware, of course), and the concurrent programming features. But is sucks against text-base programming languages in code navigation:
if error return; else do stuffcode.Labview 非常适合控制硬件。 我编写了几个 Labview 应用程序，用于收集数据（来自各种传感器的模拟电压）和控制硬件（主要是压电电机）。 Labview 使得并行执行多个任务变得相当容易。
现在回答你的问题。 Labview 让我感到沮丧的是什么？
花时间组织框图
也许，因为我是自学成才，所以我花了太多时间试图清理电线并试图跟踪它们，试图破译它们携带的数据以及它们的去向。
我应该能够使用参数输入我需要的函数/方法的名称并开始，而不是......
但是可能有一种更有效的方法来使用 Labview，我只是不知道！
Labview is great for controlling hardware. I have written several Labview apps for collecting data (analog voltage from various sensors) and control hardware (mostly piezoelectric motors). Labview makes it fairly easy to perform several tasks in parallel.
Now to answer your question. What do I find frustrating about Labview.
Time spent organizing block diagram
Perhaps, since I am self taught I spend too much time trying to clean up wires and trying to follow them in an attempt to deciphers what data they are carrying and where it is going.
I should just be able to type the name of the function/method I need with the parameters and get going instead of...
But there probably is a more efficient way to work with Labview, I just don't know it!
1.LabVIEW对象不是通过引用传递的。
2.不存在其他查看器（尤其是免费的）来查看框图。
3.需要打开大量窗口来查看一个项目。 希望它是 MDI，以便减少窗口数量。
1.LabVIEW objects are not passed by reference.
2.No other viewer exist(especially free one) for viewing the block diagrams.
3. Need to open up a large number of windows to view a project. Would like it to be MDI so that number of windows gets reduced.
最令我沮丧的是，它让我的手离开了键盘。 我是一名盲打打字员，可以相当快地用文本语言编写代码。 LabVIEW强制您使用鼠标从菜单中选择VI和程序节点，并将节点连接在一起。 如果您是一名电气工程师，习惯于在图形环境中设计电路，那么这确实非常快速和方便，但如果您习惯于输入代码，那么这会很痛苦。
披露：自从我上次使用 LabVIEW 以来已经过去了大约两年，所以接下来的两个问题现在可能已经修复了。
下一个烦恼是源代码控制。 您最常使用源代码控制存储库执行的操作之一是将当前版本与以前的版本进行比较以查找更改。 使用 LabVIEW 这样的图形语言无法做到这一点。 CVS 和 SVN 等流行的版本控制系统在幕后使用基于文本的差异工具。 我希望 National Instruments 能够为所有仍在使用 LabVIEW 的人提供他们自己的版本控制解决方案。
我最后的烦恼是缺乏真正的面向对象语言功能。 我使用的最后一个版本 LabVIEW 6i 充其量是基于对象的。 没有人能够真正准确地宣称它是面向对象的。 我无法使用继承创建真正的类层次结构，并且多态性仅保留给少数内置类型。 我意识到 6i 是两个版本之前的版本，所以我真的希望这个问题能够得到解决。
The thing I was most frustrated with was that it took my hands off the keyboard. I'm a touch typist, and can code fairly quickly in a text language. LabVIEW forces you to use the mouse to select VIs and program nodes from its menus, and to wire the nodes together. While this is really fast and convenient if you're an electrical engineer, used to designing circuits in a graphical environment, it's a pain if you're used to typing in your code.
Disclosure: It's been about two years now since I last used LabVIEW, so these next two may be fixed by now.
The next annoyance was source control. One of the things you do most often with your source control repository is diff your current version with a previous version to find the changes. You can't do that with a graphical language like LabVIEW. Popular revision control systems like CVS and SVN use text-based diff tools behind the scenes. I hope National Instruments has come up with their own revision control solution for all of you guys who are still using LabVIEW.
The last annoyance I had was a lack of real object-oriented language features. LabVIEW 6i, the last version I used, was object-based at best. No one could really make an accurate claim that it was object-oriented. I couldn't create a real class hierarchy using inheritance, and polymorphism was reserved for only a few built-in types. I realize that 6i was two versions ago, so I really hope that this is fixed.
GUI 中缺乏 Unicode 支持
这使得我们日本公司的开发变得困难。
更新： 8.6 显然有一些支持。 请参见在 LabVIEW 中使用 Unicode 的提示和工具列表。
Lack of Unicode support in the GUI
It makes development for our Japanese company difficult.
Update: there is some support in 8.6 apparently. See A List of Tips and Tools for using Unicode in LabVIEW.
疼痛。
必须调整更大的显示器的大小。
东西（也许我还没有弄清楚
Labview的多线程潜力
还）
太可怕了（别忘了小
监控问题）。
英亩的空间（有一个函数
方程的节点，为什么不是正则表达式
用于字符串操作的节点？）
我找不到其他人的代码
菜单中的任何位置。
我想补充一点，我认为 Labview 非常强大且设计精良。 我很少遇到让我希望我有一种不同的语言的事情。
pain.
a bigger monitor have to be resized.
stuff (maybe i havent figured out the
multithreading potential of labview
yet)
is horrible, (dont forget the small
monitor issue).
acres of space (there is a function
node for equations, why not a regex
node for string manipulation?)
other peoples code that i cannot find
anywhere in the menus.
i would like to add that i think labview is remarkably powerful and well designed. very rarely do i run into something that makes me wish i had a different language.
无法放大和缩小框图。 是的，设计应该保持在单个屏幕上或仅在一个方向上滚动，但我从第三方供应商那里获得了代码，他们必须使用 50 英寸显示器进行开发 - 代码在各个方向上永远持续！
(2009 年 1 月 23 日)：使用视图->导航窗口查看整个图表（前面板和图表面板）的鸟瞰图。 当 LabVIEW 决定将从程序框图创建的新控件放置在前面的随机位置时，这可能很有用。
Not being able to zoom in and out of the block diagram. Yes, designs should be kept to a single screen or scrolled in only one direction but I've gotten code from 3rd party vendors who must be using 50 inch monitors to develop on -- the code goes on forever in every direction!
(23 Jan 2009): Use View->Navigation Window to see a bird's eye view of the entire diagram (front and diagram panels). This could be useful when LabVIEW decides to put a new control created from the block diagram in a random location on the front.
缺乏 Diff 和 Merge（“专业”许可证除外）
我们在工作中使用 SVN 和 TortoiseSVN。 我很沮丧，因为我无法进行比较来查看文件中发生了什么变化。 使用 SVN 时，进行“比较”是日常工作流程的一部分，因此看到文件发生更改是令人沮丧的，但不知道它是微不足道的还是实质性的。 进行差异还可以对更改进行系统审查。
我听说“专业”有某种差异工具。 不过，我很难说服管理层我们需要专业人员来实现“差异”功能。 而且我还没有得出结论，它实际上与 TortoiseSVN 顺利集成。
源代码控制的使用被认为是业界最佳实践之一，因此 NI 最好能够全面支持它，而不仅仅是在“专业”许可证中，以免人们认为 NI 正在阻碍最佳实践的采用。
Lack of Diff and Merge (except for "professional" license)
We use SVN and TortoiseSVN at work. I'm frustrated that I can't do a diff to see what has changed in a file. Doing "diffs" is part of the daily workflow when using SVN, so it's frustrating to see that a file has changed, but have no idea whether it was something trivial or substantial. Doing diffs also enables a systematic review of changes.
I hear "professional" has some sort of diff tool. I'll have trouble convincing management that we need professional for a "diff" feature though. And I haven't been able to read conclusively that it actually integrates smoothly with TortoiseSVN.
Use of source control is considered one of the industry best-practices, so it would be great for NI to fully support it, not just in the "professional" license, lest NI be seen to be inhibiting adoption of best-practices.
就我个人而言，我认为 LabView 就其设计用途而言是一个出色的程序。 除了继承糟糕的代码（这在任何语言中都是一个问题）之外，通过良好的实践，它可以非常高效且快速地将各种过程控制、自动化、测试和测量系统组合在一起。 与文本编码一样，LabView 也存在良好的实践 - 如果您有一个混乱的 VI，那么这实际上是编码器的错误，而不是语言的错误。 文本编码语言也可能变得非常混乱——程序员有责任不创建不必要的混乱或混淆的代码。
如果您在开始编写代码时就考虑到了未来的扩展，那么创建可以随着程序的需求而增长而不会变得麻烦的 VI 一点也不困难。 就像糟糕的文本代码一样，如果你以短期的眼光来破解它，那么它很快就会变得一团糟，只会让它自我成长并变得难以维护。 然而，这确实意味着您必须花时间学习 LabView，就像您必须花时间学习任何语言或 IDE 一样。
如果 LabView 阻碍了您的努力，您可能应该使用其他东西来创建程序，或者至少应该使用其他东西来创建程序的这些组件。
例如，如果您需要进行大量字符串处理（比使用 LabView 的字符串函数更方便），但您确实想要或需要使用 LabView 来实现应用程序的主要功能，那么您有很多选择。 您可以轻松地使用 C 语言或任何您喜欢的语言编写 DLL，然后通过 LabView 的 DLL 接口访问这些函数。 这适用于任何难以使用基本 LabView 工具实现的高级或抽象函数。
这有两大优点 - 首先，您可以将文本编码集中于简单地编写函数或过程。 围绕您的功能构建应用程序的任务变得不存在。 通过将其与 LabView 混合，您可以获得 LabView 快速而强大的 UI 构建器和仪器连接的第二个优势。
在源代码控制方面，您能做的最重要的事情就是发挥 LabView 固有的模块化能力。 虽然您没有文本工具来帮助您，例如在尝试整理未知的继承代码时，但它确实具有其他非常强大的功能，这些功能以抽象的方式可以完成许多相同的事情。 它可能是现有的最容易重构的语言，这意味着，一般来说，重构继承的代码可以在您学习它的作用时完成。
例如，如果您转到数据源并断开线路，您会立即看到它连接到的所有内容。 错误列表将为您提供由于依赖该数据源而损坏的所有内容的完整列表，您可以立即创建包和集群来清理 LabView 意大利面。 它甚至会突出显示后面板上损坏的数据连接，以便您可以追踪所有内容的去向。 如果很明显子VI中的内容在主进程中乱七八糟等，那么您可以快速将它们封装在子VI中。当您弄清楚代码的用途时，它会变得整洁干净，并且突然可以重新维护。
最大的例外是程序使用了很多不必要的全局变量。 令人惊讶的是，LabView 中的全局变量也使事情变得复杂。 在这种情况下，除了咒骂那个把你弄得一团糟的混蛋之外，别无他法。 尽管如此，这还不是世界末日。
简而言之，我想表达的是 LabView 是一种非常不同的语言。 如果这看起来令人沮丧，那并不是因为没有工具可以完成您在文本编码中习惯的事情，而是因为它们通常以完全不同的方式实现。 例如，Grepping 代码本身并不是目的，而只是达到目的的一种手段 - 目的是发现整个程序中的链接和引用。 虽然您无法 grep LabView 代码，但您可以发现链接和引用 - 只是以完全不同的方式完成。 学习曲线的东西。
Personally, I think LabView is an excellent program for what it is designed to do. Aside from inheriting terrible code, which is a problem in any language, with good practice it is very efficient and quick for putting together all sorts of process control, automation, test, and measurement systems. Like text coding, good practice with LabView exists as well - if you have a scrambled, messy VI then it's really the fault of the coder and not the language. Text-coded languages can get very scrambled as well - the onus is on the programmer to not create unnecessarily messy or obfuscated code.
If you start writing your code with future expansion in mind then it's not difficult at all to create VIs which can grow with the needs of program without becoming cumbersome. Just the same as bad text code can quickly become a mess if you hack it out with a short-term view, only to have it outgrow itself and become unmaintainable. It does mean, however, that you have to take the time to learn LabView, just the same as you have to take the time to learn any language or IDE.
Chances are that if LabView is frustrating your efforts you probably should be using something else to create your program, or at least something else for those components of the program.
For example, if you need to do a lot of string handling - more than is convenient to hack through with LabView's string functions - but you really want or need to use LabView for the meat of your application, then there are many options open to you. You can easily code DLLs in something like C or whatever your favourite language is and then access those functions through LabView's DLL interface. This goes for any sort of high-level or abstract function which is awkward to implement with the basic LabView tools.
This has two big advantages - first you can focus your text coding to simply writing functions or procedures. The task of building the application around your functions becomes non-existent. By blending it with LabView, you gain the second advantage of LabView's quick and powerful UI builder and instrumentation connectivity.
In terms of source control, the biggest thing you can do is to flex LabView's inherent capacity for modularity. While you don't have text tools to help you, for example when trying to sort out unknown inherited code, it does have other very powerful features which, in an abstract way, can do many of the same things. It's probably the easiest language in existence to refactor, which means that, in general, refactoring inherited code can be done WHILE you are learning what it does.
If you go to a data source and break the wire, you instantly see everything that it was connected to, for example. The error list will give you a complete list of everything that broke due to a dependency on that data source and you can straight away work away at creating bundles and clusters to clean up the LabView spaghetti. It even highlights the broken data connections on the back panel so you can trace where everything goes. You can quickly encapsulate things in subVIs if it's clear they are littering the main process with clutter, etc. By the time you've figured out what your code does, it's neat and clean and suddenly re-maintainable.
The big exception to this is if the program used a lot of unnecessary globals. Surprise - globals complicate things in LabView too. In that case, there's nothing to do but curse the schmuck who left you the mess. Still, it's not the end of the world.
I suppose, in short, what I'm trying to say is that LabView is a very different language. If it seems frustrating, it's not because the tools don't exist to do the things you are used to in text coding, but simply that they are often implemented in radically different ways. Grepping code isn't an end unto itself, for example, but only a means to an end - the purpose is to discover links and references throughout the program. While you can't grep LabView code, you can discover links and references - it's just done in an totally different way. Learning curve stuff.
我编写了一个程序（用C++）来从计算机控制rs232设备，但被要求提供labview的驱动程序或Vi或其他任何东西。 我满怀信心地下载了labview，相信我可以在短时间内做出一些成果。 （我是常春藤学校的计算机科学毕业生，已经用 C++ 编程了 15 年，学习并使用了 C、Scheme、C#、Java 等 - 这应该是理所当然的）
我还下载了一个示例应用程序和文档对于labview。
我对这个结果感到震惊。 Labview 庞大、缓慢且不直观。 它不遵循我习惯的 MFC、Visio、Rational Rose 或 VB 等范例。尝试找到正确的文档也是一次艰难的经历。 那里有太多东西，人们需要了解 Labview 才能知道从哪里开始。
这是一个庞大的程序，可以做很多事情。 如果没有人向您展示如何使用它是非常困难的。 我自学了很多东西，但到目前为止我还没有掌握labview。 （当然我没有花太多时间在这上面，但到目前为止这是一次令人沮丧的经历）
总而言之——它很大，很慢而且不直观。 这些文档是压倒性的。
（我仍然对有一天能完成这个项目抱有很大的希望）
I wrote a program (in C++) to control an rs232 device from a computer but was asked to provide a driver or Vi or whatever for labview. I downloaded labview with full confidence that I could bang something out in short order. (I am a comp sci graduate from an ivy school, have programmed in C++ for 15 years, learned and used C, Scheme, C#, Java, etc. - this should be a no-brainer)
I also downloaded a sample app and documentation for labview.
I was horrified at the outcome. Labview is HUGE, SLOW and non-intuitive. It follows none of the paradigms I am used to with either MFC or Visio or Rational Rose or VB, etc. Trying to find the right documentation was also a hard experience. There is just so much out there that one needs to have an understanding of Labview just to know where to begin.
It is a huge program that does so much. Without someone to show you how to use it is very difficult. I self-taught myself many things, but labview so far has eluded me. (granted I have not spent nearly as much time on it as i should, but it was a frustrating experience so far)
To summarize - it is huge, slow and non-intuitive. The docs are overwhelming.
(I still have high hopes one day to finish the project)
最重要的是：
缺乏进行测试驱动开发的工具
如果我可能能说会道的话，现在这已经是一件大事了，因为我不写测试就不会去洗手间。
编辑:: 我收回所有内容，查看 http://forums.jkisoft.com /index.php?showtopic=973 。 到目前为止效果很好！
One item above all others:
Lack of tools to do Test Driven Development
If I maybe glib for a moment, this is pretty big deal now a days since I don't goto the bathroom without writing a test.
EDIT:: I take it all back, check out http://forums.jkisoft.com/index.php?showtopic=973 . So far it works great!
一个功能漏洞：没有元编程工具可言，IIRC。 它非常适合构建东西，只要你构建的任何东西都处于 LV 设计师认为你想要的相同抽象级别。
在过去的 20 年里，我（总体上）已经转向越来越高的抽象层次。 大约一年了，LV很整洁，因为它比我用的略高。 然后我就过去了，LV看起来一年比一年老气。
A feature hole: there's no metaprogramming facilities to speak of, IIRC. It's great for building things, as long as whatever you're building is at the same level of abstraction that the LV designers thought you'd want.
Over the past 20 years, I've moved (generally) to higher and higher levels of abstraction. For about a year, LV was neat, because it was slightly higher than what I was using. Then I blew past it, and LV looks more antiquated every year.
Labview 可用于编写大型、复杂的软件项目。 毫无疑问，Labview 比基于语法的语言使用起来更有趣。 我使用labview编写了数学密集的动态模拟。 较新版本的 Labview 包含许多令人兴奋的功能，特别是在利用多个处理器方面。 我非常喜欢Labview。 但我不推荐给任何人。
不幸的是，对于简单的采集和显示之外的任何事情来说，这绝对是一场噩梦。 有一天，它可能会得到充分发展，被视为基于文本的语言的可行替代方案。 然而，NI 的开发人员始终选择忽略困扰 Labview 的三个基本问题。
1）它不稳定并且充满错误。 Labview 支持论坛上发布了数千个尚未修复的错误。 其中一些问题相当严重，例如内存泄漏或基本函数中的数学错误。
2）文档很糟糕。 通常，当您在本地帮助文件中寻找有关labview函数的帮助时，您会发现一个孤独的句子，它仅仅重申了您试图查找某些详细信息的项目的名称。 例如，用户查找有关纹理过滤模式设置的帮助文件，帮助文件中唯一写入的是“纹理过滤模式-选择用于纹理过滤的模式”。 哎呀，谢谢。 这样事情就清楚了，不是吗？ 问题远不止于此。 通常，当您要求国家仪器公司的技术代表提供有关labview功能或数学函数的特定行为的关键细节时，他们根本不知道自己库中的函数是如何工作的。 这听起来可能有点夸张，但相信我，事实并非如此。
3) 虽然保持图形代码整洁和有据可查并非不可能，但 Labview 的设计目的是使这些任务既困难又低效。 为了防止你的代码变得混乱、混乱，你必须定期（每隔几次操作）使用集群、子可视化和巨型类型定义控件（它们可以在大型项目中跨越多个屏幕）等结构。 这些结构会迫使labview在内存中制作多个数据副本并执行无谓的操作，从而消耗内存并破坏性能——所有这些都是为了防止图形看起来像彩虹色的意大利面条，看不到任何注释或文本。 在labview中编程就像和魔鬼玩图画书一样。 想象一下，您的巨型软件项目被写成一面墙大小的流程图，上面根本没有任何文字。 现在想象一下，所有的线都相互交叉一千次，因此追踪数据流是完全不可能的。 您刚刚设想了最自然、最有效的 Labview 编程方式。
Labview 很酷。 Labview 随着每个新版本的发布而变得越来越好。 如果美国国家仪器公司不断改进它，有一天它会成为一种伟大的通用编程语言。 目前，作为大型或逻辑复杂项目的软件开发平台，这是一个极其糟糕的选择。
Labview can be used to author large, complex software projects. Labview is unquestionably much more fun to use than a syntax based language. I have programmed mathematically dense dynamic simulations using labview. Newer versions of Labview include alot of exciting features, especially for utilizing multiple processors. I like Labview very much. But I don't recommend it to anyone.
Unfortunately, it's an absolute nightmare for anything other than simple acquisition and display. It may one day be sufficiently developed to be considered as a viable alternative to text based languages. However, the developers at NI have consistently opted to ignore the three fundamental problems that plague labview.
1) It is unstable and riddled with bugs. There are thousands of bugs that have been posted to the labview support forums that are yet to be fixed. Some of these are quite serious, such as memory leaks, or mathematical errors in basic functions.
2) The documentation is atrocious. More often than not, when you look for help with a labview function in the local help file you'll find a lonely sentence that merely restates the name of the item you are trying to find some detail on. e.g. A user looks up the help file on the texture filter mode setting and the only thing written in the help file is "Texture Filter Mode- selects the mode used for texture filtering." Gee, thanks. That clears things right up, doesn't it? The problem goes much deeper than that; quite often, when you ask a technical representative from national instruments to provide critical details about labview functionality or the specific behavior of mathematical functions, they simply don't know how the functions in their own library work. This may sound like an exaggeration, but trust me, it's not.
3) While it's not impossible to keep graphical code clean and well documented, Labview is designed to make these tasks both difficult and inefficient. In order to keep your code from becoming a tangled, confusing mess, you must routinely (every few operations) employ structures like clusters, sub-vis and giant type defined controls (which can stretch over multiple screens in a large project). These structures eat memory and destroy performance by forcing labview to make multiple copies of data in memory and perform gratuitous operations- all for the sake of keeping the graphical diagram from looking like rainbow colored spaghetti with no comments or text anywhere in sight. Programming in labview is like playing pictionary with the devil. Imagine your giant software project written as a wall sized flowchart with no words on it at all. Now imagine that all the lines cross each other a thousand times so that tracing the data flow is completely impossible. You have just envisioned the most natural and most efficient way to program in labview.
Labview is cool. Labview is getting better with each new release. If National Instruments keeps improving it, it will be great one day as a general programming language. Right now, it's an extremely bad choice as a software development platform for large or logically complex projects.
Azim，
您会对 8.6 版本感到满意，它有两个功能可以消除您的挫败感：
清理混乱代码的工具。
但请注意，此工具不应用于干净的代码（熔岩 和 NI 论坛）。
一种使用键盘快捷键选择节点和 VI 的工具，Youtube 上的视频显示了行动迅速下降。 1:07 后，您会看到自动清理工具。
蒂姆，
你的意思是什么
如果您有示例和改进，请告知。
如果您在构建驱动程序时遇到困难，请查看附带的驱动程序（例如万用表）。 尝试找到带有驱动程序的类似仪器并根据需要进行调整，我确信 NI 愿意帮助您或其他人愿意。 将您的问题发送至 LAVA 或 NI 论坛。
LabVIEW使用的不同范式（数据流）可能是并行编程的解决方案（至少NI是这么告诉我们的），Visio不是一种编程语言，很遗憾地告诉大家。 使用初学者书籍（适合所有人的 LabVIEW）是一个很好的开始。
吨
Azim,
you will be happy with version 8.6 that has two features that attack your frustration:
A tool to clean up cluttered code.
However it is noted that this tool should not be used on clean code (LAVA and NI forums).
A tool to select nodes and VIs by using keyboard shortcuts, a video on Youtube shows the quick drop in action. After 1:07 you see the Auto Clean Up tool.
Tim,
What is that you mean by
If you have examples and improvements please let it be known.
If you have troubles building a driver have a look at the shipped drivers (for a multimeter for instance). Try to find a similar instrument with a driver and adjust it as needed, I know for sure NI is willing to help you or others will. Come with your questions to LAVA or NI forums.
The different Paradigm that LabVIEW uses (data-flow) might be the solution to parallel programming (at least that is what NI tells us), Visio is not a programming languange, sorry to break the news. Using a beginners book (LabVIEW for everyone) is a very good start.
Ton
关于LabVIEW“图形差异”的澄清：
LabVIEW不能同时在内存中拥有同名VI的多个副本。
在版本 8.5 之前，这意味着如果我想将 VI.vi 修订版 2 与修订版 1 进行比较，我必须（手动）使用不同的名称创建它的副本，打开它，然后告诉 LabVIEW 将其与我的版本进行比较。原来的。
我的理解是，他们在 8.5 中稍微自动化了这个过程，为您提供了某种 3 路合并工具。
A clarification on LabVIEW's "graphical diffs":
LabVIEW cannot have multiple copies of a VI with the same name in memory simultaneously.
Until version 8.5, this meant that if I wanted to diff My VI.vi revision 2 against revision 1, I had to (manually) create a copy of it with a different name, open that, and then tell LabVIEW to compare it with my original.
My understanding is that they automated this process somewhat in 8.5, to give you a 3-way merge tool, of sorts.
我是 LabVIEW 新手。 类似 Photoshop（空格键按住、左键单击并拖动）的鼠标平移功能将非常直观。
I'm new to LabVIEW. A Photoshop-like (spacebar hold, left click and drag) mouse panning feature would be very intuitive.
难以分支和合并： diff 在隔离更改方面做得不好，案例结构中的一个案例的微小变化可能会给您带来许多“差异”。 据我所知，合并必须手动完成。
构建简单的逻辑很耗时：我发现简单的逻辑可能需要大量的接线和绘图，一旦你想改变它，你就必须重新绘制所有内容。
Difficult to branch and merge: The diff does not do a good job in isolating the changes, a small change in one case in a case structure may give you many "differences". Merge have to be done manually as far as I know.
Time consuming to build simple logics: I find simple logics may take lots of wiring and drawing, once you want to change it, you have to redraw everything.
在Labview中，如果不先打开VI的调用者，我就找不到它们。
In Labview I can't find the callers of VI if they are not opened first.