LabVIEW or C? (Could You Rephrase the Question?)

“Why is LabVIEW better than C?” As a LabVIEW Product Manager, I get asked this question a lot.

Honestly, it is the wrong question to ask. It becomes a valid question with a little nuance and application context (for example, “Which is better for this task, under these constraints?”). Without this detail, it’s like asking why bread is better than flour.

If you want to build a measurement or control system, then NI LabVIEW system design software is a tool that can save you the risk, expense, and inconvenience of building your own from low-level languages like C. I’m not suggesting that LabVIEW is a “better” programming language than C—especially considering that large portions of LabVIEW are written not only in G but also in C and C++. Rather, they have different strengths that programmers should understand to succeed.

How is LabVIEW like bread? Read on.

The relationship between LabVIEW and C is similar to bread and flour. If you want to make a sandwich, start with bread. If you want to bake a cake, start with flour. Baking bread with flour from scratch can be expensive and time consuming (especially if you just want a quick snack), but when it comes to a cake, flour is essential. Similarly, you might find it challenging to decide which programming language is best for your task. It comes down to using the right tool for the right job.


C Gives You Low-Level Control

C is often better for applications with tight resources that must be closely managed. Since C is a relatively low-level language, it forces you to consider and specify even the smallest details, such as memory assignments and threads. A good programmer can use this low-level of control to eliminate the overhead in most higher level implementations. At this level, you can also take advantage of target architecture or host operating system properties to achieve greater performance.

NI programmers wrote most of the LabVIEW libraries in C or C++ for this reason. Operations like file I/O and analysis are as fast in LabVIEW as they are in C because they are written in low-level languages and optimized for each of the platforms and operating systems that LabVIEW supports.


Efficiency Versus Control
At some point, developer efficiency trumps the need for hand-optimized code. Relinquishing a little control to stand on the shoulders of those who have solved similar problems can benefit many projects in terms of quality productivity. Programming languages are constantly progressing toward higher levels of abstraction. This helps you focus on the problem at hand instead of the minutia of the computing.
         

LabVIEW: For Parallel Execution and Real-World I/O
No matter what the implementation language, high-level system design and low-level implementation must inevitably split.

In measurement and control applications, programming is just one task of a system designer. Engineers often don’t have time to keep up with or rewrite old software to support the advancements in computing and measurement hardware, operating systems, and so on. They add value by figuring out how to acquire, manipulate, and present real-world data—not by coming up with new ways to handle memory allocations and thread pools. By using LabVIEW,  you can  build on top of tested, supported, and maintained libraries of lower level code from NI. Choosing C means you’ll need to implement, support, and maintain your own lower level libraries or purchase them from a vendor (NI offers NI LabWindows ™/CVI software and NI Measurement Studio for this use case).
Syntax-wise, C is optimized for sequential execution of instructions as fast as the CPU can handle them. This is perfect for pure computation, when only one task is being executed and instructions are more basic. The graphical syntax in LabVIEW, on the other hand, is optimized for the parallel execution of tasks that have real-world timing constraints.

LabVIEW allows you to skip building a foundation and go straight to customization.  

LabVIEW is more than just a programming language and associated libraries. When you use the LabVIEW integrated development environment (IDE) with NI hardware, you get a development experience that is greater than the sum of its parts. The software is aware of available hardware resources and can present available I/O channels and execution targets as drop-down menus and project items. You can prevent or catch incorrect configurations during editing, to avoid costly, hard-to-debug  runtime errors. Next-generation measurement hardware (such as the NI PXIe-5644R vector signal transceiver) even allows LabVIEW to redefine the firmware of the hardware to reach performance levels that traditional, distinct programming languages and instruments can’t.

Too many projects end up late or over budget because people underestimate the efforts required to stitch together parts from disparate sources. When you use LabVIEW, your hardware drivers return data in the same format as the analysis libraries consume, your UI widgets display technical data in the same format that the analysis libraries produce, eliminating the need to piece together components.

So Which is Better: LabVIEW, or C?           
The answer might as well be “42.” To draw from The Hitchhiker’s Guide to the Galaxy, the answer isn't meaningful until you know which question you are asking or what problem you are trying to solve. LabVIEW and C are both useful tools that, in the hands of skilled users, can solve almost any problem: LabVIEW tends to be better for high-level test, measurement, and control applications, and C is more apt for lower level implementations of computationally intensive tasks.

The next time someone asks you whether LabVIEW trumps C, feel free to answer “42”. It may be the only response that will get the discussion heading in the right direction.

To learn more about LabVIEW and the NI integrated development environment, visit ni.com/labview.


- NI LabVIEW Product Marketing Manager Simon Hogg 

46 ratings | 4.57 out of 5

Read in English Chinese (Simplified) Chinese (Traditional) French Italian Portuguese Spanish | Print | PDF

Reader Comments | Submit a comment »

