LabVIEW Pros vs. Cons?

[Synaesthete]

I don't know if this is the right board for this, but I'm interested in bringing up a topic that constantly weighs on my mind.  It relates to the state of modern LabVIEW and its validity as a programming platform in the coming years.

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.

[smercurio_fc]

Six months have passed. How do I know this? Because this question is being asked again.

I know you're looking for information, and I'm not trying to be mean or grumpy, but to be honest, I'm really tired of debating/discussing this point. You can do a search and find plenty of threads that talk about this.

One for every six months.

EDIT: I will, however, make one comment:

---

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.

---

 Then may I respectfully say that your experience is severely limited.

[Synaesthete]

I expect a level of defensiveness from such a post, and for every 6 months that passes this becomes more valid.  I'm a member of this industry too, and with many colleagues whose livelihoods depend on market opportunities.  I think it's an important consideration, to assess the efficacy of our tools in the face of an ever-changing landscape.

[Synaesthete]

But my experience is not severely limited, but backed by a thorough understanding of both platforms and a deep assessment of both.

[Akiel]

Theres place in the world for both approaches and they can work well together, I wont be drawn in the arguement but I will say  all replies are being defensive in themselves and I cant see a sensible debate starting.

[Norbert_B]

You know, in many points i do concur with you.

But one very important point bugs me:

You are writing the post as if a developer has to make a choice for one programming language for his lifetime.

In my experience, the developer should (*must*) decide case-by-case if he wants to use language A or B. So there were, are and always will be situations where LV will result in "faster developed"/"better"/"easier to manage" applications as well as where text-based programming languages will deliver certain advantages.

So, please let the developer decide on their own case-by-case instead of stating something as "lump sum".

thanks,

Norbert

[Ben]

When preparing to confront Goliath, Saul offered David his armour which David shunned choosing to use only is sling and his faith.

When confronted with a challenge we will reach fo rthe tools we are most comforatable using.

You apperently are more comforatable with text and your questions reveals as much. I am not judging good or bad only observing.

Q:

When you dream code, do you dream in text or G?

The answer is yours and you should not feel obligated to answer. I do dream in G and can red G at a glance. Even if I was not dyslexic that fact alone would lead me to G.

Final thought that summarizes my opinion only.

My company used to teach the CVI as well as LV. We had a certified CVI instructor. WHen we ran across job oppertunities where the customer was not sure C vs G they would request a quote for the sme app developed in C and G. The CVI instructor handled all of these estimates and said it was easy. Estimate the time to do it in G then multiply by 2 for teh C estimate.

Ben

[smercurio_fc]

You think I'm being defensive. I am not. I am neither defending or agreeing with you. Neither am I defending or pounding on LabVIEWl. I am also a text-based programmer, so I see both sides as well, so I believe I have the experience to comment here. You may find this difficult to believe, but I share some of your impressions regarding OO. But then as a programmer I choose which language is the better one to use for a specific task.

I never said it wasn't an important consideration. I simply fail to see the point you think you are making. Is it that LabVIEW isn't as good as text-based code when it comes to OO? Is it that NI hardware seems to be tied to LabVIEW? Is it that you think mediocre programmers choose LabVIEW because they think it's easier, and they will be able to get programming jobs more easily? Is it that you think engineers don't have the required programming skills and choose LabVIEW because they believe it's a language that doesn't require programming knowledge (and if so is that a fault of the engineer or the language)? Is that you think there's a "brain-drain" toward the internet? And what does that have to do with LabVIEW being a viable programming language???

What about all the shops that are "locked into" .NET? Does this mean that the company will fold once .NET goes away, to be replaced by the next flashy framework? Like Ruby on Rals?

Make a sensible argument/statement and then maybe you can get a sensible discussion going.

[Akiel]

yep, definatly. also there are situations where a variety of languages can work well with each other. There is no this is better than that, all depends on application and the developer

[Britoa]

---

@smercurio_fc wrote:

You think I'm being defensive. I am not. I am neither defending or agreeing with you. Neither am I defending or pounding on LabVIEWl. I am also a text-based programmer, so I see both sides as well, so I believe I have the experience to comment here. You may find this difficult to believe, but I share some of your impressions regarding OO. But then as a programmer I choose which language is the better one to use for a specific task.

I never said it wasn't an important consideration. I simply fail to see the point you think you are making. Is it that LabVIEW isn't as good as text-based code when it comes to OO? Is it that NI hardware seems to be tied to LabVIEW? Is it that you think mediocre programmers choose LabVIEW because they think it's easier, and they will be able to get programming jobs more easily? Is it that you think engineers don't have the required programming skills and choose LabVIEW because they believe it's a language that doesn't require programming knowledge (and if so is that a fault of the engineer or the language)? Is that you think there's a "brain-drain" toward the internet? And what does that have to do with LabVIEW being a viable programming language???

What about all the shops that are "locked into" .NET? Does this mean that the company will fold once .NET goes away, to be replaced by the next flashy framework? Like Ruby on Rals?

---

I'm chiming in, mostly because these kinds of discussion (when they are discussion) are interesting to read through.  Your comment on picking the language based on the task is spot on.  For a tight dsp loop (a few kcycles), I wouldn't pick LabVIEW as much as I wouldn't pick .NET or even C++, it would be in C, or if needed, parts in assembly.  Just as I wouldn't make a GUI with C or assembly.  The problems happen when many programmers lock themselves into a language (on their own accord), and use a screwdriver to drive in nails.

I do think that programmers (and managers) tend to look at labview and say it's easy, so they choose to go with that, but that's both NI's and the developer's fault.  NI has been marketing it as such, and the engineers havent been doing their research before picking their tools. 

Also, Microsoft has already anounced their .NET replacement with Windows 8, so I can imagine that some .NET shops are scrambling to retrain.