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

C(++)：

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

LabVIEW

• 可视化程序流程(块和连线，而不是代码行)更容易
• 更容易教授(据称...)
• "编程的未来是图形化的。" (也这样觉得？)
• 更接近某些新成员可能拥有的Robolab背景。
• 无需密切了解发生了什么。只需告诉模块找到红球，就无需知道如何操作。

对于我们来说，这是一个非常困难的决定，而且我们讨论了一段时间。根据每种语言的优点以及经验，我们认为更好的选择是什么？请记住，我们不一定要追求纯粹的效率。我们还希望为程序员的未来编程做好准备。

还：

• 我们认为像LabVEIW这样的图形语言是编程的未来吗？
• 图形语言比文本语言更容易学习吗？我认为他们应该同样具有挑战性地学习。
• 看到我们全心全意地致力于帮助人们学习，我们应该在多大程度上依赖预先编写的模块，以及我们应该尝试自己编写多少？ ("优秀的程序员编写好的代码，优秀的程序员复制出色的代码。"但是，首先值得成为一名优秀的程序员值得吗？)

感谢建议！

编辑：
我想进一步强调这个问题：
团队负责人认为LabVIEW因其易于学习和教学而更好。真的吗？我认为可以很容易地教授C，并且C仍将涉及初学者级的任务。我真的很想听听意见。是否有任何理由使while {}的输入比创建" while box"更困难？程序仅通过ifs和loops进行修改仅逐行地流动是不是很直观，就像程序仅通过ifs和loops进行修改时那样，通过流水线一样直观？

再次感谢！

编辑：
我刚刚意识到这属于"语言辩论"的主题。我希望这是可以的，因为这对于具有特定目标的特定编程分支来说是最好的。如果不是...对不起...

解决方案

回答

这并不能直接回答问题，但是我们可能需要考虑使用解释性语言进行混合的第三种选择。例如，Lua已在机器人技术领域中使用。它快速，轻巧，并且可以配置为以定点数而不是浮点数运行，因为大多数微控制器都没有FPU。 Forth是具有类似用法的另一种选择。

在C语言中编写一个薄的接口层，然后让学生松开解释性的脚本，这应该很容易。我们甚至可以将其设置为允许动态加载代码，而无需重新编译和刷新芯片。这样可以减少迭代周期，并让学生更快地查看结果，从而更好地学习。

我不愿使用像LabVIEW这样的可视工具。我似乎总是碰到不想要或者不想要的东西，就像我想要的那样。因此，我更喜欢用文本代码获得的绝对控制权。

回答

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

就个人而言，我必须问，如果这一切都为我们完成，那么建造机器人的真正乐趣是什么？如果只是在其中放一个"查找红球"模块，然后看它走了吗？我们对自己的成就有何自豪感？就个人而言，我不会有太多。另外，它会教给我们什么编码知识，或者对机器人技术至关重要的软件/硬件接口(非常重要)方面的知识？

我并没有声称自己是该领域的专家，而是问自己一件事：我们认为NASA使用LabVIEW编写火星漫游者代码吗？我们是否认为任何在机器人技术领域真正杰出的人都在使用LabView？

确实，如果我们问我，使用LabVIEW之类的Cookie切割器进行构建的唯一方法就是为我们准备一些后院机器人构建器，仅此而已。如果我们想要的东西可以给我们带来更多类似于行业经验的信息，请构建自己的" LabVIEW"类型的系统。构建我们自己的"找球"模块或者自己的"跟随"模块。这将更加困难，但同时也将变得更加酷。 ：D

回答

National Instruments主持了有关该主题的已发表研究：

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

它专门针对LabVIEW与MATLAB(而不是C)进行比较。

回答

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

LabVIEW非常适合用于原始设计。即从DAQ卡中获取数据并在中间进行一些较小的操作，然后将其显示在屏幕上。但是，编程算法并不容易，我什至建议它更困难。例如，在大多数程序语言中，执行顺序通常使用伪数学符号(即" y = x * x + x + 1")逐行遵循，而LabVIEW将使用不一定遵循的VI来实现彼此(即从左到右)在画布上。

此外，编程是一种职业，而不仅仅是了解编码的技术性。能够有效地寻求帮助/寻找答案，编写可读代码以及使用旧代码都是所有关键技能，而这在诸如LabVIEW之类的图形语言中无疑更为困难。

