Trying to understand just how convoluted labVIEW's GUI can get. Let's say someone came out with an efficient, procedural, text-based alternative that can integrate with NI hardware - would it be a no-brainer switch?
When I used to use LabVieW (shudder) I usually just made a VI to call python or C/C++.
A large LabView project can become tricky to maintain. Two of the largest LabView code bases are the flight software for NASA's Cold Atom Laboratory and SpaceX's real-time launch visualization GUI and both may have required substantial support from National Instruments.
A few issues come to mind (I'm sure there are others.)
1. LabView doesn't (or didn't) really mesh well with things like git or mercurial so care must be taken making sure the C, C++, Rust, Python remain coupled with corresponding versions of LabView VIs.
2. Sometimes there is a cultural gulf between the LabView developers and the C, C++, Rust, Python people. E.g. SpaceX may have some fun integrating California Software (C++, Rust, Python) with Texas Software (LabView)
3. If you only have a limited number of LabView license seats, make sure your CI automata doesn't eat all of your licenses.
Labview is a quick and dirty let’s do this and forget what happened. I considered looking up how to do something correctly then my second thought was to do whatever and turn it into a sub to hide the work.
A large LabView project can become tricky to maintain. Two of the largest LabView code bases are the flight software for NASA's Cold Atom Laboratory and SpaceX's real-time launch visualization GUI and both may have required substantial support from National Instruments.