LabVIEW Pros vs. Cons?

[natasftw]

---

@Otoro2 wrote:

I just curious around the CLA, do you realize most people who are employed under National Instruments LabVIEW team does not event have CLA certification. If so is it really important to have CLA certification?

---

You're using a strange qualification.

What does programming in LabVIEW have to do with developing hardware to talk to CAN networks?  What does it have to do with writing VHDL to be wrapped up in FPGA coding?  What does it hae to do with designing DAQ devices?  What does it have to do with RT applications?

There's a lot more to what they're doing than programming in LabVIEW.  The CLA tests your ability to put together a decent sized application.  It's not exactly relevant to most of the jobs that exist at NI.  You're also making an assumption that you probably shouldn't.  You're assuming that everyone that can pass the CLA has taken the CLA and that anyone that doesn't have the CLA cannot pass the test.  It's possible to have the ability without having taken the test.  Your question is a lot like asking if getting the CCIE is beneficial to your career even though most people at Cisco don't have it.

[Otoro2]

I agreed completely. Having CLA does not mean you can code LabVIEW !

[Jacobson-ni]

I figured I would chime in because there were a couple of posts about NI eployees and certification.

I will say that Natasftw pretty much hit the nail on the head.  NI is a pretty big company so there are obviously a lot of people who do not need to know how to build very large applications in LabVIEW (think marketing/sales).  

Even working in support, 90% of the time I am dealing with a single VI or less (Hardware/MAX configuration for example).  Usually I like to keep that 1 VI to an example if I can, so if I ever have to work with a customer on more than like 5 VIs something has probably gone terribly wrong.  If you are working out bugs in LabVIEW you tend to go in the opposite direction of CLA knowledge, where instead of needing to know how to build very large applications you need a very good understanding of how LabVIEW is handling things behind the scenes at a low level.

I think it mostly comes down to their second point though.  If you are already working at NI there isn't really a reason to get your CLA past proving to yourself that you could do it and getting that sweet, sweet polo and NIWeek sticker.  I find certifications give people who don't know a lot about the subject an idea of how much you know.  I get the chance to talk with a lot of users and I think it is usually pretty easy to gauge someone's ability with LabVIEW (especially if I can watch someone while they are programming).

[pawel.ostrogorski]

I am not saying that CLA or other certification makes You the best of the best. LAVA users are amazing and not all of them have this certifications. I am just saying that if we follow path of learinig LV in way that national wants we should have good programming habbits in LV so we can say more about pros and cons because we spent some time with it, not mentioning stuff like spagetti coes or when someone moved from text based languages and starts to complain about stuff that doesn't fully know how works. But this certification discussion is total offtop and has nothing to do with real pros and cons of LV.

[WayneS1324]

We're comparing apples to oranges. If you need Vitamin C, you aren't going to eat an apple. You're going to eat an orange.

If it's soluble fiber that you need, you're not going to eat an orange. It'll be an apple this time.

I personally prefer text based languages because I enjoy writing code and a well written chunk of C++ code is a beautiful thing.

I understand (as well as those who hate it) that LV has it's strengths. Concurrency for one.

[natasftw]

Wayne, that last post shows the problem.

You're looking at an orange and calling it an apple.  That doesn't make it an apple.  Personal preference won't change that.

They're both programming languages.  Well written code in both is a beautiful thing.  Poorly written code is a headache in both.

[WayneS1324]

---

@natasftw wrote:

Wayne, that last post shows the problem.

You're looking at an orange and calling it an apple.  That doesn't make it an apple.  Personal preference won't change that.

They're both programming languages.  Well written code in both is a beautiful thing.  Poorly written code is a headache in both.

---

I think you need to read it again. Apparently you misunderstood. My point was that they both have their places.

[Ben]

---

WayneS1324 wrote:

.... My point was that they both have their places

---

I agree.

The following is intended for those new LV developers that may be wondering if it is worth investing time in LV. It is not intended to change minds but rather give them something to consider.

Recently I had the oppertunity to be the LV guy in a project that was intended to answer the question "Should we switch to an sbRIO driven by LV or do we stick with the traditional route and code in C#?"

The chalange was to implement a standard piece of lab equipment. Two parrallel development paths were taken side by side at the same time (well not completely at the same time) and compare the results of both teams. If you want to learn the details you will have to wait for the NI Week paper I submit this year but the results were summarized in a atta-boy letter as follows;

--------------------------------sbRIO_and_LV--------------------------Traditonal C#

Development Time________4 months____________________18 months

Development Cost________$270K_______________________$1.5M

When I packed-up and moved on to my next project the other team was still trying to get their version to talk to the standard analysis package (that was also writen in C#). So when it comes to the point where software interacts with hardware, LV is a viable option.

it was a fun project.

I hope all of you get a chance to have as much fun as I had.

Ben

 

 

 

[natasftw]

---

@WayneS1324 wrote:

I think you need to read it again. Apparently you misunderstood. My point was that they both have their places.

---

The analogy is rather broken.  You're grouping text-based together.  You shouldn't. 

As an example, try writing FPGA code in C versus VHDL.  Both are text-based languages.  Both have a place.  Depending on the programmer, one is certainly worse than LabVIEW.  The other is mostly a programmer preference.  In this case, VHDL and LabVIEW are more closely grouped than VHDL and C.  Drawing a line between graphical and text-based isn't a good place to draw that line.  I don't think anyone that has spent any real time with LabVIEW is advocating that it is the best tool for any given situation.  It's not.  It's just incredibly disingenuous to say you're comparing apples to oranges.  You're not showing that is something distinctively different between LabVIEW and text-based.  You're stating something that's inherent to a comparison between any two programming languages. 

[WayneS1324]

---

@natasftw wrote:

---

@WayneS1324 wrote:

I think you need to read it again. Apparently you misunderstood. My point was that they both have their places.

---

The analogy is rather broken.  You're grouping text-based together.  You shouldn't. 

As an example, try writing FPGA code in C versus VHDL.  Both are text-based languages.  Both have a place.  Depending on the programmer, one is certainly worse than LabVIEW.  The other is mostly a programmer preference.  In this case, VHDL and LabVIEW are more closely grouped than VHDL and C.  Drawing a line between graphical and text-based isn't a good place to draw that line.  I don't think anyone that has spent any real time with LabVIEW is advocating that it is the best tool for any given situation.  It's not.  It's just incredibly disingenuous to say you're comparing apples to oranges.  You're not showing that is something distinctively different between LabVIEW and text-based.  You're stating something that's inherent to a comparison between any two programming languages. 

---

Let me elaborate.

My post was supposed to reference the "workhorse", general purpose languages. C/C++/C#, Ada, Modula 2, Pascal, etc...
It was not meant to include more obscure or speciality languages. VHDL, BASIC, Forth, etc...

Even though VHDL can be used as a general purpose language, thats not what it was created for.

I would've thought that this would be implied in my post.