What specific features of LabView are frustrating to you?
- by Underflow
Please bear with me: this isn't a language debate or a flame. It's a real request for opinions.
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.
So, for those of you with LabVIEW and text language experience, what specific things about LV drive you nuts?
------ Summaries -------
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.
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
[1]: http://www.lavag.org LAVA
