Presentation - Why LabView is better than C++

[RavensFan]

It sounds like it would be worth the investment to get the new programmer the year's worth of NI training at about $5K.  Maybe even have the manager attend Basics, or one of the NI technical symposiums.

If the programmer is a good C++ programmer, and has an open mind, he should have no problem learning LabVIEW.  With getting the manager some exposure as well, maybe they'll learn enough to be comfortable to stick with what is tried and true.

Message Edited by Ravens Fan on 03-29-2010 10:31 PM

[smercurio_fc]

---

PurpleOne wrote:

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.

---

I can. For example, object-oriented programming in LabVIEW isn't the same as the object-oriented programming that you do in C++. There are several differences, and some of these may prove to be quite annoying/cumbersomelimited/ridiculous (depending on the attitude of the programmer) to someone who has been trained in more conventional object-oriented programming. Personally, I find doing object-oriented programming in a language such as C# far more "natural" than trying to do OO in LabVIEW. Maybe that's just me though.

Another important aspect is source code control. Most, if not all, of the source code control tools are really geared towards text-based programming. Sure, there's ways of making it work with LabVIEW, and I use subversion with the LabVIEW development here. However, there's certain things that you simply cannot do since there is no text-code for LabVIEW VIs.

Another important aspect is the simple fact of LabVIEW versioning. A C++ program is pretty much backwards-compatible. Not so with LabVIEW. Is this an important factor in your company?

Still a little bit of the devil's advocate...

[Mark_Yedinak]

---

smercurio_fc wrote:

Still a little bit of the devil's advocate...

---

I'd say more than just a little. However the points you raised are all very valid and should be considered.

[smercurio_fc]

---

Mark Yedinak wrote:

---

smercurio_fc wrote:

Still a little bit of the devil's advocate...

---

I'd say more than just a little. However the points you raised are all very valid and should be considered.

---

I just like to stir up trouble.

[Purp1eOne]

Source control is not really an issue.  We already have that in place for our current code. 

Object oriented programming is really not the issue either and our code is labled/tagged so that is not either.

Come on now enough of the devil give me some positive stuff.

[lmtis]

---

Purp1eOne wrote:

Come on now enough of the devil give me some positive stuff.

---

You have a functional existing base of code, and LabVIEW is easy enough for anyone who is competent in another language to rapidly get productive in.  How much more positive can you get? 

[RGreg]

I wrote on my blog about this almost three years ago, and that particular page still gets plenty of hits.  Back then I wrote that LV was preferable because a) it was designed with test and automation in mind and b) it has an active champion (NI) promoting and improving it.  Programming in LV is smoother now than it was just 4 years ago - a LOT smoother than a decade ago.  Thank NI for that.

Nowadays, I would add another good reason for using LV over C++.  You can phrase it as, "a picture is worth a 1000 words," or as Napoleon said, "A good sketch is better than a long speech."  But people (and I would argue engineers in particular) are visually oriented.  It's just a lot easier to follow the logic of what the program is doing visually than it is by looking at text.  Furthermore, it's a lot easier to debug something visually than by stepping line by line through the text.  And not to pour lemon juice on a paper cut, but why do you think things like flowcharts, state diagrams, and UML were invented?  Partly because the visuals are easier to follow. 

[Spectre_Dave]

Changing from one language to other Language is a BIG deal. Whether from C++ to LabVIEW or LabVIEW to C++

1)   All of the documentation will have to be updated / rewritten.

2)   All of the code will have to be rewritten.

3)   All of the new code will have to be thoroughly tested. After 10 years the old code will be relative bug free but the new code will be buggy.

4)   Retraining of the end users. Never underestimate the attitudes of the end user(s)

In the end - Does the cost of Time and Money justify the change?

[Yamaeda]

One of the things i really like about LV is that the schematic is instantly runnable and debuggable through highlighted runs. The Instant Runability (just made that word up i think, think i'll TM it) allows for alot less compiling time and alot less builds in general compared to C++ where you have to compile every time you make a small change to test it.

/Y

[Elijah_K]

Smercurio,

I'm curious to know what you don't think you can do in LabVIEW... I'm a big Subversion fan and advocate, and we aim to ensure that all software configuration management and source code control practices can be extended to LabVIEW. I recently blogged about this topic here - I'd be very interested to know if their is additional support you would like to see between LabVIEW and SVN.