LabVIEW Pros vs. Cons?

[X.]

The main issue I see with LabVIEW (which I almost exclusively use) is the fact that it is a proprietary development environment. Therefore, it cannot tap into the unending creativity of its most talented and passoniate users (to be found here or elsewhere, and it definitely does NOT include me). Or at least not yet very efficiently (scripting, Xcontrols, Xnode in the future, etc are baby steps around this). Saying this is not blaming NI (which most everyone agrees does a fantastic job at supporting users) or its engineers (which are certainly excellent). NI probably cannot or does not want to take the risk to lose control on a tool that makes using its hardware very easy. But I am wondering whether an alternative to it would be to offload the GUI/Analysis part of it to an OpenSource community (and in this manner give no excuse to the OP to leave it!).

[Synaesthete]

I'm not confusing how LV is designed vs. how it's marketed, I'm looking at the issue holistically.  I would like LV to be marketed as a language for non-programmers and for that to be true.

When I'm addressing inefficiency I am focusing on the environment, not the performance.  I understand that the run-time efficiency is on par with C.  I love that about LabVIEW.  The environment, on the other hand, is not as time-efficient from a programmer's perspective.  I doubt there's much data on this, and of course it would be a difficult study.  From my personal experience, text is much faster for many of the reasons I've already stated.  I believe there are exceptions to this, but if graphical programming is truly more efficient, where are all the graphical programmers?

I am not coming at this from my isolated experience, but from my observations of other programmers and experience teaching the course.  Non-programmers who take off with a basic understanding of LabVIEW end up writing unusable spaghetti code (I have never encountered good, salvageable code from a beginner, having seen code from dozens of beginners, some trained by me, most not).

Yes, I believe most of the other text-based languages and environments are too complex for non-programmers.  I wish there were a good graphical alternative that was actually effective for non-programmers.

The trouble is that LabVIEW is in fact used as a marketing vehicle for NI, and this priority is reflected in much of its development (Express VIs, etc.)  On the other hand, its development has also been driven by demands from professional graphical programming enthusiasts.  I believe there is an inherent conflict here that has not been resolved, and don't see any evidence that development is moving towards a resolution.  I would like to see NI freed of the obligation to support graphical programming enthusiasts in the LV platform, see LV become a lean-and-mean trimmed down tool for non-programmers (and as an effective marketing tool for NI), and see a new graphical programming paradigm that is not hindered by marketing demands and long history of LabVIEW, and is developed on its own by- and for- graphical programming enthusiasts.

[SteveChandler]

---

@Synaesthete wrote:

Ben-- I'll get back to you on that.

To hone my little attack on LV, a related critique comes to mind...

You are really starting to look like the guy who hates Mexican food complaining about the menu at Taco Time when there is a Burger King accross the street. Really? Don't be that guy! It's annoying and makes you look foolish.

A while ago you said " if you don't like it, vote with your feet and don't click on this topic!". Let me turn that around a bit for ya. If you don't like LabVIEW then why not go hang out on a C# forum?

[altenbach]

---

@Synaesthete wrote:

I would like LV to be marketed as a language for non-programmers and for that to be true.

---

That already exists in the form of Lego Wedo and Lego Mindstorms NXT. surprisingly, it is written almost entirely in LabVIEW. 😄

[Synaesthete]

Altenbach, I really enjoyed your post.

And I do believe LabVIEW should be fully 3D and gestural.  If it takes LabVIEW 25 years to get there, it will be way behind the curve--3D and gestural is here 'now', would love a more sophisticated way of interacting with complex systems and machines that take advantage of this.  Graphically, LabVIEW has hardly changed in 20 years outside of the front panel.

I'm not completely suggesting crippling LabVIEW to get coders to go elsewhere, but I do think a serious branching is at hand, with a professional LabVIEW platform becoming less proprietary.  If anything will cripple LabVIEW's future, it is its overly proprietary nature and its unresolved dual-development as a marketing vehicle and professional platform.

If you've spent most of your career working with LabVIEW, of course it will fit like a glove.  I think that a good look at other languages (beyond just a good look, actually learn and use them) would shed some light on where I'm coming from.

This is a more serious philosophical debate than tacos vs. hamburgers... certainly I'm playing a hard devil's advocate, perhaps going overboard with the anti-LV stance, to contrast an overzealous attitude from many within the LV and NI ranks.  Seldom do I see a rational, serious critique of this platform in spite of so many glaring problems.  My perspective comes from significant experience and while I'm not supporting my argument with pure data and references, I believe my rationale is sound.

[Ben]

---

@Synaesthete wrote:

Altenbach, I really enjoyed your post.

...  Graphically, LabVIEW has hardly changed in 20 years outside of the front panel.

...

---

I'll set DVR's and event srucures to the side for now.

Believe it or not those graphics are part of the patent. Before we would see a change NI would have to get patents on the new versions.

Another issues is readablity since changing the icon look would be the same as changing the syntax in a text language.

