The pros and cons of LabVIEW

[muks]

Well to me pros are

• Graphical vis require  minimum keyborad interaction
• errors are immediately projected and ned to be corrected Instead of showing the line number and you get mauled by some 30 odd errors after correcting the single eror and u r wondering if had actually corrected or fixed some thing or u have broken some poisonous pipe.
• really fun after a few months of working on it
• ease of configuring device drivers
• Time taken for coding is very less compared to other language like vc++..
• User interface screen can be neatly and beautifully made in a very short time.

Cons

Yeah they do have many

• Memory allocation and memory management is still a mystery...........
• Requirement of deployment licence every time u utter the word vision.
• Pricing(Isnt it a bit on the costlier side?)
• Not all cameras can be used using LabVIEW.
• Only NI FPGAS can be programmed with LabVIEW and to imagine who grt it wudve been programming an equivalent verilog for my spartan kit.Hmmmmmmmm
• And...........
  

[muks]

And altenbach I would defenitely like to hear your thoughts........

[Ben]

As one who has already "drunk the Kool-aid" I standback from the pros and cons, with one exception the name. Although engineers and scientist may not think twice about anything involving the word "lab" but for the non-engineer and scientists, "lab" is a scary word.

 But to help those who are interested in optimizing performance, I have collected many links to threads that address the various issues and can be found in my Tag...

 LabVIEW_Performance.

If you read through all of those links and their related links, you will be on your way to being a LabVIEW Speed Wizard. I invite all of you to do so. We need someone who can keep Christian honest and another Speed Wizard is always handy to have around.

Ben

[drval]

Let me sum up what I'm hearing, and what my experience is:

Pros:

Virtually everything, esp for someone who has never programmed before, nor started programming learning text-based languages.  The truth is that there is virtually nothing that can't be done in some way in LV, including bringing in .Net code, etc.  Core LV code can compiled "as is" across  multiple platforms, including embedded applications.

Cons:

