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)

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
If this question can be reworded to fit the rules in the help center, please edit the question.

I feel that the original title was just inviting a "Subjective and Argumentative" closure.
–
EBGreenDec 16 '08 at 20:30

19 Answers
19

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.

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:

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.

+1 on that one, but I expect this can just not be appreciated by someone who is more confident with LabView than with a text-based language. It is especially hard when dealing with a large unknown project. Just think about how grep can help you with source files that are text...
–
mghieJan 31 '09 at 10:23

1

You make error handling sound like a pain, but it's really not; you can make a template with the case structure and error in/out terminals. You can then decide where and how to handle the errors, which is probably the right way to do it if you have multiple processes running concurrently, which is what LabVIEW is good at. And the 'automatic error handling' option halts execution whenever an error is raised - I'm pretty sure this has been present since version 7.
–
nekomaticOct 14 '11 at 12:02

@nekomatic I'm aware of that, I almost always use templates for error cases. And automatic error handling has to be enabled by hand for each VI
–
CharlesBOct 14 '11 at 12:07

@CharlesB There's a preferences option for automatic error handling to be on by default for new VI's, and AFAIK this is the default setting for a new LabVIEW installation. It drives seasoned users nuts ;-)
–
nekomaticOct 14 '11 at 12:09

Labview is great for controlling hardware. I have written several Labview apps for collecting data (analog voltage from various sensors) and control hardware (mostly piezoelectric motors). Labview makes it fairly easy to perform several tasks in parallel.

Now to answer your question. What do I find frustrating about Labview.

Time spent organizing block diagram

moving wires around

organizing nodes

Perhaps, since I am self taught I spend too much time trying to clean up wires and trying to follow them in an attempt to deciphers what data they are carrying and where it is going.

Point and clicking through the toolbox thing looking for the node/function that I want to place in the block diagram or front panel.

I should just be able to type the name of the function/method I need with the parameters and get going instead of...

"hmmm... I need the calculate RMS vi
now where would that be? now I need an
AND operation. OK back up to top
level, to logical functions, which one
of these is AND oh right it's that
one. Drop on diagram wire it up and
test! Well that only took 15
minutes!."

But there probably is a more efficient way to work with Labview, I just don't know it!

Looks like Quick Drop was introduced in Labview 8.6. I guess I need to upgrade from v8.5. Will check it out; it does look useful. Thanks for the tip.
–
AzimDec 18 '08 at 18:22

For cleaning up wires and blocs, you can use automatic clean up command. There is a button in the toolbar (top-right) which can automatically clean up the whole diagram or the selected parts. The clean up setting is adjustable too (Tools>Options>Block Diagram).
–
kamiMar 17 '13 at 22:35

1.LabVIEW objects are not passed by reference.
2.No other viewer exist(especially free one) for viewing the block diagrams.
3. Need to open up a large number of windows to view a project. Would like it to be MDI so that number of windows gets reduced.

In the 2009 release, there are native by-reference objects: zone.ni.com/devzone/cda/tut/p/id/9386. At tinyurl.com/mg9et3, one of the NI devs states: "None of the MDI environments attempted thus far has been as good as the current scenario of individual windows." They're thinking about it, but apparently haven't solved it yet.
–
Joe ZollerAug 8 '09 at 17:00

The thing I was most frustrated with was that it took my hands off the keyboard. I'm a touch typist, and can code fairly quickly in a text language. LabVIEW forces you to use the mouse to select VIs and program nodes from its menus, and to wire the nodes together. While this is really fast and convenient if you're an electrical engineer, used to designing circuits in a graphical environment, it's a pain if you're used to typing in your code.

Disclosure: It's been about two years now since I last used LabVIEW, so these next two may be fixed by now.

The next annoyance was source control. One of the things you do most often with your source control repository is diff your current version with a previous version to find the changes. You can't do that with a graphical language like LabVIEW. Popular revision control systems like CVS and SVN use text-based diff tools behind the scenes. I hope National Instruments has come up with their own revision control solution for all of you guys who are still using LabVIEW.

