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.
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
Answer
LabVIEW makes implementing concurrency/parallel programming easier, true. It does not, however, make debugging, testing, or thinking about concurrency/parallelism any easier. You can still write buggy, concurrent code in LabVIEW, and (as with any language, platform, or toolset) there's no silver bullet or magic wand that makes concurrency "just work".
If anything, you have to be more careful about concurrency, because if you don't think about (and declare) it explicitly, LabVIEW may make things concurrent that you weren't expecting to be.
Other beefs: It's not text. Representing dataflow in a way that makes sense means a graphical language, which means you can't use the tools that we've had for decades to manipulate text, everything from sed to emacs. It also means that source code control apps have to treat your code as opaque binaries, instead of as...source code. This, in turn, makes branching and merging an exercise in pain.