文本与graphics编程语言
我是高中机器人队伍的一员，对于使用哪种语言来编程我们的机器人有一些争议。 我们selectC（或者C ++）和LabVIEW。 每种语言都有优点。
C（++）：
- 广泛使用
- 为未来做好准备（大多数编程职位需要基于文本的程序员。）
- 我们可以从去年的C代码库扩展
- 让我们更好地了解我们的机器人在做什么。
LabVIEW的
- 更容易可视化程序stream程（块和连线，而不是代码行）
- 更容易教（据说…）
- “编程的未来是graphics化的。” （也这样觉得？）
- 接近一些新成员可能拥有的Robolab背景。
- 不需要亲密地知道发生了什么事情。 只要告诉模块find红球，不需要知道如何。
对我们来说这是一个非常艰难的决定，我们一直在辩论。 基于每种语言的专业知识，以及您获得的经验， 您认为更好的select是什么？ 请记住，我们不一定要纯粹的效率。 我们也希望为编程人员的未来做好准备。
也：
- 你认为像LabVEIW这样的graphics语言是编程的未来吗？
- graphics语言比文本语言更容易学习吗？ 我认为他们应该同样具有挑战性的学习。
- 看到我们在帮助人们学习的基础上， 我们应该依赖多less预先编写的模块，以及我们应该自己写多less？ （“好的程序员编写好的代码，伟大的程序员复制伟大的代码”。但是，首先，这不是一个好的程序员吗？）
感谢您的build议！
编辑：我想更多地强调这个问题：队长认为LabVIEW更容易学习和教学。 真的吗？ 我认为，C可以很容易地教，而初学者的任务仍然会与C一起。我真的很想听听你的意见。 有没有什么理由打字，而{}应该比创build一个“边框”更困难？ 难道直观的是，程序一行一行地stream水，只能通过ifs和循环来修改，因为直观的是程序stream经线路，只能通过ifs和loop来修改！
再次感谢！
编辑：我刚刚意识到，这属于“语言辩论”的主题。 我希望没关系，因为这对某个特定的编程分支来说是最好的。 如果不是…对不起…
在我到达之前，我们的团队（博士学位的科学家，几乎没有编程背景）一直在努力实现一个LabVIEW应用程序的开关 – 将近一年。 代码是不整洁，太复杂（前端和后端），最重要的是，没有工作。 我是一个敏锐的程序员，但从未使用过LabVIEW。 在一位LabVIEW专家的帮助下，我可以将我所熟悉的文本编程模式转化为LabVIEW概念，在一周内就可以编写应用程序。 这里的要点是， 基本的编码概念还需要学习，甚至像LabVIEW这样的语言也只是expression它们的不同方式 。
LabVIEW非常适合用于最初devise的function。 即从数据采集卡中获取数据，并在屏幕上显示，也许还有一些小的操作。 然而，编程algorithm并不容易，我甚至会build议它更困难。 例如，在大多数过程语言中，执行顺序通常是使用伪math符号（即y = x*x + x + 1 ）一行一行地执行，而LabVIEW将使用一系列不一定遵循的VI其他（即从左到右）在canvas上。
而编程作为职业不仅仅是知道编码的技巧。 能够有效地寻求帮助/search答案，编写可读代码和使用遗留代码是所有关键技能，这在LabVIEW等graphics化语言中无疑更加困难。
我相信graphics化编程的一些方面可能会成为主stream – 使用子VIs完美体现了编程的“黑盒子”原理，也被用于其他语言抽象，如Yahoo Pipes和Apple Automator – 也许还有一些未来的graphics语言将会改变我们编程的方式，但是LabVIEW本身并不是语言devise中的一个巨大的范式转变，我们仍然可以while, for, ifstream程控制，types转换，事件驱动编程，甚至是对象的情况下。 如果未来真的会用LabVIEW编写，那么C ++程序员就不会有太多的麻烦。
作为后文，我会说C / C ++更适合于机器人学，因为学生在某些时候无疑将不得不处理embedded式系统和FPGA。 低级别的编程知识（比特，寄存器等）对于这种事情是非常宝贵的。
实际上，LabVIEW在工业中被广泛使用，特别是在控制系统中。 授予NASA不太可能将其用于车载卫星系统，但随后空间系统的软件开发是一个完全不同的球类游戏 。
我目前正在研究的研究小组遇到了一些类似的情况。这是一个生物物理学小组，我们正在使用LabVIEW来控制我们的仪器。 这非常好：组装一个用户界面来控制仪器的各个方面，查看其状态并保存数据非常简单。
现在，我不得不停止写5页的咆哮，因为对我来说LabVIEW是一场噩梦。 让我来尝试总结一下优点和缺点：
免责声明我不是LabVIEW专家，我可能会说有偏见的东西，过时的或只是错误的:)
LabVIEW专业人员
- 是的，这很容易学习 。 我们集团的许多博士似乎已经获得了足够的技能，可以在几周甚至更less的时间内破解掉。
- 图书馆 。 这是一个重点。 你必须仔细研究你自己的情况（我不知道你需要什么，如果有良好的LabVIEW库，或者有其他语言的替代品）。 在我的情况下，find一个好的，快速的Python图表库已经成为一个主要的问题，这阻碍了我们用Python重写我们的一些程序。
- 你的学校可能已经安装并运行了。
LabVIEW缺点
- 这可能太容易学习了。 无论如何，似乎没有人真正想学习最佳实践，所以程序很快就会变成一个完整的，无法弥补的混乱。 当然，如果你不小心的话，这也必然会发生在基于文本的语言上，但IMO要在LabVIEW中正确做事更加困难。
- LabVIEW在寻找子VI方面往往存在主要问题 （甚至高达8.2版，我认为）。 LabVIEW有自己的方法知道在哪里可以find库和子VI，这使得完全破坏软件变得非常容易。 如果你周围没有人知道如何处理这个事情，这会使大项目变得很痛苦。
- 让LabVIEW能够使用版本控制是一件痛苦的事情 。 当然，这是可以做到的，但无论如何我都不要使用内置的VC。 查看LVDiff以获得LabVIEW diff工具，但不要考虑合并。
（最后两点让一个项目的团队工作很困难，这对你来说可能很重要）
- 这是个人的，但我发现，许多algorithm在视觉上编程时不起作用。 这是一团糟 。
- 一个例子是严格按顺序的东西; 这很快就会变得麻烦。
- 对代码进行概述很困难。
- 如果你使用子VI来完成小任务（就像创build一个执行一个小任务的函数是一个很好的习惯，而且适合在一个屏幕上），你不能只给出它们的名字，但是你必须为每个他们。 这在几分钟内变得非常烦人和麻烦，所以你很容易不把东西放在一个子VI中。 这太麻烦了。 顺便说一句：制作一个非常好的图标可能需要专业的时间。 去尝试做一个独特的，立即可以理解的，可识别的图标，你写的每个子VI）
- 你会在一个星期内有腕pipe。 保证。
- @Brendan：听到，听到！
总结发言
至于你的“我应该写自己的模块”的问题：我不确定。 取决于你的时间限制。 如果不需要，不要花时间重新发明轮子。 在编写低级代码的过程中花费时间太容易了，然后意识到你已经没有时间了。 如果这意味着你select了LabVIEW，那就去做吧。
如果能够简单地将LabVIEW和C ++结合起来，我很乐意听到这个消息：这可能会给你带来两全其美的好处，但是我怀疑它是否有用。
但要确保你和你的团队花时间学习最佳实践。 看着对方的代码。 相互学习。 编写可用，可理解的代码。 玩得开心！
请原谅我尖锐的，也许有点迂腐。 这只是对我来说，LabVIEW一直是一个真正的噩梦:)
我认为LabVIEW的select与否取决于你是否想学习用一种常用的语言来编程，或者只是想要完成一些东西。 LabVIEW使您能够非常快速和高效地完成填充工作。 正如其他人所观察到的，它不会让你不必理解你正在做什么，如果你不这样做，就很可能造成一个邪恶的混乱 – 虽然有趣的是，在LabVIEW中糟糕的代码风格最糟糕的例子是通常由有文本语言经验的人员所左右，并且拒绝适应LabVIEW的工作原理，因为他们已经知道如何编程，所以不要这么做！
当然，这并不意味着LabVIEW编程不是一个可销售的技术。 只是它不像C ++那样大众化。
LabVIEW可以非常容易地pipe理并行发生的不同事情，这在机器人控制的情况下可能会发生。 代码中的竞争条件应该是顺序的也不应该是一个问题（即如果他们是，你做错了）：有一些简单的技术，以确保东西在必要时按正确的顺序发生 – 链接使用错误导线或其他数据，使用通知或队列，构build状态机结构，甚至在必要时使用LabVIEW的序列结构。 再次，这只是一个花时间了解LabVIEW中可用的工具以及它们如何工作的例子。 我不认为必须制作子VI图标的抱怨是非常好的。 你可以非常快速地创build一个包含几个文字的文字，也许有一个背景颜色，这对大多数目的来说是很好的。
“graphics语言是未来的方式”是基于错误的二分法的红鲱鱼。 有些东西非常适合graphics语言（比如并行代码）; 其他的东西更适合文本语言。 我不希望LabVIEW和graphics编程要么消失，要么接pipe世界。
顺便提一下，如果NASA在太空计划中不使用LabVIEW，我会感到非常惊讶。 最近有人在Info-LabVIEW邮件列表中描述了他们如何使用LabVIEW来开发和testing由波音787上的电动机驱动的飞行表面的闭环控制，并给出了LabVIEW被广泛用于飞机开发的印象。 它也用于大型强子对撞机的实时控制！
除了NI自己的网站和论坛之外，目前用于获得更多信息和帮助的最活跃的地方似乎是LAVA 。
这不直接回答你的问题，但你可能要考虑第三种混合解释型语言的选项。 例如， Lua 已经在机器人领域使用了。 由于大多数微控制器没有FPU，因此它速度快，重量轻，可以configuration为使用定点数而不是浮点运行。 Forth是另外一个类似的用法。
在C中编写一个精简的接口层应该是相当容易的，然后让学生用解释的脚本松开。 你甚至可以设置它来允许dynamic加载代码，而不用重新编译和刷新芯片。 这应该减less迭代周期，让学生更快地看到结果，学习更好。
我偏爱使用像LabVIEW这样的可视化工具。 我似乎总是碰到一些没有或者不会像我想要的那样的东西。 所以，我更喜欢用文本代码来获得绝对的控制权。
LabVIEW的另一个优点（除库之外）是并发性的 。 这是一种数据stream语言 ，这意味着运行时可以为您处理并发。 因此，如果您正在做一些高度并发的事情，而不想进行传统的同步，LabVIEW可以帮助您。
未来不属于今天的graphics化语言。 它属于谁可以提出数据stream（或其他并发友好types的编程）的表示，这与graphics化方法一样简单，但也可以由程序员自己的工具进行分析。
国家仪器公布的关于该主题的已发表研究报告：
DSP教学中graphics与文本编程的研究
它具体看LabVIEW与MATLAB（而不是C）。
我认为与文本语言相比，graphics语言在expression能力方面总是有限的。 比较尝试使用可视符号（例如，REBUS或手语）与使用单词进行通信。
对于简单的任务，使用graphics语言通常更容易，但对于更复杂的逻辑，我发现graphics化语言会阻碍。
然而，这个论点所暗示的另一个争论是声明性的编程与命令性的。 对于任何你不需要对如何完成任务的细粒度控制的情况，声明通常更好。 你可以用声明的方式使用C ++，但是你需要更多的工作来完成它，而LABView被devise成一个声明性语言。
一张图片胜过千言万语，但如果一张图片代表你不需要的千言万语，那么你就无法改变，那么这样一张图片就毫无价值。 而您可以使用单词创build数千张图片，指定每个细节，甚至明确引导观众的注意力。
噢，我的上帝，答案非常简单。 使用LabView 。
我已经编写了10年的embedded式系统，而且我可以说没有至less几个月的基础设施（非常小心的基础设施！），您将不会像第一天使用LabView那样高效。
如果你正在devise一个机器人被出售和用于军事，那就从C开始 – 这是一个好的电话。
否则，使用允许您在最短的时间内尝试最多样化的系统。 这是LabView 。
LabVIEW使您能够快速入门，并且（正如其他人已经提到的那样）有大量的代码库用于执行各种testing，测量和控制相关的事情。
然而，LabVIEW最大的缺陷就是失去了所有程序员自己编写的工具。
你的代码被存储为VI。 这些是不透明的二进制文件。 这意味着你的代码真的不是你的，它是LabVIEW的。 您不能编写自己的parsing器，不能编写代码生成器，也不能通过macros或脚本进行自动更改。
当你有一个5000 VI应用程序，这需要一些小的调整普遍应用这很糟糕 。 你唯一的select就是手动完成每一个VI，如果你在某个angular落错过一个VI的改变，天堂会帮助你。
是的，因为它是二进制的，所以你不能像使用文本语言那样做diff / merge / patch。 这确实使得多个版本的代码一起工作是一个可怕的可维护性恶梦。
无论如何，如果您正在做一些简单的事情，或者需要原型，或者不打算维护您的代码，请使用LabVIEW。
如果你想做真正的，可维护的编程，使用文本语言。 你开始的速度可能会比较慢，但从长远来看，速度会更快。
（哦，如果你需要DAQ库，那么NI也有C ++和.Net版本。）
我认为，graphics化语言可能是未来的语言…..对于所有那些adhoc MS Access开发者来说。 纯文本编码器总会有一个地方。
就我个人而言，如果一切都完成了，那么build立机器人的真正乐趣是什么？ 如果你只是放下一个'find红球'模块在那里，看看它走了吗？ 你会为自己的成就感到自豪吗？ 就个人而言，我不会有太多。 另外，它会教给你什么编码，或者是软件/硬件接口（非常重要）在机器人技术中至关重要的方面？
我不认为自己是该领域的专家，但问自己一件事：你认为NASA使用LabVIEW来编写火星漫游器代码？ 你认为在机器人领域真正突出的人使用LabView吗？
真的，如果你问我，唯一使用像LabVIEW这样的小工具来构build这个东西，将会让你准备好成为一些后院机器人构build者，而不是仅仅是一些。 如果你想要一些能给你更多行业经验的东西，build立你自己的“LabVIEW”型系统。 build立你自己的“找球”模块，或者你自己的“跟随”模块。 这将是更困难的，但也将是更酷的方式。 ：d
我喜欢LabVIEW。 如果其他人记得使用了类似的东西，我会特别推荐它。 普通程序员要习惯它需要一段时间，但是如果你已经知道如何编程，结果会好得多。
C / C ++等于pipe理你自己的内存。 你会在记忆链接中游泳，担心他们。 使用LabVIEW，确保阅读LabVIEW附带的文档，注意竞争条件。
学习一门语言很容易。 学习如何编程不是。 即使它是一种graphics化语言也不会改变。 graphics语言的优势在于更容易直观地看到代码将会执行什么，而不是坐在那里解密一堆文本。
重要的不是语言而是编程概念。 不pipe你学什么语言编程，因为只要花点功夫，你就可以用任何语言编程。 语言来来去去。
免责声明：我没有亲眼目睹LabVIEW，但是我已经使用了一些其他的graphics语言，包括WebMethods Flow和Modeller，大学的dynamic仿真语言，以及呃MIT的Scratch :)。
我的经验是，graphics语言可以很好地完成编程的“pipe道”部分，但是我主动使用的部分妨碍了algorithm的实现。 如果你的algorithm很简单，那可能是好的。
另一方面，我不认为C ++也适合你的情况。 你会花费更多的时间来跟踪指针和内存pipe理问题，而不是在有用的工作中。
如果你的机器人可以使用脚本语言（Python，Ruby，Perl等）进行控制，那么我认为这将是一个更好的select。
然后是混合选项：
如果您的机器人没有脚本选项，并且您的团队中有C ++怪胎，那么请考虑让该怪胎编写绑定，将您的C ++库映射为脚本语言。 这将允许其他专业人员更容易地编程机器人。 绑定将会给社区带来好的礼物。
如果LabVIEW允许的话，用它的graphics语言把用文本语言编写的模块放在一起。
我的第一篇文章:)温柔…
我来自汽车行业的embedded式背景，现在我在国防行业。 我可以从经验中告诉你，C / C ++和LabVIEW是真正不同的，有着不同目的的野兽。 C / C ++总是用于微控制器的embedded式工作，因为它非常紧凑，编译器/工具很容易实现。 另一方面，LabVIEW使用LabVIEW驱动testing系统（以及testing台作为音序器）。 我们使用的大多数testing设备都来自NI，所以LabVIEW提供了一个我们拥有工作所需的工具和驱动程序的环境，以及我们所需要的支持。
就易学性而言，C / C ++和许多网站都提供了许多资源，这些资源在免费提供后几乎包含了devise注意事项和示例algorithm。 对于LabVIEW，用户社区可能不像C / C ++那样多样化，而且需要花更多的努力来检查和比较示例代码（必须要有正确版本的LabVIEW等）。我发现LabVIEW非常容易拾取但是这里有一些令人讨厌的东西，在这里我们要讲到并行性和其他各种需要一点经验的事情，然后才能意识到它们。
那所有的结论呢？ 我会说，这两种语言在学习上都是值得的，因为它们确实代表了两种不同的编程风格，而且在这两方面都值得注意和精通。
你在高中。 你有多less时间在这个计划上工作？ 你们小组中有多less人？ 他们是否已经知道C ++或LabView？
从你的问题来看，我发现你知道C ++，大多数人不知道。 我还怀疑，小组组长是足够敏锐的，以注意到一些团队成员可能会被基于文本的编程语言吓倒。 这是可以接受的，你在高中，这些人是normies 。 我觉得正常的高年级学生能比C ++更直观地理解LabView。 我猜大多数高中学生，像一般的人口，都害怕命令行。 对你而言，差别就更小了，但对他们来说，这是昼夜。
你是正确的，相同的概念可能被应用于LabView作为C ++。 每个人都有自己的长处和短处。 关键是select正确的工具。 LabView是为这种应用而devise的 。 C ++更通用，可以应用于许多其他types的问题。
我要推荐LabView。 鉴于正确的硬件，您几乎可以开箱即用。 你的团队可以花更多的时间让机器人做你想做的事 ，这就是这个活动的重点。
graphics语言不是编程的未来， 多年来，它们一直是解决某些types问题的可用select之一。 编程的未来是从机器代码层层抽象出来的。 将来，我们会想知道为什么我们一遍遍地编程“语义”。
我们应该依赖预先写好的模块多less，我们应该自己写多less？ 你不应该浪费时间重新发明轮子。 如果在Labview中有可用的设备驱动程序，请使用它们。 您可以通过复制function相似的代码并根据您的需求进行修改来了解更多 – 您可以看到其他人是如何解决类似问题的，并且必须先解释他们的解决scheme，然后才能将其正确应用于您的问题。 如果你盲目地复制代码，那么获得它的机会是渺茫的。 即使你复制代码，你也必须要做的很好。
祝你好运！
我build议你使用LabVIEW，因为你可以让机器人更快，更容易地完成。 LabVIEW已经被devise出来了。 OfCourse C（++）是伟大的语言，但是LabVIEW做的比其他任何事情都要做得更好。 人们可以在LabVIEW中编写非常好的软件，因为它提供了足够的范围和支持。
在我的应用程序中使用LabVIEW时发现了一个巨大的负面影响：组织devise复杂性。 作为一名物理学家，我发现Labview非常适合原型devise，仪器控制和math分析。 在LabVIEW中，没有哪种语言可以让你得到更快，更好的结果。 自1997年以来，我一直使用LabView。自2005年以来，我完全转向了.NET框架，因为它更容易devise和维护。
在LabVIEW中，必须绘制一个简单的“if”结构，并在graphicsdevise中使用大量空间。 我刚刚发现很多商业应用都很难维护。 应用程序越复杂，阅读越困难。
我现在使用文本的语言，我在维护一切方面好得多。 如果您将C ++与LabVIEW进行比较，我将使用LabVIEW，但与C＃相比，它不会赢
总之，这取决于。
我现在使用LabVIEW已有20年了，从简单的DAQ到非常复杂的可视化，从设备控制到testing序列发生器，都做了相当大的工作。 如果它不够好，我肯定会切换。 也就是说，我开始用打卡器编码Fortran，并在8位“机器”上使用了大量的编程语言，从Z80开始。 从汇编语言到BASIC语言，从Turbo-Pascal到C.
由于其广泛的数据采集和分析库，LabVIEW是一个重大改进。 但是，人们有学习不同的范例。 你肯定需要一个轨迹球;-)）
我什么都没有关于LabView（或关于C / C ++），但..
你认为像LabVEIW这样的graphics语言是编程的未来吗？
没有…
graphics语言比文本语言更容易学习吗？ 我认为他们应该同样具有挑战性的学习。
更容易学习？ 不，但他们更容易解释和理解。
要解释一种编程语言，你必须解释一个variables是什么（这非常困难）。 这不是stream程图/节点编码工具的问题，例如乐高Mindstroms编程接口或Quartz Composer。
例如， 在这是一个相当复杂的乐高Mindstroms程序 – 这是很容易理解进入…但如果你想让机器人运行INCREASEJITTER块5次，然后开车10秒，然后尝试INCREASEJITTER循环再次？ 事情开始变得非常混乱
Quartz Composer是这方面的一个很好的例子，为什么我不认为graphics语言将会是“未来”
它使真正很酷的东西变得非常容易（3D粒子效果，摄像头的像素的平均亮度控制摄像头）。但是做起来容易，比如从XML文件迭代元素或者存储将平均像素值转换为文件。
看到我们在帮助人们学习的基础上，我们应该依赖多less预先编写的模块，以及我们应该自己写多less？ （“好的程序员编写好的代码，好的程序员复制伟大的代码”。但是，首先，这不是一个好的程序员吗？）
对于学习来说，解释和理解graphics语言是非常容易的。
也就是说，我会推荐一个专门的基于文本的语言语言作为一个进展。 例如，像Processing或NodeBox的graphics。 它们是“正常”的语言（Processing是Java，NodeBox是Python），具有非常专业化，易于使用（但是荒谬的function）的框架。
重要的是，他们是非常互动的语言，你不必写几百行就可以在屏幕上看到一个圆圈。你只需要inputoval(100, 200, 10, 10) ，然后按下运行button，就会出现！ 这也使得他们很容易演示和解释。
更多的机器人相关的，甚至像LOGO这样的东西将是一个很好的介绍 – 你键入“FORWARD 1”，乌龟向前驱动一个盒子。键入“LEFT 90”，它转动90度..这与现实很简单。 你可以直观地看到每条指令会做什么，然后尝试一下，确认它是否真的有效。
向他们展示一些看起来光鲜亮丽的东西，他们会吸取他们从C学到的有用东西，如果他们感兴趣或进展到需要“真正”语言的地步，他们将拥有所有的知识，而不是遇到语法错误和编译砖墙
看来，如果你正在努力让我们的团队为将来的编程做准备，C（++）可能是更好的路线。 用视觉构build模块构build的一般编程语言的承诺似乎从未实现，我开始怀疑它们是否会这样做。 看起来虽然可以针对特定的问题领域完成，但一旦您尝试解决许多常见问题，基于文本的编程语言就很难被打败。
曾经有一段时间，我对可执行的UML有所了解，但是看起来，一旦你超越了对象关系和一些stream程stream，UML将是构build应用程序的一个相当悲惨的方式。 想象一下，试图把它连接到一个GUI。 我不介意被certificate是错误的，但到目前为止，我们似乎不可能很快就点击点击编程。
我大约两年前开始使用LabVIEW，现在一直在使用它，所以可能会有所偏差，但对于涉及数据采集和控制的应用程序来说，它是理想select。
我们使用LabVIEW主要用于testing连续测量和控制燃气阀门和ATEshell的位置。 这涉及到数字和模拟input和输出，信号分析例程和过程控制均来自GUI。 通过将每个部分分解为子VI，我们可以通过鼠标的点击和拖动来重新configurationtesting。
与C / C ++不完全相同，但使用Visual BASIC进行测量，控制和分析的类似实现似乎比较复杂，难以通过比较来维护。
我认为编程的过程比实际的编程语言更重要，您应该遵循graphics编程语言的风格指南。 LabVIEW程序框图显示数据stream （ Dataflow编程 ），所以应该很容易看到潜在的竞争条件，尽pipe我从来没有遇到任何问题。 如果你有一个C代码库，那么将其构build成一个dll将允许LabVIEW直接调用它。
这两种select都是有价值的。 但是，由于您的域名是一种教育体验，我认为C / C ++解决scheme将最有利于学生。 graphics化编程将永远是一种select，但不能以一种优雅的方式提供function，使得使用比低级编程的文本编程效率更高。 这不是一件坏事 – 抽象的全部重点是对问题域进行新的理解和观察。 我相信很多人可能会对graphics编程感到失望，但对于任何特定的程序来说，从C编程到graphics编程的增量收益与从assembly到C的增量差不多。
对graphics编程的了解肯定会对未来的程序员有所裨益。 未来可能会有机会，只需要graphics编程的知识，也许你的一些学生可以从一些早期的经验中受益。 另一方面，通过文本方法提供的基本编程概念的坚实基础将使所有学生受益，当然必须是更好的答案。
该队长认为，LabVIEW的学习和教学便利性更好。 真的吗？
我怀疑这对于任何一种语言或范式都是如此。 对于具有电子工程背景的人来说，LabView肯定会更容易; 制作程序是“简单”绘制电线。 再次，这样的人也可能已经接触到编程。
一个本质的区别 – 除了graphics – 是LV是基于需求的（stream程）编程。 你从结果开始，并告诉，需要什么去得到它。 传统的编程往往是必不可less的（相反）。
有些语言可以提供这两种。 我最近为Laa制作了一个multithreading库（Lanes），它可以用于在其他势在必行的环境中进行基于需求的编程。 我知道有成功的机器人主要在Lua跑（Lua Oh Six的Crazy Ivan ）。
你有没有看过微软机器人工作室？ http://msdn.microsoft.com/en-us/robotics/default.aspx
它允许可视化编程（VPL）： http : //msdn.microsoft.com/en-us/library/bb483047.aspx以及现代语言，如C＃。 我鼓励你至less看看教程。
我对Labview（以及Matlab在这方面）的抱怨是，如果你打算把代码embeddedx86以外的其他任何东西（Labview有工具把Labview VI放在ARM上），那么你必须在这个问题上投入很多的功率尽你所能，因为它效率低下。
Labview is a great prototyping tool: lots of libraries, easy to string together blocks, maybe a little difficult to do advanced algorithms but there's probably a block for what you want to do. You can get functionality done quickly. But if you think you can take that VI and just put it on a device you're wrong. For instance, if you make an adder block in Labview you have two inputs and one output. What is the memory usage for that? Three variables worth of data? Two? In C or C++ you know, because you can either write z=x+y or x+=y and you know exactly what your code is doing and what the memory situation is. Memory usage can spike quickly especially because (as others have pointed out) Labview is highly parallel. So be prepared to throw more RAM than you thought at the problem. And more processing power.
In short, Labview is great for rapid prototyping but you lose too much control in other situations. If you're working with large amounts of data or limited memory/processing power then use a text-based programming language so you can control what goes on.
People always compare labview with C++ and day "oh labview is high level and it has so much built in functionality try acquiring data doing a dfft and displaying the data its so easy in labview try it in C++".
Myth 1: It's hard to get anything done with C++ its because its so low level and labview has many things already implemented. The problem is if you are developing a robotic system in C++ you MUST use libraries like opencv , pcl .. ect and you would be even more smarter if you use a software framework designed for building robotic systems like ROS (robot operating system). Therefore you need to use a full set of tools. Infact there are more high level tools available when you use, ROS + python/c++ with libraries such as opencv and pcl. I have used labview robotics and frankly commonly used algorithms like ICP are not there and its not like you can use other libraries easily now.
Myth2: Is it easier to understand graphical programming languages
这取决于实际情况。 When you are coding a complicated algorithm the graphical elements will take up valuable screen space and it will be difficult to understand the method. To understand labview code you have to read over an area that is O(n^2) complexity in code you just read top to bottom.
What if you have parallel systems. ROS implements a graph based architecture based on subcriber/publisher messages implemented using callback and its pretty easy to have multiple programs running and communicating. Having individual parallel components separated makes it easier to debug. For instance stepping through parallel labview code is a nightmare because control flow jumps form one place to another. In ROS you don't explicitly 'draw out your archietecture like in labview, however you can still see it my running the command ros run rqt_graph ( which will show all connected nodes)
"The future of programming is graphical." (Think so?)
I hope not, the current implementation of labview does not allow coding using text-based methods and graphical methods. ( there is mathscript , however this is incredibly slow)
Its hard to debug because you cant hide the parallelism easily.
Its hard to read labview code because there you have to look over so much area.
Labview is great for data aq and signal processing but not experimental robotics, because most of the high level components like SLAM (simultaneous localisation and mapping), point cloud registration, point cloud processing ect are missing. Even if they do add these components and they are easy to integrate like in ROS, because labview is proprietary and expensive they will never keep up with the open source community.
In summary if labview is the future for mechatronics i am changing my career path to investment banking… If i can't enjoy my work i may as well make some money and retire early…