我相信图形编程的某些方面可能会成为主流，子VI的使用完全体现了编程的"黑匣子"原理，并且还用于其他语言抽象(例如Yahoo Pipes和Apple Automator)，也许将来的某些图形语言也会革命性地改变了我们编程的方式，但是LabVIEW本身并不是语言设计的重大范式转变，但对于流程控制，类型转换，事件驱动的编程，甚至对象，我们仍然有"虽然"。如果将来真的可以用LabVIEW编写，那么C ++程序员将不会遇到太多麻烦。

作为后记，我想说C / C ++更适合于机器人技术，因为毫无疑问，学生将不得不在某个时候处理嵌入式系统和FPGA。底层编程知识(位，寄存器等)对于此类事情而言非常宝贵。

@mendicant实际上，LabVIEW在行业中已被广泛使用，尤其是在控制系统中。授予NASA不太可能将其用于机载卫星系统，但用于太空系统的软件开发则完全是一回事。

回答

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

现在，我必须停止写5页的研究报告，因为对我而言，LabVIEW真是一场噩梦。相反，让我尝试总结一些优点和缺点：

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

LabVIEW专业人士

• 是的，它很容易学习。我们小组中的许多博士似乎已经掌握了足够的技能，可以在几周甚至更少的时间内被黑客入侵。
• 图书馆。这是重点。我们必须针对自己的情况进行仔细调查(我不知道我们需要什么，是否有完善的LabVIEW库，或者是否有其他语言的替代品)。就我而言，例如在Python中找到一个良好，快速的图表库一直是一个主要问题，这使我无法使用Python重写某些程序。
• 学校可能已经安装并正在运行它。

LabVIEW缺点

• 可能太容易学习了。无论如何，似乎没有人真正去学习最佳实践，因此程序很快就变成了一个完整的，无法修复的混乱。当然，如果我们不注意的话，基于文本的语言也一定会发生这种情况，但是IMO在LabVIEW中正确执行操作要困难得多。
• 在LabVIEW中，查找子VI往往存在主要问题(我认为甚至是8.2版之前)。 LabVIEW拥有自己的知道在哪里找到库和子VI的方式，这使得完全破坏软件非常容易。如果没有一个知道如何处理的人，这会使大型项目感到痛苦。
• 使LabVIEW与版本控制一起使用是一件很痛苦的事情。当然可以，但是无论如何我都不要使用内置的VC。查看LVDiff中的LabVIEW diff工具，但甚至不考虑合并。

(最后两点使在一个项目中的团队工作变得困难。在情况下，这很重要)

• 很难对代码进行概述。
• 如果我们将sub-VI用于小任务(就像将一个可执行小任务的功能放在一个屏幕上一样是一个好习惯)，我们不仅可以给它们命名，还必须为每个VI绘制图标其中。在短短几分钟内，这变得非常烦人和繁琐，因此我们非常想不要将内容放入sub-VI。太麻烦了。顺便说一句：制作一个真正好的图标可能需要花费专业时间。尝试为我们编写的每个子VI制作一个独特的，可立即理解的，可识别的图标：)
• 我们将在一周之内拥有腕管。保证。
• @Brendan：听，听！

结束语

至于"我应该编写自己的模块"问题：我不确定。取决于时间限制。如果不需要，不要花时间重新发明轮子。花几天时间编写低级代码，然后意识到我们已经用光了时间，这太容易了。如果那意味着我们选择LabVIEW，请继续使用它。

如果有简单的方法可以将LabVIEW与C ++相结合，我很想听听它：这可能会给我们带来两全其美的感觉，但我怀疑是否存在。

但是请确保我们和团队花时间学习最佳实践。看着对方的代码。互相学习。编写可用的，易于理解的代码。玩得开心！

并请我们原谅我听起来有些前卫，甚至有些古怪。仅仅是LabVIEW对我来说真是一场噩梦:)

回答

看来，如果我们正准备为我们的团队为将来的编程做好准备，那么C(++)可能是更好的选择。用可视化构建块构建的通用编程语言的承诺似乎从未实现，我开始怀疑它们是否会实现。似乎可以解决特定的问题领域，但是一旦尝试解决许多一般性问题，就很难抗衡基于文本的编程语言。

曾经有一段时间我对可执行UML的想法有所了解，但似乎一旦我们摆脱了对象关系和某些流程，UML将是构建应用程序的一种非常痛苦的方式。想象一下，尝试将其全部连接到GUI。我不介意被证明是错误的，但是到目前为止，我们似乎不太可能很快就进行点击式编程。