The way I see it
If want a EE to play the role of a Test Engineer, then LabView is probably the best approach. However, if you have a Test Engineer in the role of a Test Engineer then LabWidnows/CVI is the best choice. The Test Engineer-pure can exploit an ROI from the Development Team which is VERY likely to have developed Firmware and initial functional/integration testing using a C- based (or a language with similar syntax as C) IDE. I would NOT use a C IDE other than LabWindows/CVI in either case. NI does an excellent job with extending ANSI C capabilties via LabWindows/CVI (just check-out the great plug-ins/functions especially the Analysis ones)!
- Anthony Conway, Test Engineer. - Mar 28, 2013

Typing vs Programming
I've been using LV since v2.5, around 1992. I recently started brushing up on C, since it's still heavily used by colleagues, especially in embedded programming. Just like in the 1990's, I've spent about half my time looking for typographical errors in the exercises I've done. Typos. Not learning about information flow or programming techniques. The compilers, to this day, appear to only give cryptic hints as to what one may have done wrong. I suppose I'll get better at this but it seems to be an awful waste of time. Regarding printing, seriously, how many of us actually USED a program printout in th last 20 years? It's a bit like printing emails, no?
- William Gilbert, University of Minnesota . wgilbert@physics.umn.edu - Feb 18, 2013

LabVIEW does have a place
I developed DoD applications for over 30 years and I was glad to see LabVIEW come along. My development projects had been directed to use a different language on about every one. We had developed on Fortran, Cobalt, ADA, BASIC, C, C++, and different assembly compilers. It seemed like DOD was searching for the perfect solution, but instead it just introduced reinvention of the same functionality. I tried an evaluation version of Labview back in 1994, and then took some training in 1995. It had so many libraries and equipment drivers, so we knocked out a 1996 project within months instead of years. I love the way it can use shared libraries, so you could use your old code if you found a need but we always had to rebuild the code even if we didn't touch it. Our customer was always wanted the latest Windows computers, so keeping up with the hardware was easier and performance always seemed to improve. I continue to use and endorse it. DOD stubbornly clings to C/C++ even if you show them the power of LabVIEW, but I suspect its more a culture and business reasons. All the programmers learn C/C++, so fear of learning something new or loss of control creeps in. On the business side of DOD, software development is billed by the hour so if you are too efficient that cuts into your profits. I'm retired and freelance now, so I target customers that just want the job to get done in the most efficient way; time, cost, robust, and quickly updated. GO LABVIEW!!
- David Neumann, Freelance Research Protos LLC. freelance_research_protos@aol.com - Feb 14, 2013

LabVIEW makes easier overview
Well, I am LabVIEW'ing since v3.0. And honestly, I love it. But in the last few years I also had to do some work with textual languages. And I hate it! It is so much harder to keep the overview over bigger systems. One has much more trouble with multi-tasking/-threading. One has to remember much more with textual coding. LV has its own pitfalls and limits, but overall I'm much more productive with LV than with textual languages. And that's what counts for me.
- Uwe Frenz, getemed AG. u.frenz@getemed.de - Jan 14, 2013

... I need a bigger plotter to print my program.
&%@( Jim, I'm a programmer, not a graphic artist!
- Jan 9, 2013

Well put, however...
it makes me concerned that there is the need to explain the C vs. LabVIEW paradigms to a community of "Software Developers". Welcome to a world full of BLOATWARE! Aaahhh...
- Jan 8, 2013

...but you need to first ask how many years your application will operate without additional funding.
The first question you really need to ask (before you ask the LabVIEW or C question), assuming you are not just a developer, but also a software manager, is whether or not your application must be supported for many years (perhaps decades, as in many U.S. DoD programs) without repeated funding input, from either your customer or from your internal organization. Histroically, LabVIEW source requires somewhat annual updates to the project code base in order to stay current with the IDE. This is because LabVIEW has greatly evolved over the past 20+ years, for the benefit of all. This is not to say that this does not also happen with C (and CVI), but updates to the C source code base are typically because of funded updates and bug fixes, not because your IDE has simply evolved forward in time. The good news is that NI has partially addressed this by now supporting the ability in LabVIEW to open-forward and save-backwards to/from certain older versions of LavVIEW source. But again, the developer(s) must excercise caution when excercising this feature, and rigorous re-testing of the deployed application is also recommneded of course.
- David A. Belliveau, BAE Systems, Inc.. david.belliveau@baesystems.com - Jan 8, 2013

Exactly!
As someone who programmed exclusively in LabWindows/CVI through the 1990s and has been developing in LabVIEW since 2000, your analogy is perfect. "42" will be my answer from now on.
- William L Weaver, La Salle University. williamlweaver@gmail.com - Jan 8, 2013

Rephrased Version
While 'C'ing is believing (Lab)VIEWing is understanding ... Which would you choose?
- giriseshadri@yahoo.co.in - Jan 8, 2013