LabWindows and LabView Comparison

[hendra@ngms]

Has anyone out there written a comparison between LabWindows and LabView?  If so, please post it.

I need to provide a potential employer information to provide to a potential client, why the client should consider LabWindows instead of LabView.  I'm trying to do this without introducing my severe objections to LabView.  Yes, I keep hearing that both have their strengths and weaknesses, but I can't figure any strengths to LabView when it comes to large complex projects:  It requires an expert to design and develop, and an expert to maintain, and cannot be documented.

[menchar]

This is the oldest topic on the forum I think, there are several very long threads on it if you do a search LabView Vs. CVI.

I think it's fair to generalize the sentiments expressed on those threads that if a developer knows C, he or she is more likley going to want to use CVI than LabView.

I think 80% of NI's sales are LabView, not CVI.

I do grow weary of slinging gobs of C but that's still prefereable to me in terms of having a finger on what's actually happening "under the hood".  I find LabView mostly appeals to scientists and engineers who are not capable C developer and don't want to be.  And having had to deal with lots of very badly done C code from scientists / systems engineers I say let them eat cake!  er, ... let them use LabView!

Menchar

[RobertoBozzolo]

I agree with menchar that this is a very addressed topic on the forums: here you can find my personal answer to this question but a simple search will return you dozens of comments on this item.

On the other hand, I think some comments to hendra post are necessary.

The best code documentation is the one hand written by the analyst and the programmer before and during coding. It cannot be limited to the simple list of parameters of a function or so. In this respect, LabVIEW or CVI or whichever language you choose it's not relevant: the most important thing is that program functions and flow are described in a clear and exhaustive manner and this can be done in LabVIEW as in all other languages.

"It requires an expert to design and develop, and an expert to maintain": this is true for LabVIEW as it is in all languages: the more complex an application is the more skilled the programmer needs to be, regardless the language used. (BTW it seems Rube Goldberg has trained tons of programmers: here you can find some LabVIEW gems but I'm sure each of us can remember his or someone else's examples of it )

As per your opinion regarding the use of LabVIEW on large and complex applications, it's a long time since I have used it in a commercial application so I cannot comment it but I suppose every skilled LV programmer will be able to list several big applications he has seen or coded.

While reading this post, please consider that I'm 100% a CVI addict, but I've coded with several languages in my life including LV and I consider that those opinions were too general to be addressed only to LabVIEW.

There are other informations that can help to discriminate this choice, for example whether the end user will acquire the code or the compiled application only, whether he is able to maintain it by itself in the first case (and in which language does he has or can borrow specific skills) or if he trusts the original producer for maintenance of the application over the years (in which case specific skills of the original programmer should be the relevant argument).

[wally_666]

I think 80% of NI's sales are LabView, not CVI.

---

Go to NI's top level web site.  You practically have to know the secret handshake to find out that CVI even exists!

I'll sum up my objection to LabView with a simple analogy.  Its like trying to design a circut by drawing the schematic and PCB layout at the same time.

LabView has very seductive demos and a top notch sales team, when my non-programming colleagues buy it and actually solve their problems with it, its a tremendous value.  But usually they quickly give up and call on someone like me which then makes it a total waste.

--wally.

Message Edited by wally_666 on 06-26-2009 07:59 AM

[hendra@ngms]

Thank you Menchar, Roberto and Wally.

I will do some searching and reading on the comparison.  I used the wrong search term at first, so did not find the old threads.

I like your analogy Wally.

I hear what you are saying about documentation Roberto, but I disagree about documenting LV projects.  I write some fairly large projects deliverable to the Navy.  These systems will be in use for a decade, maybe two.  Hardware will change, requirements may change, so it is important that my LW projects be maintainable by someone other than me.  I profusely comment my code and provide detailed information at the head of every function, as well as external documentation.  This is what I would want if a project I did not write were handed to me.  I don't see anything similar in LV, and therefore I see it as very difficult to maintain a large LV project.

As an example:  About 18 months ago I was handed what I would consider a large LV project, done by a small out-of-house company, in LV.  There was interest in doing a technolgy refresh on this system that the Navy had been using for several years.  The project consisted of one or two GUI pages, and many very large pages of LV interconnect.  Separate from the project itself was a document describing the system -- about 300 pages long, describing every VI (hundreds of custom VIs in there), but very little describing how the system worked.  I struggled with this for more than a week, trying to get this LV 5 or 6 app, which was supposed to execute under NT, first to work under NT, then to transfer to LV 8 and XP.  I gave up and told the customer that I could rewrite the whole functionallity in LW in a fraction of the time it would take me to crack the LV problem.

[RobertoBozzolo]

Well, hendra, it seems to me that you faced a typical example of poor documentation not strictly related to LabVIEW. A few pages more added to that huge and ponderous document could have given you the idea of the whole picture before pointing you to every single brushstroke. But this could happen even in a C or C++ application, dont you think?