LabVIEW Pros vs. Cons?

[Ben]

---

@Otoro2 wrote:

I used to work in NI for 9 years and lead development for Statechart ...

- 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 !!!)

---

[Set Mode = Semi-Rant]

As a person who publicly morned the passing of the State Diagram Editor having been done-in by the State Chart, an unwieldy critter with a steep learning curve (if you started with computers before CS degrees were invented) and poor performance compared with the State Diagram Editor...

and

someone who has worked on very large apps in LV

and

has done battle with people from LV R&D along the lines of of Socrates discusion in Book X of Platos Republic re: the bridle and who "is an expert at a thing"

I should not be suprised to read a post like above.

I will repeat my stand once again here and now.

In the same way a leather worker is an expert in leather work but have to rely on the rider of the horse to learn what makes a good briddle,

NI is the maker of LabVIEW but we* the users of LabVIEW are the experts in its use.

There I said it!

Where do I get my cup of hemlock?

[Set mode = normal]

As to OO etc.

"If the only tool you have is a hamer everything looks like a nail." Samuel Clements (Mark Twain).

Ben

* Myself excluded

[Norbert_B]

I find it surprising, in both positive AND negative way, how everything comes down to discussions like this. Experts (widely recognized as well as self-appointed) argue about tools, processes, procedures, approaches, architectures, style guides, <insert any software development related topic>.

In this times, i commonly remember the abstract of "No Silver Bullet" by Frederick Brooks:

Of all the monsters that fill the nightmares of our folklore, none terrify more than werewolves, because they transform unexpectedly from the familiar into horrors. For these, one seeks bullets of silver that can magically lay them to rest.

The familiar software project, at least as seen by the nontechnical manager, has something of this character; it is usually innocent and straightforward, but is capable of becoming a monster of missed schedules, blown budgets, and flawed products. So we hear desperate cries for a silver bullet--something to make software costs drop as rapidly as computer hardware costs do.

But, as we look to the horizon of a decade hence, we see no silver bullet. There is no single development, in either technology or in management technique, that by itself promises even one order-of-magnitude improvement in productivity, in reliability, in simplicity.

(quoted from here)

I find this essay interesting due to the fact that it was published back in 1986. This was the year when LV version 1.0 for MAC was published. So i hardly believe that Fred Brooks was aware of LV at all at the time he wrote the essay. So the issues are not special to LV. But some people in this thread seems to think they are.....

Well, i find, that LV does address the last quoted sentence in a certain way, but still it is no silver bullet. For sure. So all in all, Fred is still absolutely correct.

There is not THE tool, not THE approach (design), not THE implementation. We as developer have to choose. Our choice is made up by personal preferences/experiences and we have to live with the choices, at least for a given time frame. After that, we might get a chance to re-evaluate and make another choice.

But still i find it akward to create a discussion thread like this one if one changed his mind to select another tool than LV.

Well, at least we got some valuable statements from enthusiasts pointing out their outstanding dedication, confidence and loyality to LV (as tool) and NI (as company).

So from this point of view, thanks for starting this discussion....

Norbert

[Synaesthete]

I started the discussion because I find such technical debates riveting.  I'm thrilled with the philosophical tone that we hit on several times, some very smart folks on these boards, nice to see beyond the techie.

However, it is dedication and loyalty to a tool that clouds rationality in its development.  It's the overzealous enthusiasm surrounding LabVIEW that I feel is at the heart of its misdirection.  The risk is that this noise pushes LV further in to esoterica, becoming less of a useful tool with applicability to the newcomer and the technical community at large.

I would like the development of LabVIEW to be more influenced by studies of programmer efficiency and of ease-of-adoptability by newcomers and non-programmers, and less influenced by the enthusiasm of its experts.

[smercurio_fc]

---

@Synaesthete wrote:

However, it is dedication and loyalty to a tool that clouds rationality in its development.  It's the overzealous enthusiasm surrounding LabVIEW that I feel is at the heart of its misdirection.  The risk is that this noise pushes LV further in to esoterica, becoming less of a useful tool with applicability to the newcomer and the technical community at large.

---

