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.

LabVIEW

LabVIEW Pros vs. Cons?

@BigApple0 wrote:

One thing I like about writing in text code is that I can use any text editor to view my code.

Yes, that works for simple code of a few lines. Good luck on inspecting advanced text code in notepad, because you'll lose all the special highlighting and all other tools of the programming environment. What good is viewing code unless you can actually modify and debug? 😄

The trained visual cortex is extremely good at recognizing shapes and their spatial relations (such as found on a LabVIEW diagram!), but there is a learning curve of course. Only using the OCR functionality to read text based code under-utilizes the brains capabilities! Even dyslexics can be good LabVIEW programmers, so it is more inclusive.

@BigApple0 wrote:

I don't have to screw around with figuring out and installing the correct version of LV.

You only need to install the newest version and you'll be able to open any code made in the last 20 years. (i.e. anything since LabVIEW 6)

@BigApple0 wrote:

Something that is a complete waste of time and really annoying.

I agree with the "annoying" part, but any significant software needs to be installed one way or another. It is not a waste of time unless the installation fails, and it usually does not. 😄

LabVIEW Champion.