回答

我认为与文字语言相比，图形语言的表达力总是受到限制。将尝试使用视觉符号(例如REBUS或者手语)进行通信与使用单词进行通信进行比较。

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

但是，在该论点中所隐含的另一场辩论是声明式编程与命令式编程。对于我们确实不需要对完成方式进行细粒度控制的任何情况，声明式通常会更好。我们可以以声明性的方式使用C ++，但是要使它如此，我们需要做更多的准备，而LABView被设计为声明性语言。

一幅图片价值一千个单词，但是如果一幅图片代表一千个不需要的单词并且我们无法更改它，那么在这种情况下，一幅图片就毫无价值。而我们可以使用文字创建数千张图片，指定每个细节，甚至明确地引导查看者的注意力。

回答

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

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

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

我认为编程的过程比实际的编码语言更为重要，因此我们应遵循图形化编程语言的样式准则。 LabVIEW程序框图显示了数据流(数据流编程)，因此尽管我从未遇到任何问题，但应该很容易看到潜在的竞争状况。如果我们有C代码库，则将其构建为dll将允许LabVIEW直接调用它。

回答

哦，天哪，答案很简单。使用LabView。

我已经为嵌入式系统编程了10年，我可以说，如果没有至少几个月的基础架构(非常仔细的基础架构！)，使用LabView的效率将不如第一天。

如果我们要设计要出售并用于军事用途的机器人，请继续使用C，这是一个很好的选择。

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

回答

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

C / C ++等于管理我们自己的内存。我们将在内存链接中畅游，并为它们担心。使用LabVIEW，并确保我们阅读了LabVIEW随附的文档，并注意比赛条件。

学习语言很容易。学习如何编程不是。即使是图形语言也不会改变。图形语言的优点是，比起坐在那里解密一堆文本，更容易看到代码将要做什么。

重要的不是语言，而是编程概念。学会使用哪种语言都没关系，因为我们只需稍作努力就可以使用任何一种语言进行良好的编程。语言来来去去。

回答

你在上高中。我们需要花费多少时间从事该程序？小组中有多少人？他们已经知道C ++或者LabView吗？

从问题中，我看到我们了解C ++，但大多数人都不了解。我还怀疑小组负责人是否足够敏锐，注意到团队中的某些成员可能被基于文本的编程语言所吓倒。这是可以接受的，我们正在读高中，这些人是常态。我觉得普通的高中生比C ++更能直观地理解LabView。我猜想像大多数人一样，大多数高中生都害怕命令行。对我们而言，差异不大，但对他们而言，则是昼夜。

我们可以将相同的概念作为C ++应用于LabView是正确的。每个都有其优点和缺点。关键是为作业选择合适的工具。 LabView是为此类应用程序而设计的。 C ++更为通用，可以应用于许多其他类型的问题。

我将推荐LabView。有了合适的硬件，我们几乎可以立即启动并运行。团队可以花更多的时间让机器人做我们想做的事情，而这正是该活动的重点。

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

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

祝你好运！

回答

我建议我们使用LabVIEW，因为这样可以使我们想要更快，更轻松地完成机器人工作。 LabVIEW就是出于这种考虑而设计的。 OfCourse C(++)是很棒的语言，但是LabVIEW可以做得比其他任何工具都要好。
人们可以在LabVIEW中编写非常好的软件，因为它提供了足够的范围和支持。

回答

两种选择绝对是有好处的。但是，由于领域是教育经验，所以我认为C / C ++解决方案将使学生受益最大。图形化编程将始终是一个选择，但不能以优雅的方式提供功能，这将使它比用于底层编程的文本编程更有效。这不是一件坏事，整个抽象的观点是允许对问题域有新的理解和看法。我相信许多人可能对图形编程感到失望的原因是，对于任何特定程序，从C编程到图形化的增量收益与从汇编到C的收益几乎不一样。

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

回答

The team captain thinks that LabVIEW
  is better for its ease of learning and
  teaching. Is that true?

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

除了图形以外，一个重要的区别是LV是基于需求的(流)编程。我们从结果开始，然后说出达到目标所需要的条件。传统编程往往势在必行(反之亦然)。

某些语言可以同时提供这两种语言。我最近为Lua(Lanes)设计了一个多线程库，该库可用于在其他命令环境中用于基于需求的编程。我知道有成功的机器人主要在卢阿(Lua Oh Six)的卢阿(Crazy Ivan)运行。

