robotics - 文本与图形编程语言

Question

我是一个高中机器人团队的一员，关于使用哪种语言对我们的机器人进行编程存在一些争论。我们在 C（或者可能是 C++）和 LabVIEW 之间进行选择。每种语言都有优点。

C(++):

被广泛使用的
为未来做好准备（大多数编程职位都需要基于文本的程序员。）
我们可以从去年开始扩展我们的 C 代码库
让我们更好地了解我们的机器人在做什么。

LabVIEW

更容易可视化程序流程（块和连线，而不是代码行）
更容易教（据说......）
“编程的未来是图形化的。” （也这样觉得？）
更接近一些新成员可能拥有的 Robolab 背景。
不需要亲密地知道发生了什么。只需告诉模块找到红球，不需要知道如何。

这对我们来说是一个非常艰难的决定，我们已经争论了一段时间。基于每种语言的这些优点，以及你所拥有的经验，你认为更好的选择是什么？请记住，我们不一定要追求纯粹的效率。我们也希望让我们的程序员为未来的编程做好准备。

还：

您认为 LabVEIW 等图形语言是编程的未来吗？
图形语言比文本语言更容易学习吗？ 我认为他们应该同样具有学习挑战性。
鉴于我们部分植根于帮助人们学习，我们应该在多大程度上依赖预先编写的模块，以及我们应该尝试自己编写多少？ （“优秀的程序员写出优秀的代码，优秀的程序员复制优秀的代码。”但首先成为一名优秀的程序员不值得吗？）

感谢您的建议！

编辑：我想更加强调这个问题：队长认为LabVIEW更好，因为它易于学习和教学。 真的吗？ 我认为 C 可以很容易地教授，初学者级别的任务仍然可以使用 C。我真的很想听听您的意见。 输入 while{} 是否比创建“while 框”更困难？ 程序逐行流动，仅由 ifs 和循环修改，这不是很直观，因为程序流过线路很直观，仅由 ifs 和循环修改！？

再次感谢！

编辑：我刚刚意识到这属于“语言辩论”的主题。我希望它没问题，因为它是关于什么最适合特定的编程分支，有特定的目标。如果不是……对不起……

score 34 · Accepted Answer

在我到达之前，我们的团队（博士科学家，几乎没有编程背景）已经尝试断断续续地实现一个 LabVIEW 应用程序将近一年。代码不整洁，太复杂（前端和后端），最重要的是，它不起作用。我是一个热心的程序员，但从未使用过 LabVIEW。在一位 LabVIEW 大师的帮助下，他可以帮助将我所知道的文本编程范例转化为 LabVIEW 概念，因此可以在一周内编写应用程序。这里的重点是基本的编码概念仍然需要学习，语言，即使是像LabVIEW这样的语言，也只是表达它们的不同方式。

LabVIEW 非常适合用于最初设计的用途。即从 DAQ 卡中获取数据并将其显示在屏幕上，可能需要在两者之间进行一些小的操作。然而，编程算法并不容易，我什至建议它更难。例如，在大多数程序语言中，执行顺序通常是逐行遵循的，使用伪数学符号（y = x*x + x + 1即在画布上。

此外，作为职业的编程不仅仅是了解编码的技术。能够有效地寻求帮助/搜索答案、编写可读代码和使用遗留代码都是关键技能，这在 LabVIEW 等图形语言中无疑更加困难。

我相信图形编程的某些方面可能会成为主流——子 VI 的使用完美体现了编程的“黑盒”原则，并且也用于其他语言抽象，如Yahoo Pipes和 Apple Automator——也许未来的一些图形语言将彻底改变我们的编程方式，但 LabVIEW 本身并不是语言设计的大规模范式转变，我们仍然有while, for, if流控制、类型转换、事件驱动编程，甚至对象。如果未来真的会用LabVIEW来编写，C++程序员跨界就不会有太大麻烦了。

作为附言，我会说 C/C++ 更适合机器人技术，因为学生在某些时候无疑必须处理嵌入式系统和 FPGA。低级编程知识（位、寄存器等）对于这类事情非常宝贵。