The last annoyance I had was a lack of real object-oriented language features. LabVIEW 6i, the last version I used, was object-based at best. No one could really make an accurate claim that it was object-oriented. I couldn't create a real class hierarchy using inheritance, and polymorphism was reserved for only a few built-in types. I realize that 6i was two versions ago, so I really hope that this is fixed.

OOP was available with an external toolkit since at least version 7. Version 8.0 introduced native objects. You can use LabVIEW with both CVS and SVN. The repositories do get a bit big, but disk space is cheap. LVDiff is a free LabVIEW diff tool.
–
eaolsonDec 17 '08 at 6:21

LabVIEW has had graphical differencing built in since 7.1 (Professional dev system and higher).
–
nekomaticDec 17 '08 at 14:55

LVDiff is free, but requires LabVIEW Professional Development System or higher.
–
Don KirkbyMar 24 '09 at 18:27

I really wish Shift or Alt-scrollwheel would do horizontal scroll. I've got used to it in other programs, and it's terrific.
–
Craig McQueenSep 24 '09 at 5:06

It should be easy to avoid UI lockups. This may be as simple as understanding your dataflow properly or you may need to look a bit harder at how you are using event structures (if you are) or operations that force a switch into the user interface thread. See the help.
–
nekomaticDec 15 '09 at 9:42

I love event structures, what causes UI lock ups for my code is when i query DAQ cards, I'm pretty sure this can be done on a separate thread to avoid lock up issues, but it hasn't been a big enough problem for me to re-architect the app in order to avoid it.
–
Atilio JobsonDec 29 '09 at 23:55

We use SVN and TortoiseSVN at work. I'm frustrated that I can't do a diff to see what has changed in a file. Doing "diffs" is part of the daily workflow when using SVN, so it's frustrating to see that a file has changed, but have no idea whether it was something trivial or substantial. Doing diffs also enables a systematic review of changes.

I hear "professional" has some sort of diff tool. I'll have trouble convincing management that we need professional for a "diff" feature though. And I haven't been able to read conclusively that it actually integrates smoothly with TortoiseSVN.

Use of source control is considered one of the industry best-practices, so it would be great for NI to fully support it, not just in the "professional" license, lest NI be seen to be inhibiting adoption of best-practices.

Not being able to zoom in and out of the block diagram. Yes, designs should be kept to a single screen or scrolled in only one direction but I've gotten code from 3rd party vendors who must be using 50 inch monitors to develop on -- the code goes on forever in every direction!

(23 Jan 2009): Use View->Navigation Window to see a bird's eye view of the entire diagram (front and diagram panels). This could be useful when LabVIEW decides to put a new control created from the block diagram in a random location on the front.

A feature hole: there's no metaprogramming facilities to speak of, IIRC. It's great for building things, as long as whatever you're building is at the same level of abstraction that the LV designers thought you'd want.

Over the past 20 years, I've moved (generally) to higher and higher levels of abstraction. For about a year, LV was neat, because it was slightly higher than what I was using. Then I blew past it, and LV looks more antiquated every year.

Personally, I think LabView is an excellent program for what it is designed to do. Aside from inheriting terrible code, which is a problem in any language, with good practice it is very efficient and quick for putting together all sorts of process control, automation, test, and measurement systems. Like text coding, good practice with LabView exists as well - if you have a scrambled, messy VI then it's really the fault of the coder and not the language. Text-coded languages can get very scrambled as well - the onus is on the programmer to not create unnecessarily messy or obfuscated code.

If you start writing your code with future expansion in mind then it's not difficult at all to create VIs which can grow with the needs of program without becoming cumbersome. Just the same as bad text code can quickly become a mess if you hack it out with a short-term view, only to have it outgrow itself and become unmaintainable. It does mean, however, that you have to take the time to learn LabView, just the same as you have to take the time to learn any language or IDE.

