logo标签列表

文本编程语言与图形编程语言的比较

roboticslabviewgraphical-language
35
我是一名高中机器人团队的成员，我们正在讨论用哪种编程语言来编写我们的机器人程序。我们在C（或者可能是C ++）和LabVIEW之间进行选择。每种语言都有其优点。
C（++）：
- 广泛使用 - 对未来有好的准备（大多数编程职位需要基于文本的程序员） - 我们可以扩展去年的C代码库 - 允许我们更好地了解我们的机器人正在做什么
LabVIEW：
- 更容易可视化程序流程（块和线，而不是代码行） - 更容易教授（据说...） - “图形化是编程的未来。”（你这样认为吗？） - 更接近Robolab背景，新成员可能会更熟悉 - 不需要深入了解正在发生的事情。只需告诉模块找到红球，无需知道如何做到。
这对我们来说是一个非常困难的决定，我们已经讨论了一段时间。基于每种语言的优点和你的经验，你认为哪个选项更好？请记住，我们并不一定追求纯效率。我们还希望为我们的程序员未来的编程之路做好准备。
另外：
- 你认为像LabVEIW这样的图形语言是编程的未来吗？ - 图形语言比文本语言更容易学习吗？我认为它们应该同样具有挑战性。 - 鉴于我们部分根植于帮助人们学习，我们应该依靠多少预先编写的模块，以及我们应该尽量自己编写多少代码？（“好的程序员编写好的代码，伟大的程序员复制伟大的代码。”但是首先成为一个好的程序员难道不值得吗？）
谢谢您的建议！
编辑： 我想更加强调这个问题：队长认为LabVIEW更适合学习和教学。这是真的吗？我认为C也可以同样容易地教授，并且初学者级别的任务仍然会在C中存在。我真的很想听听你们的意见。打字时while {}有什么理由比创建“while框”更困难吗？程序流程从一行到另一行的修改只能通过ifs和循环进行修改，这与程序流程沿线传播并通过ifs和循环进行修改一样直观！？
再次感谢！ 编辑： 我刚意识到这属于“语言争论”的话题。如果可以的话，因为它是关于特定编程领域的最佳选择，具有特定目标。如果不行...我很抱歉...
回到1990年，当我在喷气推进实验室工作时，LabView和“图形化编程”就是“未来”。显然，它们现在仍然如此。 - Curt Hagenlocher
请注意，今年（2010年）Java也将是一种选择。我们团队去年使用了LabVIEW，但我不喜欢它。我们今年肯定会使用C(++?)。 - Sophie Alpert
对于图形化编程和文本编程的问题，我倾向于选择图形化编程。 - thirdy
我的反馈与机器人领域完全不同。在我参与金融界的一个任务中，我被迫使用了一些可视化编程工具。这不是LabView，而是一种EAI（将其他软件组合在一起的工具）。这个EAI是一个可视化工具，由连接在一起的方框组成。对于主要的“道路”来说还好，但细节非常丑陋：逻辑被埋藏起来，我们不得不点击很多次才能分析“真正”的程序流程。它变成了可视化的意大利面条，周围有数十个盒子和连接器。维护是一场噩梦：没有重构，没有自动化测试... - Guillaume
25个回答
35
在我到达之前，我们的小组（由博士科学家组成，几乎没有编程背景）已经尝试了近一年时间来实现一个LabVIEW应用程序。代码杂乱无章，过于复杂（前端和后端），最重要的是，不起作用。我是一个热心的程序员，但从未使用过LabVIEW。在一位能够帮助将我所知道的文本编程范例转化为LabVIEW概念的LabVIEW专家的帮助下，我们可以在一周内编写应用程序。关键在于基本的编码概念仍然需要学习，即使是像LabVIEW这样的语言，也只是表达它们的不同方式。
LabVIEW非常适合用于其最初设计的目的。即从DAQ卡中获取数据并在屏幕上显示，可能在其中进行一些微小的操作。然而，编写算法并不容易，我甚至认为更加困难。例如，在大多数过程式语言中，执行顺序通常按照伪数学符号（即y = x * x + x + 1）逐行跟随，而LabVIEW会使用一系列VI来实现这一点，这些VI不一定按照画布上的顺序（即从左到右）。
此外，作为一项职业，编程不仅仅是了解编码的技术细节。能够有效地寻求帮助/搜索答案、编写可读的代码以及使用遗留代码都是至关重要的关键技能，这些在像LabVIEW这样的图形语言中无疑更加困难。
我认为图形编程的某些方面可能会成为主流——使用子VI完美地体现了编程中的“黑盒”原则，并且还用于其他语言抽象，如Yahoo Pipes和Apple Automator。也许将来的某种图形语言将彻底改变我们编程的方式，但LabVIEW本身并不是语言设计上的重大范式转变，我们仍然有while、for、if流程控制、类型转换、事件驱动编程，甚至对象。如果未来真的会使用LabVIEW编写，那么C++程序员就不会遇到太多困难。
作为后记，我想说C/C++更适合机器人技术，因为学生们无疑将不得不处理嵌入式系统和FPGA。对低级编程知识（位、寄存器等）的了解在这种情况下将非常有价值。 @mendicant实际上，LabVIEW在工业界中被广泛使用，尤其是在控制系统中。当然，NASA不太可能将其用于卫星系统上，但是针对航天系统的软件开发是一个完全不同的挑战...
FPGA可以使用VHDL/Verilog(文本)或原理图(图形)进行设计。此外，两者可以互换，因此FPGA设计师拥有两全其美的选择。在您的回答中详细说明FPGA的参考可能会很有用。 - earlNameless
12

