LabVIEW or C? Can You Please 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 3rd party 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.
This week's post was written by NI LabVIEW Product Marketing Manager Simon Hogg. Feel free to leave a comment below or email him directly.