I am learning to use lab view as part of my honours project, and was wondering what benefits the graphical programming language has over a textual one?
I've used labview before for calculating parameters to tune an nMRI machine. They exist because in theory it is easier for someone with little programming language experience create a program. The control flow and decision structures can be arranged graphically and they can type in their formula's where they want.
For professors and lab assistants...helpful. For real software developers...it would be easier to write in another language.
I've used LabView in the past, and for data acquisition, virtual instrumentation, etc - there is nothing better. The last time I used it was 10 years ago, and nothing I've seen since has matched where it was in the mid 90s.
Its all about the equipment drivers and user capabilities. NI (Labview) has a well supported set of lab equipment drivers that are easily interfaced. A test operator (not a developer) needs a gui with a big green/red pass/fail button. I've implemented complicated automation via python in cygwin. A Labview developer was able to invoke the cygwin/python system and data mine the log files. So you can do both. The python system is portable, maintainable, extensible, usable and best of all, free.
Some advantages of LabVIEW in my view are:
The built-in user interface components such as buttons, graphs etc literally require no programming whatever; you just place them on the front panel and the data terminals appear on the block diagram.
There is a large library of drivers for data acquisition hardware and test instruments. If your task is basically about getting data to and from these and putting a user interface on it then you can achieve it with almost no programming.
Parallel execution of multiple tasks is handled automatically - place two independent loops on the diagram and they will execute simultaneously. This is often a requirement in data acquisition and control applications.
Many people, including 'real software developers', feel that the graphical paradigm suits the way they think and visualise their software better than the textual one. There are undoubtedly things that text languages are better for than LabVIEW (covered in another discussion on this site) but where LabVIEW is suitable it's very good at getting the job done.
To me, the benefit of LabVIEW is not in graphical vs. textual.
It's dataflow vs. imperative.
Dataflow programming lends itself to concurrency, because your execution is modeled as black boxes which execute when their inputs are valid, whose inputs / outputs are wired together. This as opposed to implicit state with a list of instructions on how to modify it. (Loosely paraphrasing 'kipedia, the article linked above is better.)
Each black box can run on a separate core/processor/node, which gives you, effectively, free concurrency if you organize your program the dataflow way.
Unfortunately (and this is a crippling downside to dataflow programming in general) the best way to visualize and edit dataflow programs is graphical, not textual. This makes using tools such as revision control and code generators very difficult.
The question is: Do the pros of dataflow outweigh the cons, for you and your project?
One of the main advantages to graphical programming with LabVIEW is that the source code is very similar to circuit diagrams, so it's a very easy language for electrical/electronics engineers to pick up. This is one of the reasons that LabVIEW has become so popular in the data acquisition and automation fields, where EEs are plentiful.
Another advantage that I found was raw speed of development. You assemble your GUIs from a palette of available front panel controls, very similar to how you do it in Visual Studio. The source code is written in a similar manner, with many pre-defined components that you can drop in from menus and wire together.
A third advantage is compatibility with hardware. National Instruments main business is data acquisition hardware, and they go to great lengths to make sure all of their products can communicate with LabVIEW software straight out of the box. Many other hardware vendors in the data acquisition and automation control industry are doing the same.