@mendicant实际上，LabVIEW 在工业中被大量使用，尤其是用于控制系统。尽管 NASA 不太可能将其用于机载卫星系统，但空间系统的软件开发是完全不同的球类游戏......

score 12 · Accepted Answer

我在我目前工作的研究小组中遇到过类似的情况。这是一个生物物理学小组，我们到处都在使用 LabVIEW 来控制我们的仪器。这绝对是伟大的：很容易组装一个 UI 来控制仪器的各个方面，查看它的状态并保存您的数据。

现在我不得不阻止自己写一篇 5 页的长篇大论，因为 LabVIEW 对我来说是一场噩梦。让我试着总结一些优点和缺点：

免责声明我不是 LabVIEW 专家，我可能会说一些有偏见、过时或完全错误的话 :)

LabVIEW专家

是的，它很容易学习。我们小组中的许多博士似乎已经掌握了足够的技能，可以在几周甚至更短的时间内破解。
图书馆。这是一个重点。您必须根据自己的情况仔细调查（我不知道您需要什么，是否有适合它的 LabVIEW 库，或者是否有其他语言的替代方案）。就我而言，在 Python 中寻找一个好的、快速的图表库一直是一个主要问题，这阻止了我用 Python 重写我们的一些程序。
您的学校可能已经安装并运行了它。

LabVIEW缺点

可能太容易学了。无论如何，似乎没有人真正费心去学习最佳实践，所以程序很快就变成了一个完整的、无法弥补的混乱。当然，如果你不小心的话，基于文本的语言也必然会发生这种情况，但在 IMO 中，在 LabVIEW 中做正确的事情要困难得多。
在LabVIEW中寻找子VI往往存在重大问题（我认为甚至高达8.2版）。LabVIEW有自己的方式知道在哪里可以找到库和子VI，这使得完全破坏您的软件变得非常容易。如果您周围没有知道如何处理此问题的人，这会使大型项目变得痛苦。
让 LabVIEW 与版本控制一起工作是一件痛苦的事情。当然可以，但无论如何我都会避免使用内置的 VC。查看LVDiff以获得 LabVIEW 差异工具，但不要考虑合并。

（最后两点使在一个项目的团队中工作变得困难。这对你来说可能很重要）

这是个人的，但我发现许多算法在视觉编程时不起作用。这是一团糟。
- 一个例子是严格顺序的东西。这很快就会变得很麻烦。
- 很难对代码进行概览。
- 如果您将子 VI 用于小任务（就像制作执行小任务且适合一个屏幕的函数一样，这是一种很好的做法），您不能只给它们命名，而是必须为每个函数绘制图标其中。这只会在几分钟内变得非常烦人和麻烦，所以你很想不把东西放在子 VI 中。这太麻烦了。顺便说一句：制作一个非常好的图标可能需要专业的时间。尝试为您编写的每个子 VI 制作一个独特、立即可理解、可识别的图标 :)
您将在一周内拥有腕管。保证。
@Brendan：听，听！

结束语

至于您的“我应该编写自己的模块”的问题：我不确定。取决于你的时间限制。如果没有必要，不要花时间重新发明轮子。花几天时间编写低级代码然后意识到你已经没有时间了，这太容易了。如果这意味着您选择 LabVIEW，那就去吧。

如果有简单的方法可以将 LabVIEW 和例如 C++ 结合起来，我很想听听：这可能会给您带来两全其美的效果，但我怀疑是否存在。

但请确保您和您的团队花时间学习最佳实践。看对方的代码。互相学习。编写可用的、可理解的代码。并且玩得开心！

请原谅我听起来前卫，也许有点迂腐。只是LabVIEW对我来说是一场真正的噩梦:)

score 9 · Accepted Answer

