Thoughts on LabVIEW

NI LabVIEW is a graphical “programming language” oriented toward experiment and data acquisition automation. It’s useful in a lot of situations, and fairly easy to pick up. I’ll even give LabVIEW a pass for being a proprietary vendor-specific tool (and not an open-standard language like C). Proprietary tools are often useful, and even with the best of intentions, open-source communities don’t always have the resources to provide slick, easy-to-use tools.

For certain tasks, mostly involving data capture and analysis, LabVIEW is a very useful and intuitive way to create software for laboratory automation. If an experiment required the capture of a signal, outputting a snapshot of a Fourier transform whenever certain parameters were met, LabVIEW would be a good choice of software tool.

However, LabVIEW, by its nature, is unbelievably bad at certain other tasks. Specifically, basic arithmetic operations are generally done by wiring numbers to mathematical operators. To add two and four, you create “constant” objects for “2” and “4”, then run wires from each of these into an “addition” module (which looks like a miniature op-amp symbol.) This makes wonderful sense when routing signals and control lines; not so much when performing basic arithmetic.

The true nightmare, though, doesn’t appear until complex program-flow logic gets into the mix. Once an application becomes more than moderately complex, the LabVIEW schematic quickly starts to look like a psychedelic plate of alien spaghetti. One image in particular that I found on The Daily WTF illustrates the point beautifully.

*Literal* spaghetti code! (Click to see it in all its high-def glory...)

When your “program” looks like this, the language is trying desperately to tell you something. Pain, after all, is Nature’s way of saying “DON’T DO THAT!” Here, LabVIEW is doing its best to tell the programmer that it just doesn’t naturally bend in that direction. It’s like trying to implement linked lists in BASIC or writing a flight simulator in LISP. It might be possible, but that doesn’t mean it’s a good idea.

A while back, I buttonholed a NI rep at one of their local “hands-on” seminars. (One thing NI does very well is customer relations and training.) I eventually got him to admit that yes, there is an actual language behind the scenes that all these graphical connections are eventually compiled into. He mumbled something about it being for NI developers only right now and not-really-ready-for-prime-time and so on.

Even if that’s so, having the option to code in actual code would be very helpful. LabVIEW could retain the graphical interface for signal-flow applications, while offering a C-like text interface for applications that work better with more complex control structures. There are even ways to do concurrency (one of LabVIEW’s selling points) in textual languages — and in fact, this has probably already been solved in NI’s behind-the-scenes language.

Why not let the man behind the curtain out to meet the customers? I’m sure a lot of good would come from it. I know a lot of LabVIEW applications would become a lot easier to understand if this could happen.