Textual versus Graphical Programming Languages
我是一个高中机器人团队的一员，关于用哪种语言来编程我们的机器人还存在一些争论。我们在C(或C++)和LabVIEW之间进行选择。每种语言都有优点。
C(++)：
- 广泛应用
- 为将来做好准备(大多数编程职位都需要基于文本的程序员。)
- 我们可以从去年开始扩展我们的C代码库
- 让我们更好地了解我们的机器人在做什么。
虚拟仪器
- 更容易可视化程序流(块和线，而不是代码行)
- 更容易教(据说……)
- "编程的未来是图形化的。"(这样想吗？)
- 更接近一些新成员可能拥有的Robolab背景。
- 不需要密切了解发生了什么。只需告诉模块找到红球，不需要知道怎么做。
这对我们来说是一个非常困难的决定，我们已经争论了一段时间了。基于每种语言的专业知识，以及你的经验，你认为更好的选择是什么？记住，我们不一定追求纯粹的效率。我们也希望为我们的程序员在编程方面的未来做好准备。
也：
- 你认为像LabveIw这样的图形语言是编程的未来吗？
- 图形语言比文本语言更容易学习吗？我认为他们应该同样具有学习的挑战性。
- 既然我们部分地植根于帮助人们学习，我们应该在多大程度上依赖预先编写的模块，以及我们应该在多大程度上尝试自己编写？("优秀的程序员编写好的代码，优秀的程序员复制好的代码。"但首先，作为一名优秀的程序员难道不值得吗？"
谢谢你的建议！
编辑：我想进一步强调这个问题：队长认为LabVIEW更易于学习和教学。是真的吗？我认为C也可以很容易地教，初学者的任务也可以和C一起完成。我真的很想听听你的意见。有没有什么理由比创建"while box"更难输入while？程序一行一行地流动，仅由IFS和循环修改，这不是和程序通过线流动一样直观吗？程序只由IFS和循环修改！？
再次感谢！
编辑：我刚刚意识到这属于"语言辩论"的主题，我希望它是好的，因为它是关于什么对特定的编程分支最好，有一定的目标。如果不是…我很抱歉。。。
在我到达之前，我们的团队(博士科学家，几乎没有编程背景)已经尝试了一年左右的时间来实现LabVIEW应用程序。代码不整洁，太复杂(前端和后端)，最重要的是，无法工作。我是一个热衷于编程的人，但从未使用过LabVIEW。在一个LabVIEW专家的帮助下，他可以帮助我把我所知道的文本编程范例翻译成LabVIEW概念，一周内就可以编写这个应用程序了。这里的要点是，基本的编码概念仍然需要学习，语言，甚至像LabVIEW，只是表达它们的一种不同的方式。
LabVIEW非常适合用于它最初设计的用途。也就是说，从数据采集卡中获取数据并将其显示在屏幕上，可能需要在两者之间进行一些小的操作。然而，编程算法并不容易，我甚至建议它更难。例如，在大多数程序语言中，执行顺序通常是一行接一行的，使用伪数学符号(即
此外，编程作为一种职业不仅仅是了解编码的技术特性。能够有效地请求帮助/搜索答案、编写可读代码和使用旧代码都是关键技能，在LabVIEW等图形语言中无疑更难做到这一点。
我相信图形编程的某些方面可能会成为主流——SUB-VIS的使用完美地体现了编程的"黑匣子"原则，也被用于其他语言抽象，如Yahoo Pipes和Apple Automator——也许未来的一些图形语言会彻底改变我们的编程方式，但LabVIEW本身就是在语言设计上的一个巨大的范式转变中，我们仍然有
作为一个后记，我会说C/C++更适合机器人学，因为学生们无疑需要在某个时候处理嵌入式系统和FPGA。低层次的编程知识(位、寄存器等)对于这种事情将是无价的。
@实际上，在工业界，尤其是在控制系统中，LabVIEW被大量使用。尽管美国宇航局不太可能将其用于卫星系统，但航天系统的软件开发却是一个完全不同的球类游戏……
在我目前工作的研究小组中，我遇到了类似的情况。这是一个生物物理学小组，我们在各地使用LabVIEW来控制我们的仪器。这非常好用：很容易组装一个UI来控制仪器的各个方面，查看其状态并保存数据。
现在我不得不停止写一篇长达5页的文章，因为对我来说，LabVIEW是一场噩梦。让我试着总结一些利弊：
免责声明：我不是LabVIEW专家，我可能会说一些有偏见、过时或完全错误的话：)
LabVIEW PROS- 是的，很容易学。我们团队中的许多博士似乎已经获得了足够的技能，能够在几周内，甚至更少的时间内被攻克。
- 图书馆。这是一个要点。您必须根据自己的情况仔细研究这个问题(我不知道您需要什么，如果有好的LabVIEW库，或者有其他语言的替代品)。在我的例子中，发现一个好的、快速的python图表库是一个主要问题，这阻止了我用python重写一些程序。
- 您的学校可能已经安装并运行了它。
LabVIEW CONS
- 这也许太容易学了。无论如何，似乎没有人真正费心学习最佳实践，所以程序很快就变成了一个完整的、不可修复的混乱。当然，如果你不小心的话，基于文本的语言也会发生这种情况，但是在我看来，在LabVIEW中做正确的事情要困难得多。
- 在LabVIEW中，找到Sub-VIS(我认为，甚至在8.2版之前)往往会有一些主要问题。LabVIEW有自己的方法来知道在哪里可以找到库和子视图，这使得完全破坏软件变得非常容易。如果你身边没有一个知道如何处理这个问题的人，这会让大型项目变得很痛苦。
- 让LabVIEW与版本控制一起工作是一件痛苦的事情。当然可以，但无论如何我都不想使用内置的VC。查看labview diff工具的lvdiff，但不要考虑合并。
(最后两个要点使得在一个项目的团队中工作变得困难。这在你的案件中可能很重要)
- 这是个人的，但我发现很多算法在视觉编程时都不起作用。真是一团糟。
- 一个例子是严格按顺序排列的东西；很快就会变得很麻烦。
- 很难对代码进行概述。
- 如果您对小任务使用Sub-vi(就像让执行小任务的函数适合一个屏幕一样)，那么您不能只给它们命名，而是必须为它们中的每一个绘制图标。这在几分钟内就变得非常烦人和麻烦，所以你很想不把东西放进Sub-vi，这太麻烦了。顺便说一句：制作一个好的图标需要专业的时间。去尝试为你写的每一个子vi制作一个独特的、可立即理解的、可识别的图标：)
- 一个星期内你就有腕管了。放心。
- @布伦丹：听，听！
结束语
至于你的"我应该写我自己的模块"问题：我不确定。取决于你的时间限制。如果你不需要的话，不要花时间在重新发明轮子上。花上几天时间编写低级代码，然后意识到时间已经用完，这太容易了。如果这意味着你选择了LabVIEW，那就去吧。
如果把LabVIEW和C++结合起来的方法很简单，我很想听听：这可能给你两全其美，但我怀疑是否存在。
但要确保你和你的团队花时间学习最佳实践。看着对方的代码。互相学习。编写可用的、可理解的代码。玩得开心！
请原谅我听起来急躁，也许有点学究。只是LabVIEW对我来说真的是一场噩梦：)
我认为LabVIEW的选择取决于你是想学习用一种常用语言编程作为一种有市场的技能，还是只想完成一些事情。LabVIEW使您能够快速高效地完成工作。正如其他人所观察到的那样，这并不能神奇地让你不必理解你在做什么，如果你不理解的话，很有可能造成一个不神圣的混乱——尽管有轶事发生，但在LabVIEW中糟糕的编码风格的最坏例子通常是由有文本语言经验的人所犯，他们拒绝适应LabVIEW的工作方式。因为他们已经知道如何编程了，该死！
这并不意味着LabVIEW编程不是一种可销售的技能，当然，它并不像C++那样是大众市场。
LabVIEW可以非常容易地并行管理不同的事情，在机器人控制的情况下，您可能会遇到这种情况。代码中应该是连续的竞争条件也不应该是一个问题(例如，如果它们是连续的，那么你就错了)：有一些简单的技术可以确保在必要的时候事情按正确的顺序发生-使用错误线或其他数据，使用通知程序或队列，构建状态机结构，甚至使用如有必要，LabVIEW的序列结构。同样，这只是一个花时间了解LabVIEW中可用工具及其工作方式的例子。我不认为必须制作Subfi图标的抱怨是很有针对性的；你可以很快地创建一个包含几个文字的图标，可能带有背景色，这对于大多数目的来说都是很好的。
"图形语言是未来的道路"是一个基于错误二分法的红鲱鱼。有些东西非常适合图形语言(例如并行代码)；其他东西更适合文本语言。我不希望LabVIEW和图形编程要么消失，要么接管世界。
顺便说一句，如果NASA不在太空计划中使用LabVIEW，我会非常惊讶。最近有人在信息LabVIEW邮件列表中描述了他们如何使用LabVIEW开发和测试波音787上由电机驱动的飞行表面闭环控制，并给人留下了这样的印象：LabVIEW在飞机开发中被广泛使用。它还用于大型强子对撞机的实时控制！
除了国家仪器公司自己的网站和论坛外，目前最活跃的获取更多信息和帮助LabVIEW的地方似乎是熔岩。
这不会直接回答您的问题，但您可能需要考虑第三种选择，即混合使用解释语言。例如，Lua已经用于机器人领域。它速度快、重量轻，而且可以配置为使用定点数字而不是浮点数字运行，因为大多数微控制器没有FPU。第四种是另一种类似用法的替代方法。
用C语言编写一个很薄的接口层，然后让学生用解释过的脚本来释放它应该很容易。您甚至可以将其设置为允许在不重新编译和刷新芯片的情况下动态加载代码。这样可以减少迭代周期，让学生更快地看到结果，从而更好地学习。
我倾向于使用像labview这样的可视化工具。我似乎总是碰到一些不工作或不工作的事情，就像我想做的那样。所以，我更喜欢文本代码的绝对控制。
LabVIEW的其他优势(除了库)是并发性。它是一种数据流语言，这意味着运行时可以为您处理并发性。因此，如果您正在做一些高度并发的事情，并且不想进行传统的同步，那么LabVIEW可以帮助您实现这一点。
未来不属于现在的图形语言。它属于任何能够提出数据流(或另一种对并发友好的编程类型)的表示的人，这种表示与图形方法一样简单，但也可以由程序员自己的工具进行分析。
我认为，与文本语言相比，图形语言的表现力总是有限的。将试图用视觉符号(例如，反驳或手语)交流与用文字交流进行比较。
对于简单的任务，使用图形语言通常比较容易，但对于更复杂的逻辑，我发现图形语言会阻碍。
然而，这个论点中隐含的另一个争论是声明式编程与命令式编程。声明性通常更适合于那些您真正不需要对某件事情的完成方式进行细粒度控制的事情。你可以用声明式的方式使用C++，但是你需要更多的工作来实现它，而LabVIEW则被设计成一种声明性语言。
一张图片胜过千言万语，但如果一张图片代表了一千个你不需要的单词，而你不能改变它，那么在这种情况下，一张图片是没有价值的。然而，您可以使用文字创建数千张图片，指定每个细节，甚至明确引导观众的焦点。
LabVIEW可以让您快速入门，并且(正如其他人已经说过的那样)有一个庞大的代码库，用于进行各种测试、测量和控制相关的事情。
不过，LabVIEW最大的一个缺点是，您失去了程序员为自己编写的所有工具。
您的代码存储为VIS。这些是不透明的二进制文件。这意味着您的代码实际上不是您的，而是LabVIEW的。您不能编写自己的解析器，不能编写代码生成器，不能通过宏或脚本进行自动更改。
当你有一个5000的vi应用程序需要进行一些小的调整时，这很糟糕。你唯一的选择是手动通过每一个vi，如果你错过了某个角落里一个vi的变化，天堂会帮助你。
是的，因为它是二进制的，所以不能像文本语言那样进行diff/merge/patch。这确实使使用多个版本的代码成为可维护性的可怕噩梦。
无论如何，如果你在做一些简单的事情，或者需要原型化，或者不打算维护你的代码，那么就使用labview。
如果您想进行真正的、可维护的编程，请使用文本语言。开始的时候你可能会慢一些，但从长远来看你会快一些。
(哦，如果你需要DAQ库，NI也有C++和.NET版本。)
关于国家文书主办的主题，有一项已发表的研究：
DSP教学中图形与文本编程的研究
它特别关注labview与matlab(与c相反)。
我在这里的第一个帖子是：)温柔点…
我来自汽车工业的一个嵌入式背景，现在我在国防工业。我可以从经验中告诉你，C/C++和LabVIEW是不同目的的真正不同的动物。C/C++通常被用于微控制器的嵌入式工作，因为它是紧凑的，编译器/工具很容易得到。另一方面，LabVIEW用于驱动测试系统(与测试台一起作为定序器)。我们使用的大多数测试设备都来自NI，因此LabVIEW提供了一个环境，在这个环境中，我们拥有工作所需的工具和驱动程序，以及我们想要的支持。
在学习的方便性方面，有很多的资源用于C/C++，许多网站在免费提供的任何东西上都有设计注意事项和示例算法。对于LabVIEW，用户社区可能不像C/C++那样多样化，并且需要花费更多的努力来检查和比较示例代码(必须有LabVIEW等的正确版本)…我发现LabVIEW很容易理解和学习，但是这里有一些人提到的干扰是与并行性和其他需要一些经验才能意识到的事情有关的。
那么这一切之后的结论呢？我想说，这两种语言都值得学习，因为它们确实代表了两种不同的编程风格，而且这两种语言都值得注意和精通。
天哪，答案很简单。使用LabVIEW。
我已经为嵌入式系统编程10年了，我可以说，如果没有至少几个月的基础设施(非常小心的基础设施！)，您将不会像第一天使用LabVIEW时那样富有成效。
如果你正在设计一个出售并用于军事的机器人，那就从C开始吧——这是一个很好的选择。
否则，请使用允许您在最短时间内尝试最多样性的系统。那是LabVIEW。
免责声明：我没有看到LabVIEW，但我使用了其他一些图形语言，包括WebMethods Flow和Modeller、大学的动态模拟语言以及麻省理工学院的scratch:。
我的经验是图形语言可以很好地完成编程中的"管道"部分，但是我使用的那些语言会妨碍算法。如果你的算法很简单，那就可以了。
另一方面，我认为C++对你的情况也不好。您将花费比在有用的工作上更多的时间来跟踪指针和内存管理问题。
如果您的机器人可以使用脚本语言(python、ruby、perl等)进行控制，那么我认为这将是一个更好的选择。
还有混合动力的选择：
如果你的机器人没有脚本选项，你的团队中有一个C++ GEKE，那么就考虑使用GEK写绑定来将C++库映射成脚本语言。这将使其他专业的人更容易对机器人进行编程。这些捆绑物将是对社区的一个很好的礼物。
如果LabVIEW允许，可以使用它的图形语言将用文本语言编写的模块垂直放置在一起。
我认为图形语言可能是未来的语言……对于所有那些临时的MS访问开发人员来说。总是会有一个纯文本编码人员的位置。
就我个人而言，我得问一个问题，如果所有这些都是为你做的，那么制造一个机器人真正的乐趣是什么？如果你把一个"找到红球"模块丢在那里，看着它走？你对自己的成就有什么自豪感？就个人而言，我不会有太多。另外，它将教你什么编码，或者是在机器人技术中至关重要的软件/硬件接口的(非常重要的)方面？
我并不是说我是这个领域的专家，但问问你自己一件事：你认为美国宇航局用LabVIEW对火星漫游者进行编码吗？你认为机器人界真正杰出的人使用LabVIEW吗？
真的，如果你问我，唯一使用像LabVIEW这样的cookie切割工具来构建它的方法就是准备一些后院机器人构建器，而不是其他东西。如果你想要一些能给你更多的行业经验的东西，建立你自己的"labview"类型的系统。建立你自己的"找到球"模块，或者你自己的"跟着线"模块。这将是更困难，但也将是更酷的方式。D
我喜欢LabVIEW。我强烈推荐它，特别是如果其他记忆使用了类似的东西。普通程序员需要一段时间来适应它，但是如果您已经知道如何编程，结果会更好。
C/C++等于管理你自己的内存。你会沉浸在记忆中，担心它们。使用LabVIEW并确保您阅读了LabVIEW附带的文档，并注意比赛条件。
学习一门语言很容易。学习如何编程不是。即使是图形语言，也不会改变。图形语言的优点是，它更容易看到代码将要做什么，而不是坐在那里破译一堆文本。
重要的不是语言，而是编程概念。学习什么语言编程并不重要，因为只要稍加努力，你就可以很好地用任何语言编程。语言来来往往。
我建议你使用LabVIEW，因为你可以让机器人做你想做的更快更容易。LabVIEW就是这样设计的。当然，C(++)是很好的语言，但是LabVIEW比其他语言做得更好。人们可以在LabVIEW中编写非常好的软件，因为它提供了足够的范围和支持。
总的来说，这要看情况而定。
我从20年前开始使用LabVIEW，做了很多工作，从简单的DAQ到非常复杂的可视化，从设备控制到测试序列器。如果不够好，我肯定会换的。也就是说，我开始用punchcards编写Fortran，并在8位"机器"上使用了大量编程语言，从基于Z80的机器开始。语言从汇编语言到基本语言，从turbo pascal到c。
LabVIEW因其广泛的数据采集和分析库而得到重大改进。然而，我们必须学习一个不同的范例。你肯定需要一个轨迹球；-)
我对LabVIEW(或者很多关于C/C++)一无所知，但是…
Do you think that graphical languages such as LabVEIW are the future of programming?
不。。。
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。
例如，在这是一个相当复杂的乐高Mindstroms程序-很容易理解发生了什么…但是，如果你想让机器人运行5次
石英作曲家是一个很好的例子，为什么我不认为图形语言将永远是"未来"
它使得真正的酷东西变得非常容易(3D粒子效果，摄像头由摄像头像素的平均亮度控制)。但要做一些简单的事情却非常困难，比如迭代XML文件中的元素，或者将平均像素值存储到文件中。
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?)
对于学习来说，解释和理解图形语言要容易得多。
也就是说，我会推荐一种专门的基于文本的语言作为一种进步。例如，对于处理或节点盒之类的图形。它们是"正常"语言(处理是Java，NoDox是Python)，具有非常专业化、易于使用(但荒谬强大)的框架。
重要的是，它们是非常交互式的语言，你不必只写几百行就可以在屏幕上画一个圆圈。您只需键入
更多的机器人相关，甚至是像logo这样的东西都是一个很好的介绍——你输入"前进1"，乌龟前进一个盒子。"左90"型，旋转90度。这与现实的关系非常简单。您可以可视化每一条指令将要执行的操作，然后尝试并确认它确实以这种方式工作。
给他们看亮眼的东西，他们会一路从C学习有用的东西，如果他们感兴趣或进步到他们需要一种"真正的"语言的程度，他们会掌握所有的知识，而不是遇到语法错误和编译砖墙。
你在上高中。你要花多少时间来做这个项目？你们小组有多少人？他们已经知道C++还是LabVIEW了？
从你的问题来看，我知道你知道C++，而且大部分都不知道。我还怀疑组长足够敏锐地注意到团队的一些成员可能会被基于文本的编程语言所恐吓。这是可以接受的，你在上高中，这些人都很正常。我觉得普通的高中生比C++更能直观地理解LabVIEW。我猜大多数中学生，像普通人一样，都害怕命令行。对你来说，差别不大，但对他们来说，是日夜不分。
正确的是，同样的概念可以应用于LabVIEW作为C++。每个人都有其优点和缺点。关键是为工作选择正确的工具。LabVIEW是为这种应用而设计的。C++是更通用的，可以应用于许多其他类型的问题。
我要推荐LabVIEW。如果有了合适的硬件，您就可以几乎开箱即用了。你的团队可以花更多的时间让机器人做你想做的事情，这就是这个活动的焦点所在。
图形语言不是编程的未来；多年来，它们一直是为解决某些类型的问题而创建的可用选项之一。编程的未来是一层又一层的抽象，远离机器代码。在未来，我们会想，为什么我们要浪费这么多时间反复地编写"语义"程序。
我们应该在多大程度上依赖预先编写的模块，我们应该在多大程度上尝试自己编写模块？你不应该浪费时间重新发明轮子。如果LabVIEW中有可用的设备驱动程序，请使用它们。通过复制功能相似的代码并根据您的需要对其进行裁剪，您可以学到很多东西——您可以了解其他人是如何解决类似问题的，并且必须先解释他们的解决方案，然后才能将其正确地应用到您的问题中。如果你盲目地复制代码，让它工作的机会是微乎其微的。即使你复制代码，你也必须表现得很好。
祝你好运！
在我的应用程序中使用LabVIEW有一个巨大的缺点：组织设计复杂性。作为一名物理学家，我发现LabVIEW非常适合于原型设计、仪器控制和数学分析。没有哪种语言能比LabVIEW更快更好地获得结果。我从1997年开始使用LabVIEW。自2005年以来，我完全转向了.NET框架，因为它更易于设计和维护。
在LabVIEW中，必须绘制一个简单的"if"结构，并在图形设计中使用大量空间。我刚发现我们的许多商业应用程序很难维护。应用程序越复杂，就越难阅读。
我现在使用文本延迟，并且我在维护所有内容方面都做得更好。如果你将C++与LabVIEW进行比较，我会使用LabVIEW，但是与C语言相比，它不可能获胜。
如果你想让我们的团队为将来的编程做好准备，那么C(++)MA是更好的方法。用可视化构建块构建的通用编程语言的前景似乎从未实现，我开始怀疑它们是否会实现。虽然它可以用于特定的问题域，但是一旦您开始尝试解决许多一般问题，基于文本的编程语言就很难击败了。
有一次我有点接受了可执行UML的概念，但似乎一旦你通过了对象关系和一些流程流，UML将是构建应用程序的一种非常糟糕的方式。想象一下，尝试将其全部连接到一个GUI。我不介意被证明是错误的，但到目前为止，我们似乎不太可能很快就成为点击式编程。
我大约2年前开始使用LabVIEW，现在一直使用它，因此可能会有偏差，但发现它非常适合涉及数据采集和控制的应用程序。
我们主要使用LabVIEW进行连续测量和控制气阀和ATE外壳的测试。这涉及数字和模拟输入和输出，信号分析程序和过程控制都是从一个图形用户界面运行的。通过将每个部分分解成Subvis，我们可以通过单击和拖动鼠标重新配置测试。
与C/C++不完全相同，但使用Visual Basic实现测量、控制和分析的类似实现显得比较复杂，难以通过比较来维护。
我认为编程过程比实际的编码语言更重要，您应该遵循图形编程语言的样式指南。LabVIEW方块图显示了数据流(数据流编程)，因此应该很容易看到潜在的竞争条件，尽管我从未遇到过任何问题。如果您有一个C代码库，那么将它构建成一个DLL将允许LabVIEW直接调用它。
The team captain thinks that LabVIEW
is better for its ease of learning and
teaching. Is that true?
我怀疑这对于任何一种语言或范式都是正确的。对于有电子工程背景的人来说，LabVIEW肯定更容易实现；在LabVIEW中制作程序就是"简单"的绘制电线。同样，这些人可能已经接触到编程了。
除了图形之外，一个重要的区别是LV是基于需求的(流)编程。你从结果开始，告诉我们需要什么来达到它。传统编程往往是必要的(反过来说)。
有些语言可以同时提供这两者。我最近为Lua(Lanes)编写了一个多线程库，它可以在其他必要的环境中用于基于需求的编程。我知道有很多成功的机器人主要在卢亚跑(在卢亚六号疯狂的伊凡)。
人们总是比较LabVIEW与C++和天"O-LabVIEW是高水平的，它有很多内置的功能，尝试获取数据做DFFT并显示数据，所以在LabVIEW中很容易在C++中尝试它"。
神话1：很难用C++做任何事情，因为它的水平很低，而LabVIEW有很多已经实现的东西。问题是，如果你正在开发一个机器人系统在C++中，你必须使用像OpenCV，PCL这样的库。如果你使用一个设计用于构建机器人系统的软件框架，比如ROS(机器人操作系统)，你会更聪明。因此，您需要使用一整套工具。事实上，当您使用ROS+Python／C++时，使用OpenCV和PCL等库，就有更多的高级工具可用。我使用过LabVIEW机器人技术，坦率地说，像icp这样的常用算法不在那里，它不像你现在可以轻松地使用其他库。
神话2：更容易理解图形编程语言吗
这取决于情况。在编写复杂的算法时，图形元素将占用宝贵的屏幕空间，而且很难理解该方法。要理解LabVIEW代码，您必须从上到下读取代码中复杂度为O(n^2)的区域。
如果你有平行系统怎么办？ROS实现了一种基于图的体系结构，该体系结构基于使用回调实现的订阅器/发布者消息，并且非常容易让多个程序运行和通信。将各个并行组件分开可以更容易地进行调试。例如，通过并行LabVIEW代码是一个噩梦，因为控制流从一个地方跳到另一个地方。在ROS中，您不会像在LabVIEW中那样显式地"绘制架构"，但是您仍然可以看到我正在运行命令ROS RUN RQT图形(它将显示所有连接的节点)
"编程的未来是图形化的。"(这样想吗？)
我不希望，当前的LabVIEW实现不允许使用基于文本的方法和图形方法进行编码。(有数学脚本，但是速度太慢了)
很难调试，因为您不能轻易隐藏并行性。
很难阅读LabVIEW代码，因为在那里你必须查看很多区域。
LabVIEW非常适合数据AQ和信号处理，但不适合实验机器人，因为大多数高级组件，如SLAM(同时定位和映射)、点云配准、点云处理等都丢失了。即使他们添加了这些组件，并且像在ROS中一样易于集成，因为LabVIEW是专有的，而且价格昂贵，他们也永远无法跟上开源社区的步伐。
总之，如果LabVIEW是机电一体化的未来，我将改变我的职业道路，进入投资银行业……如果我不能享受我的工作，我不妨挣点钱提前退休…
你看过微软机器人工作室吗？http://msdn.microsoft.com/en-us/robotics/default.aspx
它允许可视化编程(vpl)：http://msdn.microsoft.com/en-us/library/bb483047.aspx以及现代语言，如C。我鼓励你至少看看这些教程。
我对LabVIEW(和Matlab在这方面)的不满是，如果你计划将代码嵌入除x86以外的任何东西(并且LabVIEW有工具将LabVIEW投入使用)，那么你就必须尽可能多地投入精力来解决这个问题，因为它效率很低。
LabVIEW是一个很好的原型设计工具：很多库，很容易将块串在一起，也许做高级算法有点困难，但可能有一个块可以满足您的需要。您可以快速完成功能。但如果你认为你可以拿着这个虚拟仪器，把它放在一个设备上，你就错了。例如，如果在labview中创建一个adder块，则有两个输入和一个输出。内存使用情况如何？三个变量值的数据？两个？在C或C++中，你可以知道，因为你可以写EDCOX1，0，EDCX1，1，你知道你的代码在做什么，内存情况是什么。内存使用可以快速增加，特别是因为(如其他人指出的)LabVIEW高度并行。所以，准备好投比你想的更多的内存。更强大的处理能力。
简而言之，LabVIEW非常适合快速原型化，但在其他情况下会失去太多的控制。如果您使用的是大量数据或有限的内存/处理能力，那么可以使用基于文本的编程语言，这样您就可以控制发生了什么。
这两种选择都有一定的优点，但是，由于您的领域是一种教育经验，我认为C/C++解决方案将对学生最有利。图形编程将始终是一个选项，但简单地没有以优雅的方式提供功能，这将使它比文本编程更有效地用于低级编程。这不是一件坏事——整个抽象的要点是允许对问题域有一个新的理解和看法。不过，我认为许多人可能对图形编程感到失望的原因是，对于任何特定的程序，从C语言编程到图形编程的增量收益与从汇编到C语言的增量收益几乎不同。
掌握图形编程的知识对任何未来的程序员都有好处。将来可能会有只需要图形编程知识的机会，也许您的一些学生可以从早期的经验中获益。另一方面，一个坚实的基础的基本编程概念提供的文本方法将受益于所有的学生，肯定是更好的答案。