我认为是否选择 LabVIEW 取决于您是想学习用常用语言编程作为一种有市场的技能，还是只是想完成工作。LabVIEW 使您能够快速高效地完成工作。正如其他人所观察到的那样，它并不能神奇地让您不必了解自己在做什么，而且如果您不这样做，很可能会造成一团糟——尽管有趣的是，LabVIEW中糟糕的编码风格最糟糕的例子是通常是由具有文本语言经验并拒绝适应 LabVIEW 工作方式的人所为，因为他们“已经知道如何编程，该死！”

当然，这并不是说 LabVIEW 编程不是一种有市场的技能。只是它不像 C++ 那样面向大众市场。

LabVIEW使管理并行进行的不同事情变得非常容易，这在机器人控制情况下很可能会发生。应该是顺序的代码中的竞争条件也不应该是一个问题（即，如果它们是，你做错了）：有一些简单的技术可以确保事情在必要时以正确的顺序发生 - 使用链接子VI错误线或其他数据，使用通知器或队列，构建状态机结构，甚至在必要时使用LabVIEW的序列结构。同样，这只是花时间了解 LabVIEW 中可用的工具及其工作原理的一个例子。我不认为必须制作 subVI 图标的抱怨是很好的指导。您可以非常快速地创建一个包含几个文字的文字，可能带有背景颜色，

“图形语言是未来的方式吗”是基于错误二分法的红鲱鱼。有些东西非常适合图形语言（例如并行代码）；其他东西更适合文本语言。我不希望 LabVIEW 和图形化编程要么消失，要么接管世界。

顺便说一句，如果 NASA不在太空计划中使用 LabVIEW ，我会感到非常惊讶。最近有人在 Info-LabVIEW 邮件列表中描述了他们如何使用 LabVIEW 开发和测试波音 787 上由电动机驱动的飞行表面的闭环控制，并给人的印象是 LabVIEW 在飞机的开发中被广泛使用。它还用于大型强子对撞机中的实时控制！

除了 National Instruments 自己的网站和论坛之外，目前获取更多 LabVIEW 信息和帮助的最活跃的地方似乎是LAVA。

score 6 · Accepted Answer

这不会直接回答您的问题，但您可能需要考虑使用解释语言进行混合的第三种选择。例如，Lua 已经用于机器人领域。它速度快、重量轻，并且可以配置为使用定点数而不是浮点数运行，因为大多数微控制器没有 FPU。Forth是另一种用法类似的替代方法。

用 C 语言编写一个薄的接口层应该很容易，然后让学生使用解释脚本来放松。您甚至可以将其设置为允许动态加载代码，而无需重新编译和刷新芯片。这应该会减少迭代周期，并让学生通过更快地看到结果来更好地学习。

我偏向于使用 LabVIEW 等可视化工具。我似乎总是碰到一些不能或不会像我想要的那样工作的东西。所以，我更喜欢通过文本代码获得的绝对控制。

score 6 · Accepted Answer

LabVIEW 的另一个优势（除了库）是并发性。它是一种数据流语言，这意味着运行时可以为您处理并发。因此，如果您正在做一些高度并发的事情并且不想进行传统的同步，LabVIEW 可以帮助您。

未来并不像今天那样属于图形语言。它属于任何能够提出数据流表示（或另一种对并发友好的编程类型）的人，它与图形方法一样简单，但也可由程序员自己的工具解析。

score 4 · Accepted Answer

National Instruments 主持了一项关于该主题的已发表研究：

用于 DSP 教学的图形与文本编程的研究

它专门研究了 LabVIEW 与 MATLAB（而不是 C）。

score 4 · Accepted Answer

我认为与文本语言相比，图形语言的表达能力总是有限的。将尝试使用视觉符号（例如 REBUS 或手语）进行交流与使用文字进行交流进行比较。

对于简单的任务，使用图形语言通常更容易，但对于更复杂的逻辑，我发现图形语言会阻碍。

然而，这个论点中隐含的另一个争论是声明式编程与命令式编程。声明式通常更适合您确实不需要对如何完成某事进行细粒度控制的任何事情。您可以以声明性方式使用 C++，但您需要做更多的工作才能做到这一点，而 LABView 被设计为声明性语言。