Chances are that if LabView is frustrating your efforts you probably should be using something else to create your program, or at least something else for those components of the program.

For example, if you need to do a lot of string handling - more than is convenient to hack through with LabView's string functions - but you really want or need to use LabView for the meat of your application, then there are many options open to you. You can easily code DLLs in something like C or whatever your favourite language is and then access those functions through LabView's DLL interface. This goes for any sort of high-level or abstract function which is awkward to implement with the basic LabView tools.

This has two big advantages - first you can focus your text coding to simply writing functions or procedures. The task of building the application around your functions becomes non-existent. By blending it with LabView, you gain the second advantage of LabView's quick and powerful UI builder and instrumentation connectivity.

In terms of source control, the biggest thing you can do is to flex LabView's inherent capacity for modularity. While you don't have text tools to help you, for example when trying to sort out unknown inherited code, it does have other very powerful features which, in an abstract way, can do many of the same things. It's probably the easiest language in existence to refactor, which means that, in general, refactoring inherited code can be done WHILE you are learning what it does.

If you go to a data source and break the wire, you instantly see everything that it was connected to, for example. The error list will give you a complete list of everything that broke due to a dependency on that data source and you can straight away work away at creating bundles and clusters to clean up the LabView spaghetti. It even highlights the broken data connections on the back panel so you can trace where everything goes. You can quickly encapsulate things in subVIs if it's clear they are littering the main process with clutter, etc. By the time you've figured out what your code does, it's neat and clean and suddenly re-maintainable.

The big exception to this is if the program used a lot of unnecessary globals. Surprise - globals complicate things in LabView too. In that case, there's nothing to do but curse the schmuck who left you the mess. Still, it's not the end of the world.

I suppose, in short, what I'm trying to say is that LabView is a very different language. If it seems frustrating, it's not because the tools don't exist to do the things you are used to in text coding, but simply that they are often implemented in radically different ways. Grepping code isn't an end unto itself, for example, but only a means to an end - the purpose is to discover links and references throughout the program. While you can't grep LabView code, you can discover links and references - it's just done in an totally different way. Learning curve stuff.

