Is LabVIEW A Programming Language?

[Elijah_K]

Is LabVIEW A Programming Language?

Yes.

As a LabVIEW fanatic and enthusiast, I commonly field this question from customers and text-based programmers on a regular basis.At first glance, graphical programming appears abstract and so radically different from C and similar languages, that for many it’s hard to grasp how this grid of wires and colored blocks could possibly represent code.

  While studying for my degree in computer engineering at the University of Missouri, I regularly programmed in C++, Java, and spent many long hours in labs going through the painful process of writing x86 assembly and even VHDL.I was also an avid web developer and had written many programs in a combination of HTML, PHP and Adobe Flash for a research lab at the school.Sadly, I had never used LabVIEW or graphical programming, but I did have one friend who kept egging me on to try it out.He claimed it would make my life much easier and that I could do all the same things I was already doing in a fraction of the time.

When I finally learned LabVIEW after beginning work at National Instruments, it was like a whole new world had opened up to me.It all made so much sense and I found myself wishing I’d listened and saved myself many all-nighters in college.

If you look back at 1986, the year LabVIEW 1.0 was released; graphical programming was a part of the natural progression. Apple had just announced the first graphical user interface ever for the commercial market.The use of computers had previously been entirely through the command-line and it seems logical that only text-based programming was around up until then.

Enter graphical interfaces… enter graphical programming.It was simple at the time, but the concept of dataflow made the representation of information and the relationships between operations to be performed much more apparent and easy for someone without a programming background to understand. It took off and became the foremost tool for anyone who wanted to control a bench top instrument and perform analysis in software.

  These days, LabVIEW has evolved dramatically.  The abstraction LabVIEW provides still enables scientists and engineers to solve complex problems without worrying about lower-level details, but it still has the ability to control more granular aspects of your application and push that same graphical code down to the pin with FPGAs and embedded targets.What would’ve taken dozens of pages of VHDL can now be accomplished with just a few simple VIs in graphical code.LabVIEW is object oriented and open; developers can re-use libraries developed in .NET or other languages.Users can build professional, end-use applications for commercial re-sale.

The flexibility of the development environment even allows users to combine different models of computation within a single application.Dataflow can be combined with text-based *.mfiles or tools like Statechart to take advantage of the strengths of every paradigm.All of these different models of computations are compiled by LabVIEW into a single binary.

Because of the abstraction that is inherent to graphical programming and the investment we’ve made in the compiler, LabVIEW is even smart enough to perform optimizations in the background that result in performance that can often exceed that of text-based counterparts.This is especially true when optimizing applications for multiple cores, which is a growing concern as the personal computer continues to offer consumers more and more cores within a single machine without any significant gains in clock frequency.

At National Instruments, we even develop many of our software products and a large portion of LabVIEW itself in LabVIEW.For those of you who use Vision Builder, you’re using a LabVIEW application that spans roughly 5,000 VIs and is developed by a team of about 3 individuals.The fact is that LabVIEW is a programming language in every sense of the word and it presents users with more options and more flexibility than other monolithic environments.

Why do so many people still refuse to believe LabVIEW is a programming language?Perhaps after 23 years of development, LabVIEW is still just that far ahead of its’ time.

Share your thoughts on LabVIEW as a Programming Language!  Leave a comment below.

[spsuamin]

While I fundamentally agree it is a programming language, my opinion is more jovial in saying that I disagree it's programming cause it's too fun. I am a mechanical engineer and I dislike programming, especially in native languages. Matlab I can accept because it's what I learned first, but I hate that it uses a JAVA background. I love LabVIEW in that I can quickly put together a user interface and the functional code in a matter of minutes. Although at times I seem to get obessed with the apperance of my block diagram and end up wasting time.

[HalcyonAnon]

I've actually been in this argument quite frequently; mostly with computer technology "purists" who state that it is not a programming language so much as it is a program that writes programs; like a pseudo code engine. However, they are obviously wrong. Lol. My argument always comes back to the English language communication analogy, a sentence being a program ; C, Java, python, etc. being the sentence written, and labview and other GPL's being the same sentence just spoken instead of written. My only problem with LV being how hard it is to find a job programming labview! I have yet to find a program I can't make in LV (we used to compete to see who could write various programs the best/quickest; I won ALOT 😉 and yet it's rare to find a programming gig when your weapon of choice is LV. It's disheartening to enjoy writing labview as much as I do (LV developer for 8 years) and have no place to find employment with this tool. Oh well C'est la vie I suppose.

[3dfernando]

No. Labview is an abomination that should cease to exist. Why? This is my top complaint list after years of usage. I consider myself a fairly experienced user.

1. Data types are not clear. How is a beginner (or, for god's sake, an advanced user) supposed to know that a green thick line is different than a dashed purple line? As a colorblind person, I have even more trouble. Using different computers makes customizing a hinderance. It is hard to convert data types because they are not transparent to the user. In a conventional programming language, data types are either explicitly declared or implicitly converted. Labview doesn't do a good job at either.

2. It's really hard to read a code if you don't know what one of the functions in the code does, and it is hard to search online their function. This is particularly annoying when looking up for information in forums. I cannot search an image of a box with squiggly lines inside in Google. I have to know the function name. But if all I have is a print-screen (because many times that's what is shared in forums), I cannot reverse engineer the code without spending a ton of time in dead ends. If it's a Matlab code, for example, I will just type "[function name] Matlab" in Google and learn what the function does and which arguments it takes in a matter of a couple minutes.

3. It's hard to debug error messages through online search. I thought C was unhelpful in their error messages. Well, in my opinion Labview is 10x more useless. Searching online will usually lead to a dead end and hours of offline figuring out what is wrong with the code. That's because using function names is not a common practice online, since the language is pictorial. 

There are many more other points, but these are definitely the main ones. Not being able to debug or understand your code is really annoying.

You can come up with your excuses about how I am not being smart about X and Y. The fact is, Labview has not kept up with how coding is done in the current decade. Any researcher will for sure know how to code at least in Matlab, it is a survival skill nowadays. So Labview is an outdated hinderance that makes for a frustrating user experience every time I (and many other colleagues of mine) attempt to use it. I personally stick to Matlab whenever I can to communicate with NI DAQs (thanks for doing at least that). But sometimes the computer with the DAQ will not have a Matlab license, and then I have to remember all the pain I have to deal with when using Labview. This rant comes, obviously, after another of these frustrating experiences.

Please, NI, stop fooling yourselves. The language sucks. I know you spent a lot of time and resources into it, and I really appreciate the effort. But coding through text is accepted in today's society. It's not a monster it used to be. It is necessary for anything barely advanced. The language is meant for research environments anyway, where engineers are more prepared and already know how to code. 

Hope more people agree with my point of view.