回答

我认为是否选择LabVIEW取决于我们是否想学习使用一种通用的语言进行编程以将其作为一种可销售的技能，还是只是想把事情做好。 LabVIEW使我们可以快速高效地完成工作。正如其他人所观察到的那样，它使我们不必神奇地摆脱我们正在做的事情，而且即使我们不这样做，也很可能会造成邪恶的混乱，尽管通常情况下，LabVIEW中不良编码风格的最糟糕的例子通常是受过使用文本语言的经验的人所犯，并且因为他们"已经知道如何编程，该死！"而拒绝适应LabVIEW的工作方式！

当然，这并不意味着LabVIEW编程不是适销对路的技术；只是它不像C ++那样大众化。

LabVIEW使管理并行运行的不同事物变得非常容易，而这可能是在机器人控制情况下发生的。代码中的竞争条件应该是顺序的，这也不是问题(即如果它们是错误的，则说明我们做错了)：有一些简单的技术可确保在必要的情况下使用错误将子VI链接起来，以正确的顺序进行操作连接器或者其他数据，使用通知程序或者队列，建立状态机结构，必要时甚至使用LabVIEW的序列结构。同样，这只是花时间了解LabVIEW中可用的工具以及它们如何工作的一种情况。我不认为必须制作subVI图标是一件好事；我们可以非常快速地创建一个包含几个文本单词的文本，也许带有背景色，这对于大多数用途来说都很好。

"图形语言是未来的方式"是基于错误的二分法的红鲱鱼。有些东西很适合图形语言(例如，并行代码)；其他东西更适合文字语言。我不希望LabVIEW和图形化编程消失或者接管世界。

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

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

回答

在我的应用程序中使用LabVIEW有一个很大的缺点：组织设计的复杂性。作为物理学家，我发现Labview非常适合原型设计，仪器控制和数学分析。没有比LabVIEW更快，更好的结果的语言。我从1997年开始使用LabView。从2005年起，我就完全切换到.NET框架，因为它更易于设计和维护。

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

我现在使用文本语言，并且在维护所有内容方面要好得多。如果将C ++与LabVIEW进行比较，我将使用LabVIEW，但与Cit相比则无法胜出

回答

LabVIEW使我们可以快速入门，并且(如其他人已经说过的那样)拥有一个庞大的代码库，可以进行各种与测试，测量和控制相关的事情。

但是，LabVIEW最大的缺点是，我们会丢失程序员自己编写的所有工具。

代码存储为VI。这些是不透明的二进制文件。这意味着代码实际上不是，而是LabVIEW的。我们不能编写自己的解析器，不能编写代码生成器，也不能通过宏或者脚本进行自动更改。

当我们有一个5000 VI应用程序需要普遍应用一些细微调整时，这很糟糕。唯一的选择是手动遍历每个VI，如果我们错过某个角落某个角落的某个VI的更改，天堂将为我们提供帮助。

是的，因为它是二进制文件，所以我们无法像使用文本语言一样进行差异/合并/补丁。确实，这使得使用多个版本的代码成为可维护性的噩梦。

如果我们正在做简单的事情，或者需要原型设计，或者不打算维护代码，请使用LabVIEW。

如果要进行真实的，可维护的编程，请使用文本语言。我们可能会较慢地上手，但从长远来看，我们会更快。

(哦，如果我们需要DAQ库，NI也会提供C ++和.Net版本。)

回答

LabVIEW的其他优势(除了库)是并发性。这是一种数据流语言，这意味着运行时可以为我们处理并发。因此，如果我们正在执行高度并发的操作，而又不想进行传统的同步，LabVIEW可以为我们提供帮助。

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

回答

免责声明：我没有见过LabVIEW，但是我使用了其他一些图形语言，包括WebMethods Flow和Modeller，大学的动态仿真语言，以及MIT的Scratch :)。

我的经验是，图形语言可以很好地完成编程的"管道"部分，但我积极使用的语言却妨碍了算法学的发展。如果算法非常简单，那就可以了。

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

如果可以使用脚本语言(Python，Ruby，Perl等)控制机器人，那么我认为这是一个更好的选择。

然后是混合选项：

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

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

回答

无论如何，这取决于。

我使用LabVIEW大约已有20年了，做了很多工作，从简单的DAQ到非常复杂的可视化，从设备控件到测试定序器。如果还不够好，我肯定会改了。就是说，我开始使用打孔卡对Fortran进行编码，并在基于Z80的8位"机器"上使用了很多编程语言。语言的范围从汇编程序到BASIC，从Turbo-Pascal到C。