我在目前工作的研究组中遇到了一个类似的情况。这是一个生物物理学研究组，我们使用LabVIEW来控制仪器。这非常好用：可以轻松地组装一个UI来控制仪器的所有方面，查看其状态并保存数据。

现在我要阻止自己写五页的牢骚，因为对我来说，LabVIEW一直是个噩梦。让我试着总结一些优缺点：

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

LabVIEW优点

  • 是的，它很容易学习。我们研究组的很多博士似乎只需要几周甚至更短时间就能掌握足够的技能。
  • 库。这是一个重要的点。你需要仔细调查你自己的情况（我不知道你需要什么，是否有适合你的好的LabVIEW库，或者其他语言的替代品）。在我的情况下，找到例如Python中一个好的、快速的图表库一直是一个主要问题，这阻止了我将一些程序重写为Python。
  • 你的学校可能已经安装并运行了它。

LabVIEW缺点

  • 它可能太容易学习了。无论如何，似乎没有人真正费心去学习最佳实践，因此程序很快就变成了一个完全的、不可修复的混乱。当然，如果你不小心处理文本语言，这种情况也会发生，但在我的看法中，在LabVIEW中做正确的事情要困难得多。
  • LabVIEW有找到子VI的主要问题（甚至到8.2版本，我想）。LabVIEW有自己的方式知道在哪里找到库和子VI，这使得完全破坏软件非常容易。如果你没有知道如何处理这个问题的人在身边，这将使大型项目成为一场痛苦。
  • 让LabVIEW与版本控制配合起来很麻烦。当然，这是可以做到的，但无论如何，我都不建议使用内置的VC。看看LVDiff这个LabVIEW差异比较工具，但甚至不要想着合并。

    • （最后两点使得在一个项目上团队合作变得困难，这对你们来说可能很重要）

    • 这是个人感受，但我发现许多算法在可视化编程中根本不能工作。这很混乱。
      • 例如严格按顺序执行的任务，这很快就会变得笨重。
      • 很难全局查看代码。
      • 如果为小任务使用子VI（就像制作执行小任务的函数一样好的实践，并且可以适合一个屏幕），你不能只给它们命名，而是必须为每个绘制图标。这会在短短几分钟内变得非常烦人和繁琐，所以你会非常诱惑不要将东西放入子VI中。这太麻烦了。顺便说一下：制作一个真正好的图标可能需要专业人员数小时。试着为你编写的每个子VI制作独特的，立即可理解的，可识别的图标吧:)
    • 您将在一周内得到腕隧道综合症。保证。
    • @Brendan：听说了！

    总结

    关于您“是否应该编写自己的模块”的问题：我不确定。这取决于您的时间限制。如果您不必要重复造轮子，请勿花费时间。编写低级代码很容易花费几天时间，然后意识到时间已经不够用了。如果这意味着您选择LabVIEW，请去做吧。

    如果有结合LabVIEW与例如C++之类的简单方法，我很乐意听到。那可能会给您带来最好的两个世界，但我怀疑是否存在这样的方法。

    但一定要确保您和您的团队花费时间学习最佳实践。彼此查看代码。互相学习。编写可用、易懂的代码。并且享受其中的乐趣！

    请原谅我听起来有些尖锐和有点迂腐。因为LabVIEW曾经是我的噩梦 :)

    2
    LabVIEW自8.5版本起可以合并VI - http://zone.ni.com/devzone/cda/tut/p/id/6212 8.5版本还具有防止交叉链接的工具，可以解决您提到的子VI查找问题 - http://zone.ni.com/devzone/cda/tut/p/id/6200 - Chris Hamons
    9
    我认为是否选择LabVIEW取决于你是想学习一种通用的编程语言作为一项市场技能，还是只是想完成任务。LabVIEW可以让你非常快速和高效地完成任务。正如其他人所观察到的那样，它并不能神奇地使你免除理解自己在做什么的责任，如果你不理解，很可能会创造出一个混乱的代码 - 虽然根据经验，LabVIEW中最糟糕的编码风格通常是由那些有文本语言经验并拒绝适应LabVIEW工作方式的人制造的，因为他们“已经知道如何编程了！”
    当然，并不是暗示LabVIEW编程不是一项市场技能；只是不像C++那样大众化。
    LabVIEW使得管理并行进行的不同事情变得极其容易，在机器人控制情况下，您可能会需要这样的功能。代码中的竞态条件不应该成为问题（即如果存在，则说明你做错了）：有简单的技术可以确保必要时以正确的顺序发生事情 - 使用错误线或其他数据链接子VI、使用通知器或队列、构建状态机结构，甚至使用LabVIEW的序列结构。再次强调，这只是花时间了解LabVIEW中可用的工具及其工作方式的问题。我认为抱怨必须制作子VI图标并不是非常正确；您可以非常快速地创建一个包含几个文本单词的图标，甚至带有背景颜色，这对于大多数目的来说都足够了。
    “图形语言是未来的发展方向”是基于错误二分法的误导性论点。某些事情非常适合使用图形语言（例如并行代码）；其他事情则更适合文本语言。我不指望LabVIEW和图形编程会消失或接管世界。
    顺便说一句，如果NASA没有在太空计划中使用LabVIEW，我会非常惊讶。最近有人在Info-LabVIEW邮件列表上描述了他们如何使用LabVIEW开发和测试波音787上由电动机驱动的飞行表面的闭环控制，并给人留下了印象，即LabVIEW在该飞机的开发中被广泛使用。它还用于Large Hadron Collider的实时控制！ 除了国家仪器自己的网站和论坛外，获取有关LabVIEW的进一步信息和帮助的最活跃的地方似乎是LAVA。
    6

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

    未来不属于现有的图形化语言。它属于能够提供与图形化方法一样简单易懂、但也可以由程序员自己工具解析的数据流（或其他友好的并发编程类型）的人。

    6
    这并没有直接回答你的问题，但是你可能想考虑第三种选择，即混合使用解释型语言。例如Lua已在机器人领域被广泛 使用。它速度快，体积小，可以配置为使用定点数而不是浮点数运行，因为大多数微控制器没有FPU。Forth是另一个具有类似用途的替代品。
    在C中编写薄的接口层应该很容易，然后让学生们使用解释性脚本。你甚至可以设置动态加载代码，无需重新编译和刷新芯片。这应该减少迭代周期，并允许学生通过更快地看到结果来更好地学习。
    我偏向于反对使用像LabVIEW这样的可视化工具。我总是碰到一些不能或不会按照我希望的方式工作的东西。因此，我更喜欢文本代码所提供的绝对控制权。
    4
    LabVIEW让你可以快速入门，并且（正如其他人已经说过的）有一个庞大的代码库，用于执行各种测试、测量和控制相关的任务。
    然而，LabVIEW最大的缺点是你失去了程序员为自己编写的所有工具。
    你的代码被存储为VI文件。这些是不透明的二进制文件。这意味着你的代码实际上不属于你，而是属于LabVIEW。你不能编写自己的解析器，也不能编写代码生成器，更不能通过宏或脚本进行自动化更改。
    当你有一个需要应用普遍小调整的5000 VI应用程序时，这真的很糟糕。你唯一的选择就是手动检查每个VI，如果你在某个角落里错过了一个VI中的更改，那么你将会付出代价。
    是的，因为它是二进制的，所以你无法像文本语言那样进行差异/合并/补丁。这确实使得处理多个版本的代码变得难以维护。
    如果你正在做简单的事情，或者需要原型设计，或者不打算维护你的代码，那么请务必使用LabVIEW。
    如果你想进行真正可维护的编程，请使用文本语言。你可能会花费更长的时间入门，但从长远来看，你会更快。
    （哦，如果你需要DAQ库，NI也有C++和.Net版本。）
    4

    我在这里发表我的第一篇文章 :) 请温柔对待...

    我来自汽车行业的嵌入式背景，现在在国防工业。从我的经验来看，C/C++和LabVIEW是两种完全不同的编程语言，用于不同的目的。在微控制器上进行嵌入式开发时，通常使用C/C++，因为它紧凑且易于获得编译器/工具。另一方面，LabVIEW用于驱动测试系统（连同测试架作为顺序控制器）。我们使用的大多数测试设备都来自NI，因此LabVIEW提供了一个环境，在其中我们拥有所需的工具和驱动程序，以及我们想要的支持。

    就学习难度而言，有许多关于C/C++的资源和网站，可以免费提供几乎任何你想要的设计考虑和示例算法。对于LabVIEW，用户社区可能没有C/C++那么多样化，检查和比较示例代码需要更多的努力（必须拥有正确版本的LabVIEW等）...我发现学习LabVIEW相当容易，但也有一些麻烦，如并行性和其他一些需要经验的事情，才能意识到它们。

    那么所有这些之后的结论是什么呢？我想说，学习两种语言都是值得的，因为它们确实代表了两种不同的编程风格，而且精通这两种语言肯定是值得的。

    4
    8
    值得一提的是，NI 是 LabVIEW 的开发者。 :) - unwind
    4

    我认为，与文本语言相比，图形语言在表达能力上始终存在局限性。比较一下使用视觉符号（例如REBUS或手语）进行交流和使用文字进行交流。

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

    这个论点中还涉及到另一个争议，即声明式编程与命令式编程之间的区别。对于任何你不需要对如何完成某件事进行精细控制的情况，声明式通常更好。你可以以声明式的方式使用C++，但需要更多的前期工作来实现，而LABView则是专门设计为声明式语言。

    一幅画胜过千言万语，但如果一幅画代表了你不需要的千言万语，并且你无法改变它，那么在这种情况下，一幅画是毫无价值的。而使用文字可以创建成千上万幅图片，指定每个细节甚至明确引导观众的注意力。

    2
    免责声明：我没有亲眼见过LabVIEW，但我使用过其他几种图形语言，包括WebMethods Flow和Modeller，在大学里使用过动态模拟语言，还有MIT的Scratch :）。
    我的经验是，图形语言可以很好地完成编程中的“管道”部分，但我使用过的那些语言会妨碍算法。如果你的算法非常简单，那可能没问题。
    另一方面，我认为C++对于你的情况也不是很好。你将花费更多时间来追踪指针和内存管理问题，而不是进行有用的工作。
    如果你的机器人可以使用脚本语言（Python、Ruby、Perl等）控制，那么我认为这将是一个更好的选择。
    然后还有混合选项：
    如果你的机器人没有脚本选项，并且你团队中有一个C++极客，那么考虑让这个极客编写绑定，将你的C++库映射到脚本语言。这将使其他专业人员更容易地编程机器人。这些绑定将成为社区的好礼物。
    如果LabVIEW允许，使用其图形语言将以文本语言编写的模块连接在一起。
    网页内容由stack overflow 提供, 点击上面的
    可以查看英文原文，
    原文链接