LabVIEW Pros vs. Cons?

[Dennis_Knutson]

Now you're just making things up. With very few exceptions, NI hardware has always been supported by other programming languages.

[Intaris]

---

@Synaesthete wrote:

I think there's an inherent hindrance that makes LabVIEW more sluggish, less adaptable, and less evolvable. It's one part the restrictions of a graphical environment, but also in the NI strategy.

---

Well bearing in mind the number of customers NI has in defence, aeronautics and other regulated industries, a "sluggish, less adaptable, and less evolvable" system is not really a drawback but rather a claim that the system is consistent.

But one point I WOULD make is the utter lack of a LTS Version of LabVIEW (We still run into bugs in LV 2012 SP1 and no, we're not upgrading to have a spin on the great bug carousel!), something which is sorely missing in my opinion.

[richjoh]

---

@natasftw wrote:

---

@richjoh wrote:

Well that my point, they're are none, your quoting a quote I quoted. I'm really not concerned with his certs, its not an issue. Getting certs doesn't make you expert or guru. He's titled this pros and cons but appears to be whining about how bad graphical is compared to text. If you meet a text programmer that doesn't like LV, it probably because its concepts don't fit standard textbook (no pun) programming paradigms. This is clear from initial post.

---

Why would you feel the need to make the point there?  He never brought up those "certifications."  He brought up having knowledge of the topics and you asked for the certifications, not in a quote of a quote. 

Your entire post was asking for his certs.  It's a bit strange to not be concerned, not see that as an issue, and only post to ask for them don't you think?

Being an expert doesn't really add to the conversation.  Trying to bring someone's qualifications down doesn't negate their opinion, whether it relies on emotion or rational thought.  There's no benefit to trying to show they're not as versed as they think they are.  Even if you're right, it doesn't change the opinion and doesn't offer any actual insight.

There are certainly applications I'd prefer use a text-based approach.  If he's working with those styles of applications, it wouldn't shock me that he'd prefer use text-based languages over LabVIEW.  There's also applications where I'd dread using text-based code.  There's a good chance the people excited about LabVIEW work in those domains. 

---

---

@hmmm he wrote:

---

It's important to know a few tidbits about my background.  I have attained a CLA and CPI, and have taught the LabVIEW Basics course several times.  I've written dozens of applications in LabVIEW, and use the latest coding practices and follow strict style guidelines.  I've produced a hundred event-driven state machines, and in my architecture I utilize LVOOP and have a thorough understanding of the actor framework.

Recently I've had opportunities to write more code in text-based languages, something I did often prior to becoming a LabVIEW professional.  I found an unexpected breath of fresh air when returning to object-oriented text-based programming.  I've found that text-based languages run circles around LabVIEW in terms of scalability, reusability, ease-of-documentation, and overall the mental experience is far better.  It's not unlike the difference between a picture book and a textual book--while picture books are easy to read by anyone, they can never be as fully expressive as a text-based book.  For those who've taken the time to master the language, there's a zen-like fluidity to reading and writing text.  Furthermore, most of the time you can write text-based code in a good IDE without switching "modes"... no jumping in to an icon editor, opening up several new windows, switching back-and-forth between project views and block diagrams, etc.

I understand that different people have different preferences for writing code.  What I'm beginning to question is whether a very experienced LabVIEW programmer can do the equivalent of a very experienced text-based programmer.  From my recent experience, that is not the case.  I approve of LabVIEW's use as a tool for helping non-programmers get up-and-running with hardware faster.  What I'm bringing in to question is the validity of LabVIEW as the primary tool for a seasoned professional coder.  What I'm guessing is that we're in a state in the industry where a lot of engineers have gone down the route of using LabVIEW, perhaps due to a lack of training in a text-based language or because they had the opportunity to take on a few LabVIEW projects, which then defined their career.

My experience of transitioning from LabVIEW to a text-based language certainly presented some initial frustrations; learning a new environment and language is hard.  After about a month of sticking to it, my text-based abilities matched my LabVIEW abilities, and if it weren't for my present obligations to the LabVIEW industry, I would much prefer to stick to text.  I'm wondering if this would be the case for other engineers and integrator firms who are essentially "locked in" to LabVIEW.

The reason I bring this up is because I fear that development houses who focus primarily on LabVIEW can compete in the industry only because of LabVIEWs ability to integrate with NI hardware and the availability of packages for signal analysis, etc, and not due to an inherent advantage derived from the LabVIEW language.  In other words, if an integration house of experienced text-based programmers were using NI hardware and had access to similar packages, they could deliver a better, cheaper, and more timely service than the equivalent LabVIEW house.  If things were to change in the industry, something that allowed text-based coders to access the market currently occupied by LabVIEW coders, it could be devastating to a lot of engineers and their companies.  Right now there's a kind of brain-drain of text-based coders who have focused on web technologies and the "app market".  If and when those bubbles burst, there will be an influx of text-based coders who might start to feast their eyes on other markets.  The emerging "Internet of Things" foreshadows such an occurrence.  This should not be ignored by our industry.

---

No comment necessary, highlights are shown above in bold on certs & other points bold. No, I should comment. Clearly this professional has a hard time working in a Labview graphical environment. He hopes a take over of graphical zombies by intelligent text coders. Everybody knows you use the right tools for the job, it appears he's stuck using graphical and wants to get out.

[richjoh]

It's important to know a few tidbits about my background.  I have attained a CLA and CPI, and have taught the LabVIEW Basics course several times.  I've written dozens of applications in LabVIEW, and use the latest coding practices and follow strict style guidelines.  I've produced a hundred event-driven state machines, and in my architecture I utilize LVOOP and have a thorough understanding of the actor framework.

Recently I've had opportunities to write more code in text-based languages, something I did often prior to becoming a LabVIEW professional.  I found an unexpected breath of fresh air when returning to object-oriented text-based programming.  I've found that text-based languages run circles around LabVIEW in terms of scalability, reusability, ease-of-documentation, and overall the mental experience is far better.  It's not unlike the difference between a picture book and a textual book--while picture books are easy to read by anyone, they can never be as fully expressive as a text-based book.  For those who've taken the time to master the language, there's a zen-like fluidity to reading and writing text.  Furthermore, most of the time you can write text-based code in a good IDE without switching "modes"... no jumping in to an icon editor, opening up several new windows, switching back-and-forth between project views and block diagrams, etc.

I understand that different people have different preferences for writing code.  What I'm beginning to question is whether a very experienced LabVIEW programmer can do the equivalent of a very experienced text-based programmer.  From my recent experience, that is not the case.  I approve of LabVIEW's use as a tool for helping non-programmers get up-and-running with hardware faster.  What I'm bringing in to question is the validity of LabVIEW as the primary tool for a seasoned professional coder.  What I'm guessing is that we're in a state in the industry where a lot of engineers have gone down the route of using LabVIEW, perhaps due to a lack of training in a text-based language or because they had the opportunity to take on a few LabVIEW projects, which then defined their career.

My experience of transitioning from LabVIEW to a text-based language certainly presented some initial frustrations; learning a new environment and language is hard.  After about a month of sticking to it, my text-based abilities matched my LabVIEW abilities, and if it weren't for my present obligations to the LabVIEW industry, I would much prefer to stick to text.  I'm wondering if this would be the case for other engineers and integrator firms who are essentially "locked in" to LabVIEW.

The reason I bring this up is because I fear that development houses who focus primarily on LabVIEW can compete in the industry only because of LabVIEWs ability to integrate with NI hardware and the availability of packages for signal analysis, etc, and not due to an inherent advantage derived from the LabVIEW language.  In other words, if an integration house of experienced text-based programmers were using NI hardware and had access to similar packages, they could deliver a better, cheaper, and more timely service than the equivalent LabVIEW house.  If things were to change in the industry, something that allowed text-based coders to access the market currently occupied by LabVIEW coders, it could be devastating to a lot of engineers and their companies.  Right now there's a kind of brain-drain of text-based coders who have focused on web technologies and the "app market".  If and when those bubbles burst, there will be an influx of text-based coders who might start to feast their eyes on other markets.  The emerging "Internet of Things" foreshadows such an occurrence.  This should not be ignored by our industry.

[natasftw]

DAQmx product page: http://sine.ni.com/nips/cds/view/p/lang/en/nid/10181 
Automatic LabVIEW, C, C++, C#, and VB .NET example program creation with the DAQ Assistant

X-NET support page: http://sine.ni.com/psp/app/doc/p/id/psp-903/lang/en

Driver and APIs for writing custom frame and signal applications in LabVIEW, LabWindows™/CVI, C/C++

If the solution to your proposed problem is to allow text-based programs to integrate with the hardware, do you actually have a problem?  That's a lot like saying everyone would be happy if we could only breathe.  Either that's not the solution to the problem or the problem doesn't exist.

[James_W]

TO be honest I just love the title of the thread, I know it's going to be some text based LabVIEW basher so I'm not going to read it. I'g just going to revel in the thought of "LabVIEW Pros" taking on "Cons" at some task. Not quite sure what the Knights of NI are challenging the criminals/ex-criminals at but the thought of the challenge is very appealing!

[Hooovahh]

Okay fine I'll go back on topic for a bit and try to focus on the Cons of LabVIEW.  I too often minimize LabVIEW's cons due to it being my career choice but this will be good for me.

• Window resizing and multi-resolution support
• Panes are a pain, things can be made to work but it sucks
• Versioning and opening newer / older code
• This is normal for things like Word where 2003 can't open 2007 files but people don't expect this from a programming language
• Backsaving entire projects is a pain too
• The many windows problem
• So each VI has two floating windows, and each project can have thousands of VIs, and probes and probe manager, and breakpoint manager, and project window...too many windows and it can be difficult to keep track of them.  Especially in an OS that tends to collapse them into a single button.
• Multiple versions opening files
• How often do you double click a VI file and have it say "This VI can't be opened with this version of LabVIEW".  Really? Then why did you try?  Why didn't you use the version that could open it?  Sometimes I see this when that other version is already open.  I've since tried fixing these types of issues with my LabVIEW Tray Launcher but it is a pain.
• Seemingly poor implementation of OO
• Other languages seem to implement object oriented designs in a more elegant way.  It is hard to describe it but LabVIEW implementation seems immature, and I only mean that maybe these other languages have more miles on the tires and have flushed things out.
• LabVIEW not seen as a real programming language
• This opinion is seen in several industries, where computer engineers think graphical programming is for kids, or can't compete with text in terms of performance.  This is of course asking the wrong question.

In my opinion there are many more pros than cons pros.  But this forum, and especially this thread probably focus most of the attention on the pros, so I don't feel like listing them.

[tst]

---

@James_W wrote:

I know it's going to be some text based LabVIEW basher so I'm not going to read it...

---

I disagree. I think that the title is perfectly reasonable (as opposed to the various "I hate LV" stuff you can find occasionally) and I think that both Synaesthete and Wayne have been at least respectable and apparently reasonably thorough and I wouldn't expect anyone to do more than that. That doesn't mean that every conclusion they came is necessarily true, but they're not just bashing and it's perfectly OK for people to prefer text based programming. Personally, I think they've been treated a bit too harshly by some of the posters here.

[pawel.ostrogorski]

I am 8 month after studies, working mostly in LabVIEW, waiting on my CLA results so I think I could share my 2 cents.

LabVIEW is superior if it comes to acquiring data and processing it. Recently I had project where that stuff needed to be done on PLC and there was a lot of problems and pain to make that work. From other side writting simple sequences and controlling some actuators is easier and ceaner to do and modify in PLC ladder than in LV.

Recently I have started doing some stuff in c# and pros of LV are:

- very simple architecture creation, making 5 threads running asynchronously is very easy to do.

- simple memory managment

- IO communication

- loops with autoindexing, conditional input...

- UserEvents and what can we do with them.

- playing with variants and data types

I think I agree what richjoh says in his arguments, Stuff like:

- writing equations and connecting all this primitives is really annoying. There is something like MathNode that makes it better, hope this tool will be part of LV soon.

- property node and method selection, moving mouse through all this windows is really annoying - should be included in QD

- UI creation when compared to WindowsForms it is poor. Trees Listboxes... need big improvement. There is a lot of pain when comes to getting tree elements, converting all to string in order to put it inside listbox... I think that needs to be solved to alow better UI creation.

-Can't open files from new version of LV. 

-UI resising, I always have too many problems doing that.

-VIs that are password protected - what for. The same with Xnodes - great tool that should be public.

So far my programs didn't go larger than 600 VIs, I don't use LVOOP and I don;t intend to because that doesn't fit me well in LV. I think I will stick to LV now, because that's only thing I know in advanced level, I think I will start to put more and more things from C# and eventually move to C# if that need comes.

[Otoro2]

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?

[BowenM]

---

@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?

---

If you took one look at some of the LabVIEW code I have inherited - done by "experts" who have been programming since LabVIEW 4 you would not be asking that question.