This completely differs from my own experience with LabView, which I used a number of times in both undergrad/some grad-level coursework (I have a mechanical engineering background), as well as in internships at a couple of different companies. LabView sits, almost uniquely, in the "absolutely not, with no exceptions, ever again for the rest of my life" tools that I've worked with in my career. I don't think I even list on my resume anymore, because I don't want anyone to know that I've ever touched it and assume I'd be willing to again.
I know it's a classic "don't blame your tools!" situation, but the ability for even moderately-experienced programmers to accidentally build high-incidental-complexity tooling that becomes a nightmare to re-learn once you've lost your mental model of the program is, in my experience, unique (and frightening).
I once spent weeks trying to get a LabView-based tool up and running that a senior engineer in another section had written. Sketching out the relationships between components, documenting I/O, etc. After finally giving up the ghost, I went to that engineer for help. After spending hours (like, 5-6 hours, not 1-2) sitting next to him in my lab, he said "yeah, I'm not really sure what I was doing with this...", and proceeded to need to take the entire program back to his desk for nearly a week before he could finally explain how it worked.
This situation wasn't a one-off; it's happened with nearly every non-trivial codebase that I've ever touched that used it. In my experience, LabView is really fantastic in only two situations:
a) Very simple GUI-based DAQ tools that the person who wrote the program, and them alone, will need to use
b) Complex tools that are owned by a team of engineers who have written LabView for years and will now be dedicated exclusively to those tools
You missed a lot of its value, which the parent commenter highlighted.
Agreed, it's terrible if you have to maintain something from before, especially as over the years they get bad as one engineer after another adds or fixes one thing or another. It's terrible for that, and those codebases and tools should have been migrated to python etc. long ago.
It is great for getting a piece of hardware working and being tested today. In the next 2 hours. Sometimes you just don't have thr time or money in the budget to write custom code for everything. Sometimes you just need to make it work and move on. Labview is great for that.
I know it's a classic "don't blame your tools!" situation, but the ability for even moderately-experienced programmers to accidentally build high-incidental-complexity tooling that becomes a nightmare to re-learn once you've lost your mental model of the program is, in my experience, unique (and frightening).
I once spent weeks trying to get a LabView-based tool up and running that a senior engineer in another section had written. Sketching out the relationships between components, documenting I/O, etc. After finally giving up the ghost, I went to that engineer for help. After spending hours (like, 5-6 hours, not 1-2) sitting next to him in my lab, he said "yeah, I'm not really sure what I was doing with this...", and proceeded to need to take the entire program back to his desk for nearly a week before he could finally explain how it worked.
This situation wasn't a one-off; it's happened with nearly every non-trivial codebase that I've ever touched that used it. In my experience, LabView is really fantastic in only two situations:
a) Very simple GUI-based DAQ tools that the person who wrote the program, and them alone, will need to use
b) Complex tools that are owned by a team of engineers who have written LabView for years and will now be dedicated exclusively to those tools