Virtually nothing UNLESS you started with text-based programming, then many of the real strengths of LV appear to be weaknesses.  This is really because, what are actually weaknesses in text-based languages (eg the NEED for memory management) that text-based programmers have learned to cope with, confuse those programmers because those functions are either not available (because they're not needed) or are accessed in ways that differ from what text-based programmers are used to.

Bottom line -- the real issue is that LV is a true graphical environment for system design and implementation that supports true parallel execution, highly optimized memory management and algorithms (as long as one programs well), is very forgiving and is available to almost anyone.

re: cost.  I think if you compare the cost of getting the Professional Development System -- along with some courses -- and compare that to the cost of getting traditional text-based languages and ALL of the courses, support, additional libraries, components, etc that you need to actually be productive in text-based languages, I suspect that LV will not only be comparable in overall cost (in terms of time and money) but will actually be cheaper overall.

The real truth is that it's just too easy to use LV and become a functioning, effective system developer without the need for a CS or EE degree -- and I think that's really upsetting to a lot of people.  Easier to dismiss LV as being a "toy" instead of actually getting into it and discovering how powerful, full-featured and elegant it actually is. 

[F._Schubert]

Pros:

* it's graphical

seem obvious, but consider: text-bassed OOP-programs have spent a lot of time to develop graphical representations like uml. One of the problems they face is to keep the doc and the code in sync, in LV it is always the same. But: we need more tools to interchange LV-code with uml...

* Really fast prototyping;

I really don't wnat to say software developement, as that means a lot of testing, evaluation of use cases and so on. But using MAX, DAQ-Assistant, Express VIs it's really fast to compare/understand different algorithms of signal pocessing (or else) and selecting the better one.

* You really don't need to care about MemAlloc, NullPointerException and all that really nasty things, that modern tex-base languages anloy give their users with a warning sign (I think it was C# that has a 'unsafe pointer' expression), and yes, I still shoot down LV with the task manager several times a day.

* VI server technology: It's incredible powerful: over a network - run as win service - use vit's to create multiple instances of a vi (did a pop-up menu that was attached to every graph in a vi where I just placed to VI, having all kind of save data, save image ...) - launching indepedet running processes (connected to main prog via queue), to conclude, I can do so many things with it, I would need multi-inheritance in text-based OOP (which get's messy).

Cons:

* Bad reputation as a tool for Lab-Rats that can't write real code, though NI tries their best. People told me, that Event handling was not possible, File Dialogs were slow,  ..., but they even didn't managed to get two buttons to be the same size, though what?

* Outdated GUI interface (you can't dynamically create control 'on the fly'), last real face-lift was 7.0, though X-Controls might give more options.

But:

every language has some paradigms, so I wouldn't use (or would I?) LV for: textual analysis, mathematical calcs (when writen in text only, esp. whe recursion is needed), web programming. There are languages especially made for that. 

And: I would say it's really ok for big projects. I do complete ATE with max 1000+VIs today. But I'm not feeling that LV is limitating me. But it's software engineering then and not Prototyping.

Felix

[stha]

Cons (or the list of things I don't know to do efficiently with LV because I'm a new user):

 1. Binary source file make multiple check out and merge difficult. Comparaison of different file versions seems inefficient.

 2. Corollary: you can't work in a task branch (sand box)

 3. No scripting?... How do you deploy continuous integration in your LV environment?

 4. Limited to Microsoft Interface for file versionning system. Can't use modern tools such as Mercurial, GIT or Subversion

 5. Proprietary language

Like I said, my list might only be the list of things I don't know how to do in LV, not the list of things LV can't do!!!

PS: People trying to compare LV to other langages in terms of "mine is better than yours" are missing the point. You should simply use the best language adapted to the problem in hand. Don't limit your mind to "one size fits all" utopia. There is more than LV, C++ and Java. Other languages are great too: Ruby, Python, Erlang, just to name a few...Ever tried to make a cloud of 200 pcs work together in LV? Of course not! That's a task for Erlang!!!

[mikeporter]

In terms of your points 1 and 2, these issues are so much a problem with LV as they are with the primitive source control application you are using.

Point 3, there is scripting, but it is only accessible through a separate license. Though I'm not sure what you mean by "continuous integration".

Point 4, simply incorrect. I use Subversion and have since LV 7.1, and it works fine.

Point 5, you got me there - but who cares?

Mike...

[BlueTwo]

In addition to the technical advantages described by others, one big plus point is an active development community and prompt support from NI. That made being a nubie a lot easier... 

[stha]

Hello mikeporter,

pt 1 and 2 : For text-based code I use Beyond Compare which is far from being primitive. But it is not adapted to graphical language. What would you suggest for LV?

pt 3 : Are you refering to test stand? Great article on continuous integration here.A short description of continuous integration would be: Every submit (or check in) of source code in the repository is continuously synchronized (check out) on another pc an unit test, regression test, etc. are executed. If a test fail, the submit is rejected (rollback).The goal is to continuously validate your software, as opposed to long iterations of design, dev, test, release, etc. It goes in the line of agile development.But all that is easier to deploy if you can automate your build and tests using some kind of scripting language.

pt 4 : I use SVN too, but integration with LV IDE is possible only through a third party proxy which emulates MS interface...

pt 5 : well... me... obviously. But others too if you read the previous posts. But I guess you don't and that's alright.

Thanks in advance for any tips you can provide on pt 1 and 2. So far, my approach is to limite the size of any VI as small as possible to avoid any collision between developpers and lock files while I modify them.

Regards,

Message Edited by stha on 01-06-2009 10:01 AM

Message Edited by stha on 01-06-2009 10:03 AM

[mikeporter]

Concerning my comments on your points 1 and 2, a source control system might provide a lot of features but if it assumes that input files are only text and is non-extensible to manage binary datatypes, it is a fundamentally primitive package. I would recommend Subversion. Currently integration with the project window is not available without a commercial plugin from PushOK (which I haven't tried). But given the availability of TortoiseSVN I haven't missed it as that interface gives you the ability to do the things you were asking about - managing updates, diffing files, etc.

Point 3, No I'm talking about LV scripting. Do a search for scripting here and on LAVA for more information.

Point 4, TortoiseSVN works great and I have no trouble managing work using it. Just be sure that you have LV configured correctly, otherwise you can be saving a lot of incidental "changes" like recompiles due to a typedef changing.

Point 5, I realize that there are a lot of people for whom the "freedom" of software is a closely held philisophical issue - which is fine. But for me functionality is more important that philosophy. When you get right down to it most customers don't care what development environment you use as long as the software works when they get it. So yes there are versions  of other languges that financially and philisophically free, but they would impose far longer development cycles, and for me my time has value. Hence, for me the cost of a "free" development environment is far greater than what I pay to NI for a LV license.

Mike...