The pros and cons of LabVIEW

[altenbach]

This is a generic post to possibly continue the discussion started in an unrelated thread.

Feel free to express your opinions on the pros and cons of LabVIEW as compared with more traditional, text base programming languages. 🙂

Message Edited by altenbach on 08-09-2008 10:47 AM

[TechWiz]

The pros are too many to list but here a just a few to start with

1. Graphical interface is flexible and easy to use without any programming skills

2. provides a universal platform for numerous applications in diverse fields

3. can be used with 3rd party hardware - can be interfaced with C/C++, VB, fortran etc etc. the list is too long!!!

4. has excellent customer support- this forum is a testament to that.

Cheers!!!

Mani's World

[cschneider]

Yeah, there are really much pros for LabView, beginning from device-drivers to easy-programming. But I want to focus in this post on the disadvantages of LabView, hoping there will be some workarounds in future releases:

- Memory management: I have to transfer much data (about 200 MB) over one wire. By using several sub-VIs, the amount of memory needed for my application increases very fast. I already tried using queues to transfer data, but control over memory-allocation / deallocation can't easily be done... perhaps a switch in the connector pane of subVIs saying "transfer data by pointers" could be helpful
- Data structures: I am using some C++-DLLs for data analysis. As there are sometimes some structs in the function-arguments-list, I had to write a wrapper-DLL. Perhaps there's a possibility to get this compatible... it would be nice if an array of a cluster could be converted to an array of a struct.
- Speed: In some applications, I already realized that the speed of LabView can be improved by rewriting LabView-Sub-Vis into C++code. I think this is due to the LV-runtime-engine which has to "convert" the binary code of labview into native code??? Would be great if it would be possible to generate native code directly.
- Expandability: It's hard to implement new functions into a already written LV-Program. By using design patterns like producer-consumer, the expandability is improved in comparison to a "normal" LV-program, but in comparison to a text-based language,  LV still stands back

What do you think about the points above?

Greetings,

Christian

[mikeporter]

Taking your points one-by-one:

Memory management: If the code is written properly, this is essentially a non-issue as the processing will be done inplace. If you write code such that memory space reallocation needs to be done, LV will perform poorly - especially with datasets the size of which you are handling.

Data Structures: This is only an issue if you decide to write part of your code in DLLs  or need to call a specialized DLL that expects a struct as an input. I have never seen the first to be necessary, the second is rarely needed.

Speed: Since version 2 LV has been a compiled language. The runtime engine needs to perform no further conversion at runtime.

Expandable: This is only a point if you start with the assumption that the "normal" LV program (to use your terminology) is poorly written. I, of course, can't speak for you but mine are well-written. Regardless of how they are created, well written programs are Scalable, Readable and Maintainable. If someone chooses to write a program poorly, that is not the fault of the language. Or perhaps we should blame C++ or C# for the deficiencies of VIsta...

[Lavezza]

Pros:
1) Dead simple to create a GUI. In fact, you have to 🙂
2) Incremental compile of VIs gives the same interactive environment that makes languages like Python, Perl and Ruby easy to work in
3) Cross platform, for the most part
4) This first time I showed execution highlighting to a C++ programmer, all he said was "wow"
5) It keeps getting better. Each release adds more features to make programming in LabVIEW easier (well, maybe not 8.0 🙂

Cons:
1) Many things are 'hidden' on the block diagram. Key navigation, Data Binding, Min/Max Coercion, etc. can't be discerned from looking at a print out of the block diagram. You should be able to reproduce the code from a paper print out (not that I'd want to).
2) Code & Binary in a single file makes source control more difficult. We have to document why each file changes from release to release. We end up with hundreds of VIs that change simple because they call a subVI that changed.
3) Price. I think a lot of people don't try LabVIEW because a 30-day eval of a development environment isn't enough. We compete with Java, C#, C++ and others that are all free. Sure, you might have to pay to get the 'Enterprise' version of these environments, but you can make that decision after you have a working application. NI should release LabVIEW Full for free, LabVIEW Pro for a few $100's. If Jeff K. wants LabVIEW to be to engineers what Excel is to business, it needs to be priced like Excel, at least at the ground level.
4) GUI elements need a big update. Look at the capabilities of the various .Net GUI libraries that are available, we should have that in LabVIEW. For example, status bar for bottom of window, Grid control (think table but with booleans, combo boxes, etc. in any cell, easily rearrange columns, sort by clicking on header, etc.)
5) Can't extend the development environment. For example, LV supports Perforce and any system that uses the MSSCC for version control. Since Subversion doesn't support MSSCC directly, you need a third party utility. On Mac & Linux, Perforce is your only choice. Now, the Perforce support in LV just calls the Perforce command line. There is no reason someone couldn't write a set of VIs that mimic the Perforce VIs but call the Subversion command line. But there isn't a easy way to get those Subversion VIs to work with the LabVIEW editor. Things like this should be more open. (And I should be able to set shortcut keys for items dynamically added to the project menu)

[mishklyar]

Pros:

It is very easy to write a small program ( Acquire data, analyze it, save)

Cons:

It is very hard to write a big program ( > 100 VI ) and requires a lot of experience so that it would  still manageble. One should know many tricks like :

  1) Call by reference VI

  2) Functional Global

  3) Strict typedefs

  4) Managing sizes of array by "reshape"

  5) etc...

[Pnt]

mishklyar, all those you wrote, are basic programming technics for LabVIEW.

Not advanced tricks.

You just need a different way of thinking, from a text based language

[Intaris]

Pros:
Parallel code execution
Visual programming style
Fast execution speed (when you know how of course)
Perfect for Quick&Dirty solutions
Getting better all the time for larger projects
Lots of toolkits available
Fairly slick IDE
Bug reports are reacted on
Windows, Linux and Mac support
LVOOP

Cons
It's called LabVIEW
Non-extendible IDE (At the moment)
Most toolkits only under Windows
Need to buy a full licence for each platform (Win, Linux, Mac)
Relatively expensive
Makes me always want a bigger monitor (for multiple diagrams, not sprawling code )

I'm most definitely a fan.  Love LV on the whole.

Shane.

[Ray.R]

Intaris wrote:

Cons
It's called LabVIEW
Need to buy a full licence for each platform (Win, Linux, Mac)

Yes!!  The name LabVIEW...  

I edited my reply before posting only to see that I would have been repeating what others have already said:  http://zone.ni.com/devzone/cda/tut/p/id/5313

http://forums.ni.com/ni/board/message?board.id=170&view=by_date_ascending&message.id=347980#M347980

It's evolved to more than being just a "Laboratory Virtual Instrumentation Engineering Workbench".  It is a full-fledged software language...  Not limited to laboratory applications or to be a virtual instrument.

Maybe it is time for a change of name.

R

[TechWiz]

Joe LabView Wrote

---

It's evolved to more than being just a "Laboratory Virtual Instrumentation Engineering Workbench".  It is a full-fledged software language...  Not limited to laboratory applications or to be a virtual instrument.

---

In my humble opinion, if you look at the individual terms in LabVIEW as Joe mentioned, it tends to encompass a lot of ground from virtual intrumentation to all fields of engineering. It is no doubt an advanced programming software/language but its basic strength lies in the simplicity of the Graphical coding capability.

LV is not a bad name afterall. Java, C/C++ etc. etc. also don't convey the potentials of those languages.

Cheers:)

Mani's World


Message Edited by Mani's World on 08-10-2008 11:11 AM