Presentation - Why LabView is better than C++

[Mark_Yedinak]

---

lmtis wrote:

---

Btw. what is your source of the mars rover? I thought they where programmed with VxWorks and C. 

---

I believe that LabVIEW was used for the earthside health monitoring system, not the embedded code on the rovers themselves.

---

Either way Ibelieve that my earlier statements are accurate.

[tbob]

To answer the original question, speed of development is probably the biggest advantage of using Labview over C.  Try developing a simple "Hello World" program in C, measure the time it takes.  Then do it in Labview and measure the time.  I just did this in Labview (a string indicator with "Hello World" constant wired to the indicator).  It took me 15 seconds, and I'm slow.

Other good arguements are ease of use, ease of maintenance, easier to understand, easier to another developer to modify the code.  All of these are time saving advantages to developing in Labview over text based languages.  But the best arguement is that Labview is just plain more fun.

[Mark_Yedinak]

I would also add the inherent support for parallel tasks. LabVIEW can take full advantage of multicore processors without any code modification. In traditional text based languages you have to explicitly develop your application to be thread safe and capable of taking advantages of multicore processors.

[WG-]

---

Mark Yedinak wrote:

---

lmtis wrote:

---

Btw. what is your source of the mars rover? I thought they where programmed with VxWorks and C. 

---

I believe that LabVIEW was used for the earthside health monitoring system, not the embedded code on the rovers themselves.

---

Either way Ibelieve that my earlier statements are accurate.

---

I doubt after finding, http://findarticles.com/p/articles/mi_m0EIN/is_1997_July_18/ai_19593795/?tag=content;col1, on google. NI even quote the article their self so I don't doubt it's legitity, http://zone.ni.com/devzone/cda/tut/p/id/8344.

Also I just doubt it very much that labVIEW has been running on the Rover, with it's immense time critical tasks. I'm ready to change my opinion if you can give me a reliable source of course.

[smercurio_fc]

Let me play devil's advocate for a moment...

All of the arguments for LabVIEW notwithstanding (and as you have no doubt discerned, the majority of them here are going to be pro-LabVIEW), I don't think that the issue of familiarity with a specific programming language should be overlooked so readily. The OP stated that new members and a manager came aboard and they are not familiar with LabVIEW. They are, presumably, quite comfortable with another programming language (in this case C++).  Good C++ programmers can be just as productive as LabVIEW programmers. However, ask that good C++ programmer to write some LabVIEW code, and you will most likely end up with code that will get ridiculed in the "Why local variables are bad" thread or the "Rube Goldberg" thread. Is the company now better off? That's a hard question to answer because it depends on what the company does. If all this code is for internal development, then what are they actually coding up? Some basic tests? Some instrument drivers? Do you really need LabVIEW to make good code for this purpose? Do you really need multicore capabillity for talking to GPIB instruments, especially since the GPIB bus can't do multiple communications at the same time? On the other hand, if they're creating a large-scale test suite then it's most likely that they would need to look at something like TestStand (or something equivalent from another vendor), and in that case, the actual modules that get called from TestStand can be written in C or LabVIEW. 

While it's true that there's a lot of instrument-related functionality in LabVIEW, it's also true that a lot of it is really tied down to NI-specific hardware. All of the DAQmx stuff can only be used with NI DAQ hardware. Sure, you can use DAQ hardware from other vendors by use of DLLs, ActiveX, or .NET, but LabVIEW soon looses the niceness of its development environment for these technologies that it usually has.

Well, my moment is up...

[Mark_Yedinak]

One other point similar to the post above though is if you switch languages will this application need to be rewritten in the new language? How much existing code do you have that will need to continue to function and need to be maintained. If this code base is large changing languages can be risky and result in a significant amount of development that basically reinvents the wheel.

[falkpl]

One thing to consider is do you have the resources to program in either.  If I had a team of experienced c programmers who never used Labview or vice-veral this could greatly sway my vote as a manager.  A development environment is just a tool.  I would say that I am at least 10x faster in labview than c but this is because (yes I do know c and spent many years programming in c as well) I primarly develop in labview.  I have seen this argument between almost all languages (why labview vs python vs c# vs c vs ......)

What language are your programmers most proficient in?

[PurpleOne]

Here is the current programming experience

Designer of the system knows labview

I know labview and C++

New member knows C++

Manager(who will never work on the system) knows C++

 The system has been in place for almost ten years, has a large test data base in place with almost 500 test cases that will have to be ported over.   The main thing is they don't understand it so they want to change.  My things I don't think its worth the time and the effort to basically change everything just to change the development environment.  If you can learn C++ you can learn labview.  I can't think of anything that you can do in C++ that you can't do in labview.

So far I have speed (unless you don't know the language),parallel tasks is plus because they think that is advantage going to C++ and in the future we will be doing this where could I find more info on this?, gpib boxes will only be for regression testing in the future everything will be lan based and like I said we already use labview so all of test equimpment works with it.

The system will need enhancements and the code could probably use some cleaning up but nothing major.

I did a search on the forums to find some more info comparing the two and didn't find much could someone point me in the direction to find more info on this?  And keep the comments coming I appreciate the feedback.

Like I said my preference is labview and teststand and I would like to give them something to go that route.

[Dennis_Knutson]

Pushing TestStand is a good idea since you can readily use either LabVIEW or C++ (or .NET. etc). TestStand does not care what you use and one step could be a LabVIEW module and the next one a C++ module. In my case, I created nothing but custom steps and the end users have no idea which language was used.

[Mark_Yedinak]

GIven that this system will need to be around can you estimate how long it would take to rewrite it? If the system is fairly large which it sounds like it is this can be a significant task. You also run the risk of introducing bugs since it would effectively be a complete rewrite. Based on the existence of the system and that most of the team (I'm not counting the manager) know LabVIEW I don't see any compelling reason to make the switch other than a "not invented here" attitude.