LabVIEW的哪些特定功能使您感到沮丧? [英] What specific features of LabVIEW are frustrating to you?

问题描述

请多多包涵:这不是语言辩论，也不是烈火.这是一个真正的征求意见的请求.

Please bear with me: this isn't a language debate or a flame. It's a real request for opinions.

有时，我必须帮助教育传统的文本编码器如何在LabVIEW(LV)中进行思考.通常在此过程中，我会听到有关LV如何吸吮的信息.除了"Language X好得多！"以外，这种见解很少伴随理性的观察.虽然这句话令他们满意，但并不能帮助我理解是什么使他们感到沮丧.

Occasionally, I have to help educate a traditional text coder in how to think in LabVIEW (LV). Often during this process, I get to hear about how LV sucks. Rarely is this insight accompanied by rational observations other than "Language X is just so much better!". While this statement is satisfying to them, it doesn't help me understand what is frustrating them.

那么，对于那些拥有LabVIEW 和文本语言经验的人来说，有关LV驱动器的特定于的事情有何帮助?

So, for those of you with LabVIEW and text language experience, what specific things about LV drive you nuts?

------摘要-------

------ Summaries -------

感谢所有答案！一些问题在下面的评论中得到了回答，一些问题在其他站点上存在，而一些仅仅是LV的真正问题.本着原始问题的精神，我不会在这里尝试回答所有这些问题:检查 LAVA 或 NI 的网站，您会惊讶地发现其中可以克服的许多事情.

Thanks for all the answers! Some of the issues are answered in the comments below, some exist on other sites, and some are just genuine problems with LV. In the spirit of the original question, I'm not going to try to answer all of these here: check LAVA or NI's website, and you'll be pleasantly surprised at how many of these things can be overcome.

• 意外并发
• 无法使用传统文字处理工具
• 仅二进制源代码控制
• 难以分支和合并
• 打开的窗口太多
• 文本具有更清晰/更清晰/更具表现力的语法
• 干净的编码需要大量的时间和操作
• 大型，难以访问的API/调色板系统
• 需要鼠标
• 文件命名空间:内存中没有重复的具有相同名称的文件
• LV对象本身仅是按值
• 需要开发人员环境才能查看代码
• 缺乏缩放
• 启动缓慢
• 记忆猪
• 巨人"代码难以使用
• UI锁定很容易
• 触控板和LV混合不好
• 字符串操作在图形上很
• 有限的UI自定义
• 隐藏"原语(是的，这些存在)
• 缺乏正式的元编程能力(不过不会再持续很长时间了)
• 缺乏unicode支持

• Unintentional concurrency
• No access to tradition text manipulation tools
• Binary-only source code control
• Difficult to branch and merge
• Too many open windows
• Text has cleaner/clearer/more expressive syntax
• Clean coding requires a lot of time and manipulation
• Large, difficult to access API/palette system
• Mouse required
• File namespacing: no duplicate files with the same name in memory
• LV objects are natively by-value only
• Requires dev environment to view code
• Lack of zoom
• Slow startup
• Memory pig
• "Giant" code is difficult to work with
• UI lockup is easy to do
• Trackpads and LV don't mix well
• String manipulation is graphically bloated
• Limited UI customization
• "Hidden" primitives (yes, these exist)
• Lack of official metaprogramming capability (not for much longer, though)
• Lack of unicode support

推荐答案

我很欣赏LabView，特别是能够轻松驱动硬件的能力(当然，这是在National Instruments的硬件上)，以及并发编程功能.但是在代码导航中很讨厌基于文本的编程语言:

I appreciate LabView in many ways, especially the ability to easily drive hardware (well, when it's National Instruments' hardware, of course), and the concurrent programming features. But is sucks against text-base programming languages in code navigation:

• 浏览代码时，随着您一次又一次地打开subVis，最终会打开大量的窗口
• 因为单词比图标更具表达力，所以与文本语言相比，您在一个屏幕上看到的指令更少，尤其是在像Python这样的表达性语法中
• 我们用其他语言也没有例外处理；错误以结构表示，从一个VI传输到另一个VI，并且对于每个VI，必须添加一个if error return; else do stuff代码.
• 出现错误时，调试期间无法停止

• when you browse the code, you end up with tons of opened windows, as you successively open subVis again and again
• because words are more expressive than icons, you see fewer instructions in one screen, compared to text languages, especially in expressive syntaxes, like python
• there's no exception handling as we know it in other languages; errors are expressed in structures, transported from one VI to another, and for every VI you must add a if error return; else do stuff code.
• There's no way during debug to halt when an error is raised

这篇关于LabVIEW的哪些特定功能使您感到沮丧?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！