一张图片值一千个字，但如果一张图片代表一千个你不需要的单词并且你无法改变它，那么在这种情况下，一张图片是毫无价值的。然而，您可以使用文字创建数千张图片，指定每个细节，甚至明确引导观众的焦点。

score 4 · Accepted Answer

LabVIEW 让您可以快速入门，并且（正如其他人已经说过的）拥有一个庞大的代码库，用于执行各种测试、测量和控制相关的事情。

然而，LabVIEW 最大的一个缺点是你失去了程序员为自己编写的所有工具。

您的代码存储为 VI。这些是不透明的二进制文件。这意味着您的代码真的不是您的，而是 LabVIEW 的。您无法编写自己的解析器，无法编写代码生成器，无法通过宏或脚本进行自动更改。

当您有一个 5000 VI 应用程序需要普遍应用一些小的调整时，这很糟糕。您唯一的选择是手动检查每个 VI，如果您错过某个角落某个 VI 的更改，天堂会帮助您。

是的，因为它是二进制的，所以你不能像使用文本语言那样做差异/合并/补丁。这确实使使用多个版本的代码成为可维护性的可怕噩梦。

如果您正在做一些简单的事情，或者需要原型，或者不打算维护您的代码，请务必使用 LabVIEW。

如果您想做真正的、可维护的编程，请使用文本语言。您可能会较慢开始，但从长远来看，您会更快。

（哦，如果您需要 DAQ 库，NI 也有 C++ 和 .Net 版本。）

score 4 · Accepted Answer

我在这里的第一篇文章 :) 要温柔...

我来自汽车行业的嵌入式背景，现在我在国防工业。我可以根据经验告诉你，C/C++ 和 LabVIEW 是真正不同的野兽，有着不同的目的。C/C++ 一直用于微控制器上的嵌入式工作，因为它结构紧凑，编译器/工具很容易获得。另一方面，LabVIEW 用于驱动测试系统（与测试台一起作为定序器）。我们使用的大多数测试设备都来自 NI，因此 LabVIEW 提供了一个环境，我们拥有工作所需的工具和驱动程序，以及我们想要的支持......

就易于学习而言，有许多 C/C++ 资源和许多网站，这些资源在您免费获得的几乎所有内容上都列出了设计注意事项和示例算法。对于 LabVIEW，用户社区可能不像 C/C++ 那样多样化，检查和比较示例代码需要更多的努力（必须有正确版本的 LabVIEW 等）......我发现 LabVIEW 很容易选择起来学习，但是有些人在这里提到的与并行性和其他各种需要一些经验才能意识到它们有关的麻烦。

那么这一切之后的结论呢？我想说这两种语言都值得学习，因为它们确实代表了两种不同的编程风格，当然值得了解并精通这两种语言。

score 2 · Accepted Answer

天哪，答案太简单了。使用LabView。

我已经为嵌入式系统编程了 10 年，我可以说，如果没有至少几个月的基础设施（非常小心的基础设施！），您将不会像使用LabView的第一天那样高效。

如果您正在设计一个用于出售和用于军事的机器人，请继续并从 C 开始 - 这是一个很好的选择。

否则，请使用允许您在最短的时间内尝试最多品种的系统。那是LabView。

score 2 · Accepted Answer

我喜欢LabVIEW。我强烈推荐它，特别是如果其他人记得使用过类似的东西。普通程序员需要一段时间才能习惯它，但如果你已经知道如何编程，结果会好得多。

C/C++ 等于管理自己的内存。你会在记忆链接中游泳并担心它们。使用 LabVIEW 并确保您阅读了 LabVIEW 附带的文档并注意竞争条件。

学习一门语言很容易。学习如何编程不是。即使它是一种图形语言，这也不会改变。图形语言的优点是更容易看到代码将做什么，而不是坐在那里破译一堆文本。

重要的不是语言，而是编程概念。你学习用什么语言编程并不重要，因为只要稍加努力，你就应该能够用任何语言很好地编程。语言来来去去。

