我是高中机器人团队的一员,对于使用哪种语言来编程机器人存在争议.我们在C(或C++)和LabVIEW之间进行选择.每种语言都有优点.
C(++):
广泛使用
为未来做好准备(大多数编程职位需要基于文本的程序员.)
我们可以从去年开始扩展我们的C代码库
让我们更好地了解我们的机器人在做什么.
LabVIEW的
更容易可视化程序流(块和线,而不是代码行)
更容易教(据说...)
"编程的未来是图形化的." (也这样觉得？)
更接近一些新成员可能拥有的Robolab背景.
不需要密切了解发生了什么.只需告诉模块找到红球,不需要知道如何.
这对我们来说是一个非常困难的决定,我们已经讨论了一段时间.基于每种语言的专业知识,以及您获得的经验,您认为更好的选择是什么？请记住,我们不一定要追求纯粹的效率.我们也希望为程序员的未来编程做好准备.
也:
你认为像LabVEIW这样的图形语言是编程的未来吗？
图形语言比文本语言更容易学习吗？ 我认为他们应该同样具有挑战性.
看到我们正在帮助人们学习,我们应该依靠预先编写的模块多少,以及我们应该多少尝试自己编写？ ("优秀的程序员编写优秀的代码,优秀的程序员可以复制优秀的代码."但是,首先不值得成为一名优秀的程序员吗？)
感谢您的建议!
编辑:我想更多地强调这个问题:团队队长认为LabVIEW更易于学习和教学. 真的吗？ 我认为C可以很容易地教授,初级水平的任务仍然可以用C.我真的很想听听你的意见. 是否有任何理由在{}之前打字比创建"while box"更困难？ 是不是直观的程序逐行流动,只是由ifs和循环修改,因为直观的程序流过电线,只是由ifs和循环修改!？
再次感谢!
编辑:我刚才意识到这属于"语言辩论"的主题.我希望它没关系,因为它是针对具体目标的特定编程分支的最佳选择.如果不是......我很抱歉......
在我到达之前,我们的小组(博士科学家,几乎没有编程背景)一直试图实现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不太可能将它用于机载卫星系统,但随后太空系统的软件开发是一个完全不同的球类游戏 ......
我在目前正在研究的研究小组中遇到过类似的情况.它是一个生物物理小组,我们正在使用LabVIEW来控制我们的仪器.这非常有用:可以轻松组装UI来控制仪器的各个方面,查看其状态并保存数据.
现在我不得不停止写5页咆哮,因为对我来说,LabVIEW一直是个噩梦.让我试着总结一些优点和缺点:
免责声明我不是LabVIEW专家,我可能会说有偏见,过时或只是错误的东西:)
是的,它很容易学习.我们小组中的许多博士似乎已经获得了足够的技能,可以在几周内甚至更少的时间内进行攻击.
图书馆.这是一个重点.您必须根据自己的情况仔细研究这个问题(我不知道您需要什么,如果有好的LabVIEW库,或者有其他语言的替代品).在我的例子中,在Python中查找例如一个好的,快速的图表库是一个主要问题,这使我无法用Python重写我们的一些程序.
您的学校可能已安装并运行它.
这可能太容易学了.无论如何,似乎没有人真的很难学习最佳实践,所以程序很快就会成为一个完整的,无法修复的混乱.当然,如果你不小心的话,这也必然会发生在基于文本的语言上,但IMO在LabVIEW中做正确的事情要困难得多.
在LabVIEW中,查找子VI的情况往往存在重大问题(我认为甚至高达8.2版本).LabVIEW有自己的方式知道在哪里可以找到库和子VI,这使得完全破坏软件变得非常容易.如果你周围没有人知道如何处理这个问题,这会让大型项目变得很痛苦.
让LabVIEW使用版本控制是一件痛苦的事.当然,它可以完成,但无论如何我都不会使用内置的VC.查看LVDiff获取LabVIEW diff工具,但不要考虑合并.
(最后两点让一个项目的团队工作变得困难.这在你的案例中可能很重要)
这是个人的,但我发现很多算法在视觉上编程时都不起作用.这是一团糟.
一个例子是严格顺序的东西; 这很快就变得很麻烦.
很难对代码进行概述.
如果你将sub-VI用于小任务(就像在一个屏幕上创建执行小任务的函数一样好),你不能只给它们起名字,但你必须为每个任务画出图标他们 这只会在几分钟内变得非常烦人和麻烦,所以你很想不把东西放在子VI中.这太麻烦了.顺便说一句:制作一个非常好的偶像可能需要一段时间.试着为你写的每个子VI制作一个独特的,可立即理解的,可识别的图标:)
你会在一周内得到腕管.保证.
@Brendan:听,听!
至于你的"我应该编写自己的模块"问题:我不确定.取决于你的时间限制.如果你不需要,不要花时间重新发明轮子.花太多时间编写低级代码然后意识到你已经没时间了.如果这意味着你选择LabVIEW,那就去吧.
如果有简单的方法将LabVIEW与C++结合起来,我很乐意听到它:这可能会给你两全其美,但我怀疑它有.
但请确保您和您的团队花时间学习最佳实践.看着对方的代码.互相学习.编写可用,易懂的代码.玩得开心!
并请原谅我听起来前卫,也许有点迂腐.只是LabVIEW 对我来说真是个噩梦:)
我认为LabVIEW的选择取决于你是否想要学习用常用语言编程作为一种有市场的技巧,或者只是想完成这些工作.LabVIEW使您能够非常快速有效地完成工作.正如其他人所观察到的那样,它并没有神奇地让你不必理解你正在做的事情,如果不这样做,很可能会造成一种不圣洁的混乱 - 虽然有趣的是,LabVIEW中糟糕的编码风格最糟糕的例子是通常由具有文本语言经验并且拒绝适应LabVIEW工作方式的人员执行,因为他们已经知道如何编程,该死的!
当然,这并不意味着LabVIEW编程不是一种适销对路的技能; 只是它不像C++那样大众市场.
LabVIEW可以非常轻松地管理并行执行的各种操作,在机器人控制情况下您可能会遇到这种情况.应该是顺序的代码中的竞争条件也不应该是一个问题(即如果它们是,你做错了):有一些简单的技术可以确保在必要时以正确的顺序发生事情 - 链接子VI使用错误连线或其他数据,使用通知程序或队列,构建状态机结构,甚至在必要时使用LabVIEW的序列结构.同样,这只是花时间了解LabVIEW中可用的工具以及它们如何工作的情况.我不认为必须制作子VI图标的抱怨非常有针对性; 你可以非常快速地创建一个包含几个文字的文字,也许带有背景颜色,
"图形语言是未来的方式"是基于错误二分法的红色鲱鱼.有些东西非常适合图形语言(例如并行代码); 其他东西更适合文本语言.我不希望LabVIEW和图形编程要么消失,要么接管世界.
顺便说一句,如果NASA 没有在太空计划中使用LabVIEW ,我会非常惊讶.最近有人在Info-LabVIEW邮件列表中描述了他们如何使用LabVIEW开发和测试波音787上由电动机驱动的飞行表面的闭环控制,并给人的印象是LabVIEW在飞机的开发中被广泛使用.它也用于大型强子对撞机的实时控制!
除了National Instruments自己的网站和论坛之外,目前获取更多信息和帮助LabVIEW的最活跃的地方似乎是LAVA.
这不会直接回答您的问题,但您可能需要考虑使用解释语言混合的第三种选择.例如,Lua 已经 用于机器人领域.它速度快,重量轻,可以配置为使用定点数而不是浮点运行,因为大多数微控制器都没有FPU.Forth是具有类似用途的另一种选择.
在C中编写一个精简的界面层应该很容易,然后让学生放松解释脚本.您甚至可以将其设置为允许动态加载代码而无需重新编译和刷新芯片.这应该减少迭代周期,让学生通过更快地看到结果来更好地学习.
我偏向于使用LabVIEW等可视化工具.我似乎总是打出一些不会或者不会像我希望的那样工作的东西.所以,我更喜欢用文本代码获得的绝对控制.
LabVIEW的另一个优势(除了库)是并发性的.它是一种数据流语言,这意味着运行时可以为您处理并发性.因此,如果您正在做高度并发的事情并且不想进行传统同步,LabVIEW可以帮助您.
未来不属于今天的图形语言.它属于谁能够提出数据流(或其他并发友好类型的编程)的表示,它与图形方法一样简单,但也可由程序员自己的工具解析.
京公网安备 11010802040832号 | 京ICP备19059560号-6 