I recently joined a conversation over on Stackoverflow.com that asked the question:
Why people don’t use LabView for purposes other than data acquisition and virtualization?After composing my answer, I wanted to post it here with the hope of generating discussion.
I've been thinking about this question for decades (yes, since 1989...)I would love to hear your thoughts...
Like all programming languages, LabVIEW is a high-level tool used to manipulate the flow of electrons. Unless you are a purist and refuse to use anything other than a breadboard and wires; transistors, integrated circuits and programming languages are probably a good thing if you wish to build something of any consequence.
But like all high-level tools, just wielding one does not make you a professional craftsman. Back in the day of soldering irons, op-amps and UARTs it required a large amount of careful study before you could create a system that actually functioned. The modern realm of text-based languages is so overly dominated by syntax that the programmer must get it just right before it will compile and run. In order to write code that works, the programmer must increase their skill level to create systems much larger than "Hello World".
LabVIEW is not dominated by syntax, but by Data Flow. Back in the day, reaching for your flow charting template and developing the diagram of a well-balanced information system was the art and beauty part of the job. Only after you had the reviewed flowchart in hand would you even consider slogging through the drudgery of punching out the code. (yes... punch cards)
LabVIEW is a development system that allows the programmer to use flow charting tools to diagram the complete information system and press "run"..... LabVIEW "punches out the code" and compiles it for you. No need to fight through the syntax of text language A or language B.
With such a powerful tool, novices can build large, working programs rapidly -- implying some level of professional craftsmanship since it runs at all. However, if the system does not perform elegantly, or the source code diagram is a mess, it is not the fault of LabVIEW.
People often point to "LabVIEW is only good for developing large data acquisition systems." Perhaps those people should consider the professionalism of the scientists and engineers that are working in data acquisition. If they know enough to get the actual wires right for the sensors and transducers, it may be a good bet that they are expert at developing LabVIEW wiring diagrams as well.
2 comments:
Dear Professor Weaver,
I am a consultant, specializing in LabVIEW development since 1992. I too have pondered this question for many years and have raised it at user meetings, private discussions and with NI.
- First of all I have to politely disagree with the assertion. People DO use LabVIEW for non data acq projects. For example, the hospital bed management system, "Bed Management Dashboard" (BMD) by Eclipsis (formerly Premise Development) was written in LabVIEW. This is a thick client, MSSQL based hospital management system with several hundred client stations in a typical installation. I worked on it off and on for several years, including re-architecting the main server and making it a proper Windows Service, in my last assignment. A typical installation costs several hundred thousand.
The question really is, "why don't they use LabVIEW more, or first?"
- The corollary question is why doesn't NI market and promote it for more mainstream applications?
- The main reasons NI marketing doesn't target more mainstream applications is competition and support. NI is the 800 lb gorilla in the data acq and control niche. They don't want to attract more attention from Microsoft et al, by going more into the text domain where there is a lot more entrenched competition. Support for an engineer or scientist operating hardware is within NI's expertise. Advising an investment banker coding up the next Wall Street Web based data mining app to predict market swings, is not. We discovered this when we were developing BMD.
- Another main discouragement to LabVIEW is simple fear and prejudice. Often times the more senior person(s) with final implementation influence are unfamiliar with *proper* development of large complex apps in LabVIEW. Choosing LabVIEW as a development platform would mean giving up a large part of their control of a project and entrusting that others who are experts in LabVIEW development. This happened a couple of times in the astronomy arena. Several years ago I worked on the SOAR telescope (in LabVIEW), including the camera instrument controllers. We developed a package called ArcVIEW (Array Controller in LabVIEW) based on the Leach SDSU-II hardware. Later, the NOAO instrument group was developing a new controller and software system to be called MONSOON. Naturally SOAR proposed ArcVIEW as the software. The review of this went well until a very senior astronomer/developer came into the picture. He immediately began shooting down LabVIEW, making no attempt to hide the fact that he was prejudice against it's use simply because he wasn't an expert, not about any real shortcomings of LabVIEW, other than that it is "expensive and proprietary" and therefore should be disallowed in favor of GNU C tools, TclTk, etc. This was hogwash, as the same man promoted use of SolidWorks ("expensive and proprietary") to design the optical hardware rather than open source CAD tools/methods. His opinion finally carried the day and MONSOON was developed with text.
- Lastly, LabVIEW often gets a bad rap because people try to do things with it that are way way above their skill level. They see that you can do things quickly in it that they wouldn't even consider attempting in a text/OOP lanaguage. They then charge ahead without doing upfront design. They don't apply proper software engineering discipline and practices on non trivial projects and when they end up creating spaghetti even faster than their text programming colleagues do and the project fails, then LabVIEW gets the blame. "Texties" then point to this as ammo to shoot down LabVIEW for consideration in other, more generalized, non data acq projects.
- However, with LEGO MindStorms, FIRST Robotics and other educational outreaches teaching this generation of students the benefits data-flow programming, I think it is just a matter of a few more years and you will see a large upswing of LabVIEW use outside of it's current niche.
Hi Michael,
Thanks for your thoughtful comments. I have similar stories from my days developing systems for the Air Force.
Things take time... and I guess 25+ years for LabVIEW to go mainstream is not too long to wait. It's just that so many other things in the hardware and software realm catch on so quickly that I'm still surprised that LabVIEW is not included in intro to programming courses more often (maybe it is... I haven't done a study).
I'm sure you share my frustration... as a person that spends so much effort optimizing systems, it is painful to see a new project start off in a niche text language rather than be completed in 20% of the time in LabVIEW.
Wire on! =]
Post a Comment