score 2 · Accepted Answer

免责声明：我没有见过 LabVIEW，但我使用过一些其他的图形语言，包括 WebMethods Flow 和 Modeller，大学里的动态仿真语言，呃，麻省理工学院的 Scratch :)。

我的经验是图形语言可以很好地完成编程的“管道”部分，但我积极使用的那些会妨碍算法。如果您的算法非常简单，那可能没问题。

另一方面，我认为 C++ 也不适合您的情况。与有用的工作相比，您将花费更多时间来跟踪指针和内存管理问题。

如果您的机器人可以使用脚本语言（Python、Ruby、Perl 等）进行控制，那么我认为这将是一个更好的选择。

然后是混合选项：

如果您的机器人没有脚本选项，并且您的团队中有一个 C++ 极客，那么请考虑让该极客编写绑定以将您的 C++ 库映射到脚本语言。这将使具有其他专业知识的人更容易对机器人进行编程。绑定将成为社区的好礼物。

如果 LabVIEW 允许，请使用其图形语言将用文本语言编写的模块组合在一起。

score 1 · Accepted Answer

我认为图形语言可能是未来的语言......对于所有那些特设的 MS Access 开发人员来说。纯文本编码人员总会有一席之地。

就个人而言，我不得不问，如果一切都为你完成，那么建造机器人的真正乐趣是什么？如果您只是将“找到红球”模块放在那里并看着它消失？你对自己的成就会有怎样的自豪感？就个人而言，我不会有太多。另外，它会教你什么编码，或者软件/硬件接口的（非常重要的）方面，这对机器人技术至关重要？

我不自称是该领域的专家，但问自己一件事：你认为 NASA 使用 LabVIEW 来编写火星漫游者的代码吗？你认为真正在机器人技术领域有名的人在使用 LabView 吗？

真的，如果你问我，使用 LabVIEW 之类的千篇一律的东西来构建它唯一能让你做好准备的就是成为一些后院机器人建造者，仅此而已。如果您想要一些能给您带来更多行业经验的东西，请构建您自己的“LabVIEW”类型的系统。构建您自己的“找球”模块，或您自己的“跟随路线”模块。这将更加困难，但也将更加酷。:D

score 1 · Accepted Answer

你在高中。你有多少时间在这个程序上工作？你的小组有多少人？他们已经知道 C++ 或 LabView 了吗？

从你的问题中，我看到你知道 C++ 而大多数人都不知道。我还怀疑组长的洞察力足以注意到团队中的一些成员可能会被基于文本的编程语言吓倒。这是可以接受的，你在高中，这些人是常态。感觉普通高中生能比C++更直观的理解LabView。我猜大多数高中生，就像一般人一样，都害怕命令行。对你来说，差别要小得多，但对他们来说，这是白天和黑夜。

您是正确的，相同的概念可以像 C++ 一样应用于 LabView。每个都有其优点和缺点。关键是为工作选择正确的工具。LabView 就是为这种应用而设计的。C++ 更加通用，可以应用于许多其他类型的问题。

我将推荐 LabView。有了正确的硬件，您几乎可以开箱即用地启动并运行。你的团队可以花更多的时间让机器人做你想做的事，这才是本次活动的重点。

图形语言不是编程的未来；多年来，它们一直是为解决某些类型的问题而创建的可用选择之一。编程的未来是远离机器代码的层层抽象。将来，我们会想知道为什么我们一遍又一遍地浪费所有时间来编程“语义”。

我们应该在多大程度上依赖预先编写的模块，以及我们应该尝试自己编写多少？ 你不应该浪费时间重新发明轮子。如果 Labview 中有可用的设备驱动程序，请使用它们。您可以通过复制功能相似的代码并根据您的需要对其进行定制来学习很多东西——您可以了解其他人如何解决类似问题，并且必须先解释他们的解决方案，然后才能将其正确应用于您的问题。如果你盲目地复制代码，让它工作的机会很小。即使您复制代码，您也必须做得很好。