Again and again you say this without a single shred of proof. Several people on this forum, including myself, program in languages other than LabVIEW. And most of us, like me, started out programming in text-based languages. Guess what kind of project I'm working on right now. I'm developing code for a microcontroller. In C. Not C++, not Java, not anything that even dreamed of OO. C. Plain old C. I have to deal with trying to determine whether I should make the parameter type "const char *", or "auto rom const char *", or "auto ram char *", or whatever else. I can't even use the standard stdio library because the implementation for sprintf is too slow and too large. So I have to write my own!

We are constantly harping on LabVIEW on how to do things better. We offer ideas in the LabVIEW Idea Exchange on how to improve the language to bring in more sophisticated and useful components. We clamored for OO for a very long time and NI finally included it. Did we do it because we are "in love" with LabVIEW? No, we did it because we are programmers first, not LabVIEW lovers first. As a programmer I decide what language to use. In a reasonably-sized internal application I wrote I chose to use C# because I knew that LabVIEW simply wasn't the appropriate platform. Does that mean that I think we should all switch to text-based languages because they are "superior"? Superior to what? Macaroni and cheese?

You assume we're all LabVIEW fanboys. Frankly, I find that insulting.The "overzealous enthusiasm" isn't for LabVIEW. The overzelaous enthusiasm is in criticizing vague, unsubstantiated comments like yours where you assume your own personal experience is a basis for how the world should work. 

[NIquist]

---

@smercurio_fc wrote:

---

The overzelaous enthusiasm is in criticizing vague, unsubstantiated comments like yours where you assume your own personal experience is a basis for how the world should work. 

---

Oh Snap! 

I never see much point in adding my opinion into issues where opinions are ostensibly irrelevant.  Obviously the OP has a higher opinion of his opinion so may I be the first to say to him "Welcome to reality!  It's not you place to decide these things."  Programming languages will develop based on things we can't conceive of yet.  I don't know where things will go but my money is on a graphical and modular future and doubt that text-base formats will survive as hardware grows more powerful than our human ability to use it.

Your idea to break up LabVIEW into programmer and non-programmer versions is as silly as it is nightmarish.  You might as well tell VW that their cars are kind of toy-like and so should only be sold to non-drivers.  That way the roads would be full of useful trucks and high performance sports cars for us real drivers right? 

I like the devil's advocate stance too much to blame you for creating an entertaining topic like this but I have to laugh a little if you think it will be seriously considered.  Only time can tell the future of programming (or anything else for that matter). 

[majoris]

This thread is a joke. How defensive can people be?

"Oh no, not this thread again! How silly of the OP for posting something like this. He's clearly a troll with evil intentions. No one should pay any attention to this thread. Well, I better flame the OP for six pages anyways, just for good measure." (Challenge to the skeptic: try to find the personal attacks, they start almost immediately. How civil. Also, Pro tip: If you don't like flame wars, don't post in them. Think how short this thread would be!)

Some of the assertions in this thread are hilarious. Labview is an OOP language? Seriously. There are two common notions of OOP. That by way of Smalltalk and that popularized by C++ and transformed by other "modern" languages. Labview doesn't fit in either paradigm; It doesn't resemble Smalltalk with its processes and messages and it doesn't resemble C++, or newer OOP constructs, with their powerful inheritance schemes, constructors, first class objects, etc. The OOP methodology is cute but still feels like it's in beta, making it buggy and inflexible.

And Graphical Programming will surplant Text-based Programming? If there is such a language that can do it, it isn't Labview. Labview is closed platform and costs money, pushing out new and hobbiest programmers. As long as there is a price tag on your programming language, people will look else where. To know what people will be programming in tomorrow, you just have to look at schools today and to some extent try to figure out what companies will be demanding in the future. The answer to what people are learning and wanting is mobile and web applications, and the way to make them is increasingly languages like Java and Javascript.

There are other great assertions in this thread. "I was looking at some C code and couldn't figure it out. C code is hard to understand when poorly documented." Well, I can give you reams of impossible to understand wire-fu in Labview. Bad programmers exist in every language, and Labview makes no attempt at all to protect you from them obfuscating their code (only recently could you even name a wire). "I dunno what kind of code you're looking at, but my code is clean as a whistle." We then see examples of a top level state machine. That's fine, but click down into it. How deep does it go? How do you manage all those windows (in what text-based languages would simply be functions in the same document)? How do you fix dependencies going back? How much time do you spend making type definitions so one change one place doesn't break the entire code? Icons for those functions? On and on, there's so much vi maintenance.

