In my current role I have the opportunity to use a variety of tools to solve the problems I am presented with at work. While LabVIEW and TestStand were my key value propositions as a new hire, I quickly found myself gravitating toward C# as my tool of choice. This is in no small part due to the clunky nature of interacting with ActiveX APIs in LabVIEW.
After spending some time programming in C# I have found a number of things about it that I really enjoy. There are extraordinarily useful features of the .NET framework and C# itself that get me excited to tackle complex problems. Some features of .NET/C# that I miss in LabVIEW include include generics, lambdas, LINQ and interfaces.
However, my experience in LabVIEW had taught me to approach problems in a way that began to challenge my ability to develop in C#. Dataflow and parallelism as core elements of LabVIEW development had caused me to think of every problem as an opportunity for concurrent operations. As I began writing more "traditional" code in C# I was immediately looking for ways to create parallel branches of execution and spawn asynchronous processes. This can be daunting when first learning about concurrency in traditional text based languages, however my LabVIEW experience gave me the tools I needed to jump right in.
Text based languages are naturally suited toward procedural programming but concurrent programming can be a much more difficult proposition. It is both difficult to reason about and to visualize concurrent software structure in a text based language. LabVIEW solves this problem with it's graphical element; in my opinion this is one of the true powers of the language. It makes concurrent programming accessible to even novice language users.
To explore the differences in concurrent programming in C# vs LabVIEW let's first look at the classic example of LabVIEW concurrency in action, the producer-consumer design pattern.
This simple architecture is one of the first a novice LabVIEW programmer will learn on the path to good LabVIEW coding practice. Despite the simplicity of this diagram, the application structure is actually quite complex. Few introductory programming courses for text based programming would have a novice building an application with this structure and for good reason.
Let's break it down. The primary things to notice here are the following:
Implementing this producer-consumer pattern C# is not a huge leap but it is certainly more difficult to visualize, and in my opinion, is therefore less accessible to a newbie programmer. Let's take a look at the C# implementation.
As you can see, there are certainly more details for the programmer to be aware of in the C# example. The downside of the LabVIEW approach is that working at that level of abstraction removes the flexibility to do more advanced things. For instance you lose the choice of whether to use a simple queue versus a concurrent queue versus your own queue class. You're kind of stuck with NI's implementation of the queue.
Moving from designing software in LabVIEW to doing so in C# has taught me that LabVIEW is an incredibly effective tool for teaching high-level software architecture concepts. I came out of my development experience being able to immediately grasp the concepts of concurrent programming in C#. That knowledge is also is much more accessible due to it's graphical nature. I have gained an extensive understanding of software design patterns, system architectures, messaging strategies, FPGA and RT design considerations and many more software engineering concepts through LabVIEW. The icing on the cake is that I was able to gain all that experience in just 3 years of my professional experience with the tool.
Owen Search is an Avionics Test Engineer at SpaceX. He is a Certified LabVIEW Architect, Certified TestStand Architect, Certified LabVIEW Embedded Systems Developer, Certified LabWindows/CVI Developer and NI Certified Professional Instructor. C# is his current language of choice but he has a soft spot for C/C++ and a love of LabVIEW. He holds a BS in Biomedical Engineering from the University of Connecticut.