祝你好运！

score 1 · Accepted Answer

我建议你使用 LabVIEW，因为你可以让机器人更快更容易地完成你想做的事情。LabVIEW 就是以这种思想设计的。OfCourse C(++) 是很棒的语言，但 LabVIEW 比其他任何语言都做得更好。人们可以在 LabVIEW 中编写非常好的软件，因为它提供了足够的范围和支持。

score 1 · Accepted Answer

在我的应用程序中使用 LabVIEW 时，我发现一件巨大的不利因素：组织设计的复杂性。作为一名物理学家，我发现 Labview 非常适合原型设计、仪器控制和数学分析。没有任何一种语言可以让您在 LabVIEW 中获得更快更好的结果。我从 1997 年开始使用 LabView。从 2005 年开始，我完全切换到 .NET 框架，因为它更易于设计和维护。

在 LabVIEW 中，必须绘制一个简单的“if”结构，并在图形设计中占用大量空间。我刚刚发现我们的许多商业应用程序都很难维护。应用程序越复杂，阅读起来就越困难。

我现在使用文本语言，我在维护一切方面都做得更好。如果您将 C++ 与 LabVIEW 进行比较，我会使用 LabVIEW，但与 C# 相比，它不会胜出

score 1 · Accepted Answer

一如既往，这取决于。

我使用 LabVIEW 大约 20 年了，做过很多工作，从简单的 DAQ 到非常复杂的可视化，从设备控制到测试序列器。如果还不够好，我肯定会换的。也就是说，我开始用打孔卡编写 Fortran，并在 8 位“机器”上使用了大量编程语言，从基于 Z80 的机器开始。语言范围从 Assembler 到 BASIC，从 Turbo-Pascal 到 C。

LabVIEW 是一项重大改进，因为它具有广泛的数据采集和分析库。然而，人们必须学习另一种范式。你肯定需要一个轨迹球;-))

score 1 · Accepted Answer

我对 LabView（或 C/C++）一无所知，但是..

您认为 LabVEIW 等图形语言是编程的未来吗？

不...

图形语言比文本语言更容易学习吗？我认为他们应该同样具有学习挑战性。

更容易学习？不，但它们更容易解释和理解。

要解释一种编程语言，您必须解释什么是变量（这非常困难）。这不是流程图/节点编码工具的问题，例如 LEGO Mindstroms 编程接口或 Quartz Composer。

例如，这是一个相当复杂的 LEGO Mindstroms 程序- 很容易理解其中的内容......但是如果你想让机器人运行INCREASEJITTER5 次积木，然后向前行驶 10 秒，然后尝试 INCREASEJITTER再次循环？事情很快开始变得混乱..

Quartz Composer 就是一个很好的例子，为什么我认为图形语言永远不会“成为未来”

它使真正酷的东西变得非常容易（3D 粒子效果，相机由网络摄像头像素的平均亮度控制）.. 但做简单的事情却非常困难，比如迭代 XML 文件中的元素，或存储将平均像素值写入文件。

鉴于我们部分植根于帮助人们学习，我们应该在多大程度上依赖预先编写的模块，以及我们应该尝试自己编写多少？（“优秀的程序员写出优秀的代码，优秀的程序员复制优秀的代码。”但首先成为一名优秀的程序员不值得吗？）

对于学习，解释和理解图形语言要容易得多。

也就是说，我会推荐一种专门的基于文本的语言作为进展。例如，对于像Processing或NodeBox这样的图形。它们是“普通”语言（Processing 是 Java，NodeBox 是 Python），其中嵌入了非常专业、易于使用（但功能异常强大）的框架。

重要的是，它们是非常互动的语言，您不必为了在屏幕上显示一个圆圈而写数百行。您只需键入oval(100, 200, 10, 10)并按下运行按钮，它就会出现！这也使它们很容易演示和解释。