So keeping it consistant for 20 years is a good thing.

I am on the same page reagrading how LV is sold as being for rookies. It msileads customers into thinking (like a recent customer in my shop said) "I have completed the GUI layout and I would like you to finish the other 10%.".

The good part of the marketing is it has produced enough revenue for NI to keep going.

Ben

[Mark_Yedinak]

---

@Synaesthete wrote:

I'm not completely suggesting crippling LabVIEW to get coders to go elsewhere, but I do think a serious branching is at hand, with a professional LabVIEW platform becoming less proprietary.  If anything will cripple LabVIEW's future, it is its overly proprietary nature and its unresolved dual-development as a marketing vehicle and professional platform.

If you've spent most of your career working with LabVIEW, of course it will fit like a glove.  I think that a good look at other languages (beyond just a good look, actually learn and use them) would shed some light on where I'm coming from.

This is a more serious philosophical debate than tacos vs. hamburgers... certainly I'm playing a hard devil's advocate, perhaps going overboard with the anti-LV stance, to contrast an overzealous attitude from many within the LV and NI ranks.  Seldom do I see a rational, serious critique of this platform in spite of so many glaring problems.  My perspective comes from significant experience and while I'm not supporting my argument with pure data and references, I believe my rationale is sound.

---

I will agree with you that it would be nice to see LabVIEW more open and less proprietary. I do believe this would dramatically increase its adoption.

Regarding your other statement regarding knowing other languages I also have a valid perspective. My degree is in Computer Science and I spent the early part of my career writing C and assembly code. I also worked with C++ a fair amount when it came out. Since I was making my living doing this I think it is safe to say I know the languages and know them well. For me I prefer LabVIEW and graphical programming over any of the text based languages. I find that I can write code much faster in LabVIEW than in any text based language. All you have offered so far has been your opinion. You also want NI to conform to that opinion. Why should they? They are quite successful. For that matter, why should any of us bow to your opinion? If you are so dissatisfied with LabVIEW then don't use it. Those of us who do use it, and develop some extremely sophisticated applications, will continue to use it effectively and efficiently.

[Synaesthete]

---

@altenbach wrote:

---

@Synaesthete wrote:

I would like LV to be marketed as a language for non-programmers and for that to be true.

---

That already exists in the form of Lego Wedo and Lego Mindstorms NXT. surprisingly, it is written almost entirely in LabVIEW. 😄

---

These 'trimmed down' versions of LabVIEW are awesome.  I'm sure a lot of kids are really enjoying these.  Now if we just had a graphical language for professionals who are not professional coders...

[Mark_Yedinak]

---

@Synaesthete wrote:

---

@altenbach wrote:

---

@Synaesthete wrote:

I would like LV to be marketed as a language for non-programmers and for that to be true.

---

That already exists in the form of Lego Wedo and Lego Mindstorms NXT. surprisingly, it is written almost entirely in LabVIEW. 😄

---

These 'trimmed down' versions of LabVIEW are awesome.  I'm sure a lot of kids are really enjoying these.  Now if we just had a graphical language for professionals who are not professional coders...

---

And ANY "programming" language targeted for non-programmers would only be capable of the most basic tasks. It doesn't matter if it is graphical or text based. As for LabVIEW not providing the tools for a professional programmer I strongly disagree. I find it perfectly suited for all of my programming tasks. I use it almost exclusively as a general purpose language and am not writing code to control hardware. I have multiple large scale systems under my belt. Based on all of your comments so far I truly wonder if you have really seen or have been exposed to well written, large scale systems.

It is very easy to criticize bad programming, especially when it is written by non-programmers. A large amount of LabVIEW code falls under this category. However, you would probably be crashing systems left and right if you distributed the same percentage of C/C++ code written by non-programmers. I guarantee that code would be quite awful too.

[Otoro2]

I used to work in NI for 9 years and lead development for Statechart and NI Veristand, so with that credibility this is what i think.

If you want to work with NI hardware then use LabVIEW and its good for it (not really lot of choice other than it)

If your project require UI elements in it then LabVIEW "MIGHT" be good for if all the stock controls meets your requirement.

On architecture and code cleanliness, in my opinion it depends on your LabVIEW code scale.

If you are coding:

- 1 - 1000 VIs its manageble.

- 1000 - 5000 VIs its a bit harsh but manageble

- 5000 + Errr... why are u using LabVIEW? Have ever read post about building application pains ???

In my experience you can use coding style and framework to make the LabVIEW code makes more sense but as the code ages nothing make sense anymore. Better documentation tool please NI !!!

That said, I left LabVIEW world 2 years ago to work exclusively on C# and internet technology, I can only say one thing that Programming Framework and Patterns you apply in real OO language is more robust and uplifting compared to whatever I have code in LabVIEW.

In the end remember do not be a zealot... cause LabVIEW itself is written in C/C++ (At least for the components which run fast !!!)