My direct comparison of LabVIEW vs. text-based coding is definitely a black-and-white assessment, which you have to do in order to assess their respective merits. The trouble is that LabVIEW is in fact pitched as a full-fledged alternative to other languages, and almost every coder I know is either in one boat or the other. In any given project you have several components:
The problem as I see it has as much to do with the language as it does with the culture. LabVIEW is designed and pitched as an all-encompassing solution, and most integrators use it this way. There's an effort to continue to build LabVIEW out to handle more of what other languages have accomplished, such as LVOOP. The LabVIEW language and community seems to want to head in the direction of it being a complete alternative, not as an isolated tool for doing a few things that gracefully integrates with better solutions that already exist.
Another problem related to culture. When you give an engineer a copy of LabVIEW that 'can' do most of what they need, they will go down the path of using it that way. In the process, they learn skills that are relatively non-transferrable to other programming languages, so that engineer will keep on using LabVIEW to solve most problems. The mental transition it takes to transfer over to use another tool is a major hurdle for a lot of engineers who don't have the time or support from their companies to learn those other tools. The only reason this persists is because the LabVIEW community is continuously supported by National Instruments, who help them continue down a monolithic path of using that one tool for every job. I believe this is a disservice to the engineers who use the tool and to the customers who hire them. A shift in the industry could result in a catastrophic reduction of need for LabVIEW programmers who could find themselves in a significant economic lull, like a little micro-economic-depression that has a dramatic impact on the LabVIEW community. There's a dependency between the LabVIEW coder and the single company who supports their tool, and it's a relationship that's far tighter than relationships with companies such as Apple or Microsoft.
The customer doesn't really care what language you use. For various reasons, many of which have to do with NI's support, LabVIEW continues to be sufficient to deliver satisfactory service, so LV coders continue to be employed. I don't see this as being a sustainable situation if things continue as they are. I believe LabVIEW needs a dramatic redesign to reduce it to a small, well-oiled power tool that sits comfortably on a bench with the others--not strictly for the sake of better software practices, but for the sake of the livelihoods of the engineers who use the tool.
It seems to me that you are, for whatever reason, enraged about LabVIEW and/or National Instruments.
My job includes consultings such as architecture consultings and reviews as well as code reviews. My approach to those actions is to tell the customer to develop their software as such that it can be implemented in any programming language.
If the developer CHOOSES to use LV, he has for sure stick to it, as such as he would have to stick to C# if he had chosen that.
So your point, that NI/LV would enforce customers into a "blind allea" is something i have to contradict in a strict manner.
A programming language has syntax and semantics. In this point, LV does differ much more from C than e.g. C#. Yes.
But the very basic algorithmic, so the mathematical description of "what shall happen", for the application still stays the same for every language. It only depends on its design (OOD vs. Flow Chart vs. State Diagram vs. ....) and how well you can transfer this design into code. And here, LV has clear advantage if the design was built up using Flow Charts or State Diagrams......
just my 5 Cents,
It's clear from these last comments that despite what you said in your first post you have no real understanding of LV or the other programming environments that you claim to work in. Moreover I don't really care how many classes you have taught - though I do have a large measure of pity for your students. If you really believe that you are more productive working in other environments you have the freedom to vote with your feet, log off from this forum and not come back. This forum is a place for getting answers to techincal questions - not off-topic bloviating.
Next, is NI a perfect vendor? No, of course not - go find one that is - but at least they listen to people. At least they provide a forum for people to ask their questions and get their answers - many companies these days don't. Personally, I hope LV does not devolve into a G++ or G# because it doesn't need to. LV is object oriented and has been since 1986. Of course you will object, but all your complaints are in the end rather pointless since all they really boil down to is that LV doesn't do OOP like C++ or Java does. Don't forget that OOP dates back to the 1960s (before you were born, right?) and C++ didn't appear until the late 1970s or early 1980s, and Java didn't appear until 1995!
Finally, as someone sporting a little longer view of the progression of things, I would assert that OOP is far more about the discipline of the developer than the language they use. While it is true that the features of a language can make the process easier, the best language in the world can't make you a good programmer if you don't have the discipline to engineer your code in the proper way. If it could, the world wouldn't be so full of poor examples of software developed in every language. You can't automate quality any more than you can legislate moral behavior. You either have them inside you or you don't, and while you can choose to learn both, no human power can force them on you.
I'm certainly not enraged. It's just a programming language. That's not to say I'm not being contradictory.
LabVIEW is such a curiosity to me. The language and its developers are on a little esoteric, relatively isolated island in the industry. No books on the shelves at B&N. Meanwhile, the software industry as a whole is undergoing drastic shifts and customer demands and expectations for what software can do are changing. Going forward, if LabVIEW is going to survive in the changing landscape, its survival will depend on rethinking its design not to make it do what other languages can do, but to do things other languages can't (and that means more than just making it play well with NI hardware), and find a footing such that it fits nicely in the landscape and doesn't require nearly as much monolithic adoption by developers.
Why is there such defensiveness? Where have I said anything that suggests a misunderstanding or appreciation for LabVIEW or other languages? I'm speaking directly from experience and my own observations, and such criticism is what moves things forward--my points aren't made out of malice or misinformation. Why shouldn't there be a place for such discussion? LabVIEW is a tool I've used for a long time and I have many colleagues who use it, and I have trained many people to use it to success. I'm trying to bring another point of view to the table because I care about these people and I care about writing good software. Recently I went to the other side of the fence, and all I'm saying here is that there seems to be a better way, that we could be doing things much better, and hoping to stimulate enough thought and consideration to possibly re-route things to accomodate that.
Maybe you are not enraged but you definately are passionate to an interesting degree. LabVIEW is what it is. There is always Measurement Studio with which you can write C# applications in Visual Studio that use NI hardware and software libraries. It's way cheaper too. There is also PyVISA which is free. There are lots of ways to solve problems. Use what works best for you.
Why is there such defensiveness?
I don't see the defensiveness. Maybe general irritation. As it has been pointed out above, this comes up regularly.
Can I be direct and ask what your point is? Do you want us to stop using LabVIEW and start using text based programming? As was also pointed out, many of us have lots of tools in our bags and LabVIEW is but one of them.
[...] I'm speaking directly from experience and my own observations, [...]
Yes, but those might differ a lot to other developer. And as Steve remarked in his last post: It is still not clear to us what you are really up to!!
I mean, you come here into the forum of a tool, the forum being supplied and moderated by the vendor of this very tool. The thread title seems to encourage discussion about "Is LabVIEW a good(better/best) tool in order to implement algorithm/application xyz?", but we find postings clearly stating discouraging exclamations regarding LabVIEW and its usablity, which are backup'ed by YOUR personal experience and view.
It would be just the same if i went to a Microsoft forum stating that i switched to xyz Linux recently and i predict the doom for Microsoft because xyz Linux is so much better (because *I* THINK it is). Please note that this is a theoretical point for this discussion....
As you can see, most posters in this thread concur with you that not everything can/should be done with LV.
But it is a viable tool and over the years, LV did indeed increase its acknowledgement in the markets ("LV adoption"); this is something your postings does not reflect and if i bear your "doomsaying" in mind, it seems that you are, at least in this point, plainly wrong.
Time has to show what technologies emerge and which will disappear. But i would say that LV has a *very* good setup for the next coming years and i don't share your quite negative view regarding developers getting familiar in LV.
Provided the forums stay active in helping and NI does not load on too much "Expert help" (NO Spoolies) I see LV replacing C and other languages in the future.
I say that becuase the younguns coming into the work-force are growing up in a graphic world and I suspect they will choose to "Draw picture" rather than "check spelling" when they are given a chance.
It may not happen until after I am gone but my money is on LV.