LabVIEW是一项重大改进，因为它具有用于数据采集和分析的大量库。然而，人们必须学习另一种范式。而且我们绝对需要一个轨迹球;-))

回答

我们看过Microsoft Robotics Studio吗？

http://msdn.microsoft.com/zh-CN/robotics/default.aspx

回答

它允许可视化编程(VPL)：
http://msdn.microsoft.com/zh-CN/library/bb483047.aspx
以及C＃等现代语言。
我鼓励我们至少看一下这些教程。

Do you think that graphical languages such as LabVEIW are the future of programming?

我没有关于LabView的任何知识(或者关于C / C ++的很多知识)，但是..

Is a graphical language easier to learn than a textual language? I think that they should be about equally challenging to learn.

不...

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

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

例如，在这个相当复杂的LEGO Mindstroms程序中，很容易理解发生了什么……但是，如果我们希望机器人运行" INCREASEJITTER"块5次，然后向前行驶10秒钟，然后尝试再次增加INCREASEJITTER循环？事情开始变得非常混乱。

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

Seeing as we are partailly rooted in helping people learn, how much should we rely on prewritten modules, and how much should we try to write on our own? ("Good programmers write good code, great programmers copy great code." But isn't it worth being a good programmer, first?)

它使真正酷的事物变得非常容易(3D粒子效果，并通过网络摄像头的像素的平均亮度控制相机)。但是做起来非常简单的事情却非常困难，例如遍历XML文件中的元素或者存储将平均像素值转换为文件。

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

就是说，我会建议我们使用一种专门的基于文本的语言作为进步。例如，对于图形，例如Processing或者NodeBox。它们是"普通"语言(处理是Java，NodeBox是Python)，并带有根深蒂固的非常专业，易于使用(但功能强大)的框架。

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

如果我们键入" FORWARD 1"，然后乌龟向前推动一个盒子，那么与机器人技术有关的甚至是LOGO也是一个很好的介绍。键入" LEFT 90"并旋转90度。我们可以可视化每个指令将执行的操作，然后尝试一下并确认它确实以这种方式工作。

回答

向他们展示光泽的事物，他们将沿途学习从C中学到的有用知识，如果他们感兴趣或者发展到需要"真实"语言的程度，他们将拥有所有知识，而不是遇到语法错误并编译砖墙。

我对Labview(以及Matlab)的抱怨是，如果我们打算将代码嵌入x86以外的任何版本(并且Labview具有将Labview VI置于ARM上的工具)，那么我们将不得不花很多力气解决问题尽你所能，因为它效率低下。

Labview是一个很好的原型制作工具：很多库，易于将块串在一起，也许很难执行高级算法，但是我们可能想要做一个块。我们可以快速完成功能。但是，如果我们认为可以采用该VI并将其放在设备上，那就错了。例如，如果我们在Labview中创建一个加法器块，则有两个输入和一个输出。那的内存使用量是多少？价值三个变量的数据？二？在C或者C ++中，我们知道，因为我们可以编写z = x + y或者x + = y，并且我们确切地知道代码在做什么以及内存情况如何。内存使用量会迅速飙升，尤其是因为(正如其他人指出的那样)Labview是高度并行的。因此，准备抛出比我们认为的问题更多的RAM。并具有更大的处理能力。

回答

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

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

我具有汽车行业的嵌入式背景，现在我从事国防工业。我可以从经验中告诉我们，C / C ++和LabVIEW实际上是具有不同用途的野兽。 C / C ++一直用于微控制器的嵌入式工作，因为它紧凑且编译器/工具易于获得。另一方面，LabVIEW用于驱动测试系统(以及作为定序器的测试台)。我们使用的大多数测试设备均来自NI，因此LabVIEW提供了一个环境，使我们拥有完成工作所需的工具和驱动程序以及所需的支持。

在易于学习方面，有很多C / C ++资源，许多网站都提供了我们可以免费获得的几乎所有内容的设计注意事项和示例算法。对于LabVIEW，用户社区可能不像C / C ++那样多样化，并且需要花费更多的精力来检查和比较示例代码(必须具有正确的LabVIEW版本等)……我发现LabVIEW非常容易选择起步并学习，但是这里有些人提到的麻烦与并行性和其他各种事情有关，在我们意识到它们之前需要一些经验。

段落数量不匹配