Labview is probably the best protyping language I've ever worked with. Do I need to make a program in 30 minutes that collects data, does some simple analysis and creates a graph of the results? Can't do it faster (or neater) than in Labview. The next line of this reasoning, is always "but, for blah, you have to use blah." And then the counter argument is, "use the right tool for the job." But in reality, this is really silly. We're all pretty much noobs on most languages. Learning what a language is 'meant for' might take years of programming in that language. More over, adding languages to a project requires more time spent integrating your development and build tools, which is time not spent programming. Finally, when you leave the code base behind, someone with equivalent skills to you will need to come in and maintain it. Now how many programmers do you know that are proficient in Labview, C, Python and Lisp. Guess we'll just have to hire an army of programmers! So in the end, I think language choice matters, and the idea that using a bunch of languages to solve a problem is naive in most projects. Conversations like these aren't silly, and I don't think they should be dismissed. For a six page thread, I was pretty disappointed with the responses. Why bother posting if you don't have something interesting to say? Let the Flame War continue. I expect ample personal attacks on my intentions and quality of code!

[Synaesthete]

I actually do support the idea of using several languages simultaneously on a project, but not necessarily by using most languages in their current state.  I really like how you can use CSS, JavaScript, HTML, and PHP, and SQL together to write a web application.  Each of these languages is so suited to its task and it makes it really efficient to do the thing you're doing... with web programming, you can truly use the "right tool for the job" all within a single project.  I would like languages to evolve this way with 'offline' application development as well.

[majoris]

That's fine, but of course, there is no way to make a webpage in nothing but CSS. Essentially, if you want to make a web application, you're required to implement multiple "languages". Much like in one of the examples above, when you're programming on a microprocessor, you have no choice but the use the assembler or the compiler given to you. There's no memory for a heap, much less a virtual machine implementing garbage collection to run on the processor, so there's no chance any other language is going to be implemented on it. You're limited by the platform! A lot of this debate confuses tools with languages with platforms with support with community, which is one reason why there is so much miscommunication.

Labview's tools, community and support make it a great language to many things in. I have fundamental problems with the language itself (and sure, sometimes the tools get in the way also).

[JÞB]

What the heck,  Its Friday so why not fan the flame war.

Yes, many of the posters on this thread have volunteered to work as partners with NI for no direct compensation to improve LabVIEW, encourage its adoption as a platform and share our knowledge.  In fact you are engaged in a "technical" discussion with SIX current LabVIEW champions including three "Knights of NI"

//Begin Rant

Const Sarcasm=TRUE

Reply as String

For(SnyaetheteStatementBegin, SnyaetheteStatementEnd SnyaetheteStatement++)

if (SnyaetheteStatement !sane)

   Get Reply(Sarcasm,*SnyaetheteStatement,)

   Printf(Reply)

Else

   Void

End

"However, it is dedication and loyalty to a tool that clouds rationality"

Obviously, we are all deluded by our dedication and our statements should be viewed with the greatest skepticism.  In my case such dedication could only be because my judgment of this tools utility has been skewed by overexposure to NI screwdrivers and the leaching of mind altering substances into my coffee from the LabVIEW logo on my mug. 

"I find such technical debates riveting."

I too have been riveted my all the facts, examples, and sources you invite us to look into to support the conclusions you present.  It would be sad to see this thread become a nearly futile attempt to draw out what is supporting an opinion held by a poster offering little more than a long-winded tirade.

//end Rant

Synaesthete

You have the attention of some very smart folks.  I would recommend that you look into Proverbs 29:9, reflect for a moment and come back to this discussion with some real technical points that you would like to see brought forth. 

[X.]

---

@JÞB wrote:

In my case such dedication could only be because my judgment of this tools utility has been skewed by overexposure to NI screwdrivers and the leaching of mind altering substances into my coffee from the LabVIEW logo on my mug. 

---

I knew there was something more than met the eye in these screwdrivers... And I guess that's why NI sent me that mug upon recommendation by Ben! You don't say anything about NI's pen? Is it safe to use?