文本编程语言与图形编程语言

Question

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

C(++)：

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

LabVIEW

• 更容易可视化程序流(块和线，而不是代码行)
• 更容易教(据说.)
• “编程的未来是图形化的。”(你觉得呢？)
• 更接近一些新成员可能拥有的Robolab背景。
• 不需要亲密无间知道发生了什么。简单的告诉模块找到红色的球，不需要知道怎么做。

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

另外：

• 你认为像LabVEIW这样的图形语言是编程的未来吗？
• 是一种比文本语言更容易学习的图形语言？，我认为它们应该具有同样的挑战性。
• 既然我们的目标是帮助人们学习，那么我们应该在多大程度上依赖于预先编写的模块，我们应该在多大程度上尝试自己编写呢？(“优秀的程序员编写好代码，优秀的程序员复制伟大的代码”)。但是，首先做一个好的程序员不值得吗？)

谢谢你的建议！

编辑:我想强调这个问题:队长认为LabVIEW更容易学习和教学。是真的吗？，我认为C可以很容易地被教，初级水平的任务也会和C一起出现。我真的很想听听你的意见。有什么理由让输入than {}比创建一个“than box”更困难吗？难道不是这样直观的:程序逐行流动，只由ifs和循环修改，就像程序流过电线，只被ifs和循环修改一样！？。

再次感谢！

编辑:我刚刚意识到这属于“语言辩论”的主题。我希望这是可以的，因为它是关于什么是最好的一个特定的程序设计分支，有一定的目标。如果不是..。我很抱歉。

Answer 1

在我目前工作的研究小组中，我遇到了类似的情况。这是一个生物物理小组，我们在各地使用LabVIEW控制我们的仪器。这是非常好的工作:很容易组装一个UI来控制您的仪器的所有方面，查看它的状态并保存您的数据。

现在我不得不阻止自己写一个5页的咆哮，因为对我来说，LabVIEW是一场噩梦。让我试着总结一些利弊：

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

LabVIEW专业人士

• 是的，很容易学到。我们小组中的许多博士似乎已经掌握了足够的技能，可以在几周内破门而入，甚至更少。
• 图书馆.这是一个重要的问题。您必须根据自己的情况仔细研究这一点(我不知道您需要什么，是否有好的LabVIEW库，或者是否有其他语言的替代品)。在我的例子中，用Python找到一个好的、快速的图表库是一个主要的问题，这使我无法用Python重写我们的一些程序。
• 你的学校可能已经安装和运行了。

LabVIEW反式

• 这可能太容易学了。无论如何，似乎没有人真正费心学习最佳实践，所以程序很快就变成了一个完整的、无法弥补的烂摊子。当然，如果您不小心的话，基于文本的语言也必然会发生这种情况，但是在LabVIEW中做正确的事情要困难得多。
• 在查找子VIs时，LabVIEW中往往会出现一些主要问题(我认为，甚至可以达到8.2版)。LabVIEW有自己的方法知道在哪里可以找到库和子VIs，这使得它非常容易完全破坏您的软件。如果你身边没有一个知道如何处理这个问题的人，那么大型项目就会很痛苦。
• 让LabVIEW与版本控制一起工作是一种痛苦的。当然，这是可以做到的，但无论如何，我都不会使用内置的VC。查看LVDiff以获得一个LabVIEW diff工具，但甚至不要考虑合并。

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

• 这是针对个人的，但我发现很多算法只是在视觉编程时不起作用。这是个烂摊子。
  • 一个例子是严格按顺序排列的东西，很快就会变得很麻烦。
  • 很难对代码进行概述。
  • 如果你在小任务中使用子VI(就像让函数执行一个小任务，并且适合在一个屏幕上一样)，你不能只给它们起名字，但是你必须为每个小任务绘制图标。这会在几分钟内变得非常烦人和烦琐，所以你会很想不把东西放在子VI里。太麻烦了。顺便说一句:制作一个真正好的图标需要花上一个专业的时间。试着为你所写的每一个子VI制作一个独特的、立即可以理解的、可识别的图标:)

​

• 一周内你就会有腕管。有保证。
• @Brendan:听，听！

结束语

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

如果有简单的方法将LabVIEW和C++结合起来，我很想听听:这可能会给你两个世界中最好的，但我怀疑是这样的。

但要确保你和你的团队花时间学习最佳实践。看对方的密码。互相学习。编写有用的、可以理解的代码。玩得开心点！

请原谅我听起来有些急躁，也许有点迂腐。只是LabVIEW对我来说是一场噩梦:)

Answer 2

我认为LabVIEW的选择取决于你是想学习用一种常用的语言编程，作为一种市场上的技能，还是只想把事情做完。LabVIEW使您能够非常快速和高效地完成任务。正如其他人所观察到的，它并不能神奇地让你不必理解自己在做什么，而且如果你不理解它，你也很有可能制造出一团乱七八糟的烂摊子--尽管在LabVIEW中最糟糕的编码风格的例子通常是那些在文本语言方面有经验的人，他们拒绝适应LabVIEW的工作方式，因为他们“已经知道如何编程了，该死！”

当然，这并不意味着LabVIEW编程不是一项可销售的技能，而是说它没有C++那么大众化。

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

“是图形语言--未来的道路”是一种基于错误二分法的鲱鱼。有些东西非常适合图形语言(例如并行代码)；另一些东西更适合文本语言。我不希望LabVIEW和图形化编程消失，也不会接管这个世界。

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

除了国家仪器公司自己的网站和论坛外，目前最活跃的获取LabVIEW信息和帮助的地方似乎是熔岩。

Answer 3

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

用C编写一个薄的接口层，然后让学生使用解释的脚本，应该是相当容易的。您甚至可以将其设置为允许在不重新编译和闪烁芯片的情况下动态加载代码。这将减少迭代周期，并让学生通过更快地看到结果来更好地学习。

我对使用可视化工具(如)的持偏见态度。我似乎总是碰到一些不起作用或不起作用的事情，就像我想要的那样。所以，我更喜欢文本代码的绝对控制。