Labview as a general purpose programming language

[WayneS1324]

Does anyone consider this? I have several porgrams I have written in LV, including some for work, that have nothing to do with data

acquisition or whatever.

What are your thoughts on this?

[Bob_Schor]

I've started doing this, as well.  I find that LabVIEW's graphical organization and strong data typing, particularly when combined with "good habits" (such as writing documentation, using Sub-VIs to keep diagrams "clean" and "one-screen" in size, and taking advantage of structures such as State Machines and Event Processing) makes for fairly rapid program development, easy debugging, and a higher probability that it "works right" the first time.

I can imagine that the "overhead" of handling all of the graphics might make the program run a little slower and take up more memory/disk space than if it were coded in some other language.  However, with the speed and memory/disk size of modern PCs, this should (even if true) not be a major impediment to developing "non-DAQ processes" in LabVIEW.  In my own case, the ability to write clean, mostly-works-the-first-time code that is largely self-documenting (though I do force myself to fill in the Documentation property on every VI) makes this one of the nicest programming environments I have experienced.  It can't handle every programming tasks (there are "specialized languages" that do the specialized jobs better), but it's done a lot for me.

Bob Schor

[smercurio_fc]

You may wish to read this: http://zone.ni.com/devzone/cda/tut/p/id/5313

or perhaps this: http://forums.ni.com/t5/LabVIEW/Is-LabVIEW-a-4GL/m-p/676071

or perhaps this: http://forums.ni.com/t5/LabVIEW/OT-LabVIEW-is-a-5G-programming-Language/td-p/969017

[Mark_Yedinak]

I have been doing this for the past 10 years. At my present copmany we have a total if 1 DAQ device and it is used infrequently. All of the other automation we have developed is pure LabVIEW code. We have literally dozens of applications, utilities and automated tests running. I have developed code in assembler, C, C++, several scripting languages and LabVIEW. The language of choice for me is LabVIEW. I have even discussed this with folks from NI at NI Week on several occassions. I would like to see LabVIEW promoted more as a general programming language. I think they could also do a good job working in the realtime embedded arena.

[Spectre_Dave]

I have used LabVIEW as a general purpose language from when I first used it 20-some years ago.

[SteveChandler]

When I was first exposed to LabVIEW I didn't think of it as a "programming language" but an application for making "virtual instruments" out of several pieces of test equipment. The idea of LabVIEW as a general purpose programming language was stupid (at least to me). I don't think NI even marketed it as such. If memory serves me it was not possible to move a subvi on a block diagram unless you first disconnected all the wires. That was a long time ago. When I first saw a mouse I thought it was a fad that would never last.

Now I write all sorts of programs in LabVIEW with a mouse! It really has evolved over time into a very good general purpose programming language. But it is still not the right tool for some jobs. Only when NI writes the runtime engine, compiler and development environment entirely in LabVIEW will I consider it apropriate for any application.

[altenbach]

I use LabVIEW on a daily basis for any computing task imaginable. Very few of my programs interact with hardware in any way. 🙂

My brain is more visually oriented and I my thought process is highly nonlinear. LabVIEW is a much better match and works similarly to the way I think and much closer to the way the world actually works.

If you think about it, the confines of text programming are severe. Having to express your thoughts as a linear string of characters in a primitive language is not optimal! 😄

[SteveChandler]

---

@altenbach wrote:

If you think about it, the confines of text programming are severe. Having to express your thoughts as a linear string of characters in a primitive language is not optimal! 😄

---

It is like that with written language. Look at these letters. What do they convey? At the very basic level they only convey sound. It is the representation of spoken language which is a representation of thought. Naturally over time we look at print and, if we are good readers, no longer think of sound - our brains convert the symbols for the words back into actual thought. There is kind of a runtime engine working in the background of our minds when we read.

But that is English. The Chinese written language is symbolic. Instead of pictures of sound they draw pictures of thought and have a much easier time communicating in a written form. English and most languages are like text based programming and Chinese and some others are more like G.

Chinese people can open a book written a thousand years ago and read it like yesterday's paper. They can even communicate in written language even though the spoken dialect is entirely different. Try reading a four hundred year old English text or understand someone from the Bayous of Louisiana. "Jeet?" *

But we do something similar when it comes to numbers. When you see "4321" that is not a representation of the sound - that would be "Four Three Two One". You can look at a number written thousands of years ago and know exactly what it means. You can write an equation and it can be understood in English, German, Chinese, Spanish or anything else.

End of pointless rant comparing English to text-based programming and Chinese to LabVIEW.

* "Have you eaten?"

[dthor]

I use LV for instrument control and automation. I have no idea how to use a NI DAQ device, as everything I do is just instrument communication via GPIB. Already LV is more than just a data acquisition language. On top of that, I've started to write code that just makes my life easier. I need to get data from Excel into a strangely formatted config file? Labview. I need to set up a timer and alarm for one of my tests? Labview. I need to send out an email periodically? Labview.

I tend to think that LV can be used as a general purpose language, though it is slightly more limited than others. No, I have no examples of this 

[10Degree]

For me, I would say that easily one half of the development work I do could be classified as "general programming" (GP) and I use LabVIEW to do that work.  Our company makes instruments for measuring color (spectrometers, colorimeters, densitomiters, etc) and I am involved in the front-end development of new instruments where I use LV, FPGA, and other DAQ and I/O for prototyping.  As projects progress, my development tools shift from raw HW interface and control to measurement and analysis tools.  My SW product becomes more of a GP effort and I stick with LV for the back-end tools because I can port most of the front end into the back-end application.

That is not to say that LV is the best tool for the GP job - for me, it is a convenience and efficiency / reuse thing.

For me, there are two main irritations with LV as a GP tool.

1. Clunky UI design and management
2. Headaches with deploying the run-time and the versionitus / incompatibilities that goes along with the RT

If National Instruments could provide UI design on par with Microsoft's Visual Studio, or Embarcadero's Delphi, and the ability to deploy a more standard EXE and forgiving run-time library (rather than engine), I could rule the world.

-cb