更多与机器人相关的东西，甚至像 LOGO 这样的东西都会是一个很好的介绍 - 你输入“FORWARD 1”，乌龟向前行驶一个盒子。输入“LEFT 90”，它会转动 90 度。这与现实非常简单。您可以想象每条指令将做什么，然后尝试并确认它确实以这种方式工作。

向他们展示看起来很闪亮的东西，他们会一路拾起他们从 C 中学到的有用的东西，如果他们有兴趣或进步到他们需要一种“真正的”语言，他们将拥有所有这些知识，而不是遇到语法错误并编译砖墙..

score 0 · Accepted Answer

似乎如果你想让我们的团队为未来的编程做好准备，那么 C(++) 可能是更好的途径。使用可视化构建块构建的通用编程语言的承诺似乎从未实现，我开始怀疑它们是否会实现。似乎虽然它可以针对特定的问题域完成，但一旦您开始尝试解决许多一般性问题，基于文本的编程语言就很难被击败。

有一次，我有点接受了可执行 UML 的想法，但似乎一旦你超越了对象关系和一些流程流，UML 将是构建应用程序的一种非常糟糕的方式。想象一下试图将它全部连接到一个 GUI。我不介意被证明是错误的，但到目前为止，我们似乎不太可能很快进行点击式编程。

score 0 · Accepted Answer

大约 2 年前我开始使用 LabVIEW，现在一直在使用它，所以可能会有偏见，但发现它非常适合涉及数据采集和控制的应用程序。

我们使用 LabVIEW 主要用于进行连续测量和控制气阀和 ATE 外壳的测试。这涉及数字和模拟输入和输出以及信号分析例程和过程控制，所有这些都从 GUI 运行。通过将每个部分分解为子 VI，我们可以通过单击和拖动鼠标来重新配置测试。

与 C/C++ 不完全相同，但使用 Visual BASIC 进行的测量、控制和分析的类似实现似乎很复杂，并且很难通过比较来维护。

我认为编程过程比实际的编码语言更重要，你应该遵循图形编程语言的风格指南。LabVIEW 框图显示了数据流（数据流编程），因此尽管我从未遇到任何问题，但应该很容易看到潜在的竞争条件。如果您有 C 代码库，则将其构建到 dll 中将允许 LabVIEW 直接调用它。

score 0 · Accepted Answer

这两种选择肯定都有优点。但是，由于您的领域是一种教育体验，我认为 C/C++ 解决方案最有利于学生。图形编程将始终是一种选择，但根本无法以优雅的方式提供功能，这使得它比文本编程更有效地用于低级编程。这不是一件坏事——抽象的全部意义在于允许对问题域有新的理解和看法。我相信很多人可能对图形编程感到失望的原因是，对于任何特定的程序，从 C 编程到图形编程的增量收益与从汇编到 C 的编程几乎不同。

图形编程知识肯定会使任何未来的程序员受益。将来可能会有机会只需要图形编程知识，也许您的一些学生可以从一些早期的经验中受益。另一方面，文本方法提供的基本编程概念的坚实基础将使您的所有学生受益，并且肯定是更好的答案。

score 0 · Accepted Answer

队长认为LabVIEW更易于学习和教学。真的吗？

我怀疑这对于任何单一语言或范式都是正确的。LabView 对于具有电子工程背景的人来说肯定会更容易；在其中制作程序是“简单地”拉线。再说一次，这些人也可能已经接触过编程。

除了图形之外，一个重要的区别是 LV 是基于需求的（流）编程。你从结果开始，然后告诉你需要什么来达到它。传统编程往往是命令式的（反之亦然）。

有些语言可以同时提供这两者。我最近为 Lua (Lanes) 制作了一个多线程库，它可用于在其他命令式环境中进行基于需求的编程。我知道有一些成功的机器人主要在 Lua 中运行（ Lua Oh Six 的Crazy Ivan）。

score 0 · Accepted Answer

你看过微软机器人工作室吗？ http://msdn.microsoft.com/en-us/robotics/default.aspx