I wrote a program (in C++) to control an rs232 device from a computer but was asked to provide a driver or Vi or whatever for labview. I downloaded labview with full confidence that I could bang something out in short order. (I am a comp sci graduate from an ivy school, have programmed in C++ for 15 years, learned and used C, Scheme, C#, Java, etc. - this should be a no-brainer)

I also downloaded a sample app and documentation for labview.

I was horrified at the outcome. Labview is HUGE, SLOW and non-intuitive. It follows none of the paradigms I am used to with either MFC or Visio or Rational Rose or VB, etc. Trying to find the right documentation was also a hard experience. There is just so much out there that one needs to have an understanding of Labview just to know where to begin.

It is a huge program that does so much. Without someone to show you how to use it is very difficult. I self-taught myself many things, but labview so far has eluded me. (granted I have not spent nearly as much time on it as i should, but it was a frustrating experience so far)

To summarize - it is huge, slow and non-intuitive. The docs are overwhelming.

Slow at doing what - working in the development environment (subjective) or actually running the code (shouldn't be)? Yes, it is a different paradigm. That's one of the reasons that the people who love it love it...
–
nekomaticDec 17 '08 at 14:29

Also, the evaluation download may be huge but it includes a lot of stuff in terms of toolkits and examples etc. It's a fair criticism that the documentation could be better, both for beginners and more experienced users.
–
nekomaticDec 17 '08 at 14:41

slow at loading up... it takes a long long time to load.
–
TimDec 17 '08 at 16:41

1

By different paradigm I meant it has no commonality with other standard user interfaces or designers. Much as Lotus Notes did not play by standard UI "rules" - and in the end it alienates potential users.
–
TimDec 17 '08 at 16:42

you will be happy with version 8.6 that has two features that attack your frustration:

Auto Clean up diagramA tool to clean up cluttered code.
However it is noted that this tool should not be used on clean code (LAVA and NI forums).

Quick Drop
A tool to select nodes and VIs by using keyboard shortcuts, a video on Youtube shows the quick drop in action. After 1:07 you see the Auto Clean Up tool.

Tim,
What is that you mean by

Labview is HUGE, SLOW and non-intuitive

If you have examples and improvements please let it be known.
If you have troubles building a driver have a look at the shipped drivers (for a multimeter for instance). Try to find a similar instrument with a driver and adjust it as needed, I know for sure NI is willing to help you or others will. Come with your questions to LAVA or NI forums.
The different Paradigm that LabVIEW uses (data-flow) might be the solution to parallel programming (at least that is what NI tells us), Visio is not a programming languange, sorry to break the news. Using a beginners book (LabVIEW for everyone) is a very good start.

LabVIEW cannot have multiple copies of a VI with the same name in memory simultaneously.

Until version 8.5, this meant that if I wanted to diff My VI.vi revision 2 against revision 1, I had to (manually) create a copy of it with a different name, open that, and then tell LabVIEW to compare it with my original.

My understanding is that they automated this process somewhat in 8.5, to give you a 3-way merge tool, of sorts.

Labview can be used to author large, complex software projects. Labview is unquestionably much more fun to use than a syntax based language. I have programmed mathematically dense dynamic simulations using labview. Newer versions of Labview include alot of exciting features, especially for utilizing multiple processors. I like Labview very much. But I don't recommend it to anyone.

Unfortunately, it's an absolute nightmare for anything other than simple acquisition and display. It may one day be sufficiently developed to be considered as a viable alternative to text based languages. However, the developers at NI have consistently opted to ignore the three fundamental problems that plague labview.

1) It is unstable and riddled with bugs. There are thousands of bugs that have been posted to the labview support forums that are yet to be fixed. Some of these are quite serious, such as memory leaks, or mathematical errors in basic functions.

2) The documentation is atrocious. More often than not, when you look for help with a labview function in the local help file you'll find a lonely sentence that merely restates the name of the item you are trying to find some detail on. e.g. A user looks up the help file on the texture filter mode setting and the only thing written in the help file is "Texture Filter Mode- selects the mode used for texture filtering." Gee, thanks. That clears things right up, doesn't it? The problem goes much deeper than that; quite often, when you ask a technical representative from national instruments to provide critical details about labview functionality or the specific behavior of mathematical functions, they simply don't know how the functions in their own library work. This may sound like an exaggeration, but trust me, it's not.

3) While it's not impossible to keep graphical code clean and well documented, Labview is designed to make these tasks both difficult and inefficient. In order to keep your code from becoming a tangled, confusing mess, you must routinely (every few operations) employ structures like clusters, sub-vis and giant type defined controls (which can stretch over multiple screens in a large project). These structures eat memory and destroy performance by forcing labview to make multiple copies of data in memory and perform gratuitous operations- all for the sake of keeping the graphical diagram from looking like rainbow colored spaghetti with no comments or text anywhere in sight. Programming in labview is like playing pictionary with the devil. Imagine your giant software project written as a wall sized flowchart with no words on it at all. Now imagine that all the lines cross each other a thousand times so that tracing the data flow is completely impossible. You have just envisioned the most natural and most efficient way to program in labview.

Labview is cool. Labview is getting better with each new release. If National Instruments keeps improving it, it will be great one day as a general programming language. Right now, it's an extremely bad choice as a software development platform for large or logically complex projects.

Difficult to branch and merge: The diff does not do a good job in isolating the changes, a small change in one case in a case structure may give you many "differences". Merge have to be done manually as far as I know.

Time consuming to build simple logics: I find simple logics may take lots of wiring and drawing, once you want to change it, you have to redraw everything.