它允许可视化编程 (VPL)：http: //msdn.microsoft.com/en-us/library/bb483047.aspx 以及 C# 等现代语言。我鼓励你至少看看教程。

score 0 · Accepted Answer

我对 Labview（以及这方面的 Matlab）的抱怨是，如果您计划将代码嵌入 x86 以外的任何东西（并且 Labview 有将 Labview VI 放在 ARM 上的工具），那么您将不得不在这个问题上投入尽可能多的精力尽你所能，因为它效率低下。

Labview 是一个很棒的原型设计工具：有很多库，很容易将块串在一起，做高级算法可能有点困难，但可能有你想做的块。您可以快速完成功能。但是如果你认为你可以把那个 VI 放在一个设备上，那你就错了。例如，如果您在 Labview 中制作一个加法器块，您将有两个输入和一个输出。它的内存使用量是多少？三个变量值的数据？二？你知道在 C 或 C++ 中，因为你可以编写z=x+yorx+=y并且你确切地知道你的代码在做什么以及内存情况是什么。内存使用会迅速飙升，尤其是因为（正如其他人指出的）Labview 是高度并行的。因此，请准备好在问题上投入比您想象的更多的 RAM。以及更多的处理能力。

简而言之，Labview 非常适合快速原型制作，但在其他情况下您会失去太多控制。如果您正在处理大量数据或内存/处理能力有限，请使用基于文本的编程语言，这样您就可以控制发生的事情。

score 0 · Accepted Answer

人们总是将labview与C ++进行比较，“哦，labview是高级别的，它具有如此多的内置功能，尝试通过dfft获取数据并显示数据，在labview中很容易尝试在C ++中”。

误区 1：用 C++ 做任何事情都很难，因为它的级别太低了，而且 labview 已经实现了很多东西。问题是，如果您正在使用 C++ 开发机器人系统，则必须使用 opencv 、 pcl .. 等库，如果您使用专为构建机器人系统（如 ROS（机器人操作系统））而设计的软件框架，您会更加聪明。因此，您需要使用一整套工具。事实上，当您使用时，还有更多高级工具可用，ROS + python/c++ 以及诸如 opencv 和 pcl 之类的库。我使用过 labview 机器人技术，坦率地说，像 ICP 这样的常用算法不存在，它不像你现在可以轻松使用其他库。

误区二：图形编程语言更容易理解吗

这取决于实际情况。当您编写复杂的算法时，图形元素将占用宝贵的屏幕空间，并且很难理解该方法。要理解 labview 代码，您必须阅读从上到下阅读的代码复杂度为 O(n^2) 的区域。

如果你有并行系统怎么办。ROS 实现了基于使用回调实现的订阅者/发布者消息的基于图形的体系结构，并且很容易让多个程序运行和通信。将单独的并行组件分开可以更容易地进行调试。例如，单步执行并行 labview 代码是一场噩梦，因为控制流会从一个地方跳转到另一个地方。在 ROS 中，您没有像在 labview 中那样明确地“绘制出您的架构”，但是您仍然可以在运行命令 ros run rqt_graph 时看到它（这将显示所有连接的节点）

“编程的未来是图形化的。” （也这样觉得？）

我希望不会，labview 的当前实现不允许使用基于文本的方法和图形方法进行编码。（有 mathscript ，但是这非常慢）

它很难调试，因为你不能轻易隐藏并行性。

很难阅读 labview 代码，因为你必须查看这么多区域。

Labview 非常适合数据 aq 和信号处理，但不适用于实验机器人，因为缺少大多数高级组件，如 SLAM（同时定位和映射）、点云配准、点云处理等。即使他们确实添加了这些组件并且它们很容易像在 ROS 中那样集成，因为 labview 是专有的且价格昂贵，它们永远不会跟上开源社区的步伐。

总之，如果labview是机电一体化的未来，我正在改变我的投资银行职业道路......如果我不能享受我的工作，我不妨赚些钱并提前退休......

robotics - 文本与图形编程语言

25 回答 25

LabVIEW专家

LabVIEW缺点

结束语

Related

Reference