I haven’t used LabView much myself but did work at a company whose product replaced it with .Net tooling. I got a sense that some common programming idioms become spaghetti. I want to say maybe that there wasn’t a proper loop in LabView?

Take this with two grains of salt. I’m not actually a LabView user and what I know comes from a company replacing it.

LabVIEW is a trap. If you are considering using LabVIEW for making product software, consider systems with better developer ergonomics, such as having your engineers write Python while being water boarded.

The problem is that LabVIEW, the language and IDE, comes with LabVIEW, the integration library for your NI sensors and test equipment and other doohickies. So slapping a program together to gather some data and display it is trivial. But over time, you're going to start to add business logic. And at first it might be bearable: You're code will end up spaghetti periodically, but you'll refactor a little bit and it'll be fine. But your codebase will expand and expand, well beyond the relatively trivial amount of machine interface code and eventually you'll just be developing software, but in LabVIEW.

And that's where LabVIEW's fundamental, inescapable flaws begin. A sample, in no particular order:

1. LabVIEW has a 1:1 correspondence between functions, files, and user interfaces. Every time you see a function (subVI in LabVIEW parlance), and want to know what it does, you'll end up opening 2 windows: the user interface, which for 90+% of vis is never actually shown to the user, or holds any relevant information whatsover, but has to be opened nonetheless), and the code, which may be trivial, or may be complex, but you had no way of knowing before you dove in. Because it takes up a whole window, you get far and beyond less information density than in a textual programming language, which pushes towards inlining a lot of repeated code, but because the actual experience of writing LabVIEW is so miserable, you'll want to implement a lot of stuff as subVIs. It's a lose-lose.

2. LabVIEW's pretty-path for software development is untestable. At some point, you'll say "Ah, I can make user interfaces actually work the way anybody wants them to using Events!". Events are lovely, except you cannot test them. Period. Despite LabVIEW being uniquely situated to allow for a system for inserting mocking code between all those user interfaces you've been making and your code, they refuse to do so, and since LabVIEW is proprietary garbage, you can't even fix this yourself.

3. Pixel art for subVI icons. Here, you get make a terrible choice: When looking at some LabVIEW code, do you want to A) have basically no way to distinguish between different functions without hovering over them (imagine if all your function names were func1() func2() etc, until you selected them), or B) spend an obnoxious amount of time designing little hieroglyphics for future programmers to decipher. The only silver lining is that you're fucked either way.

4. Laying out wires. Have you ever thought to yourself: "You know what I need? More freedom of choice when it comes to expressing myself through data flow"? Well good news! LabVIEW will give you an endless amount of personal freedom when it comes to expressing how data goes from the output of one function to the input of the next. Make sure to lay it out in a nice sane way, otherwise you will progressively go mad. If you get bored, you can always try and use the built in layout engine which, besides being written by an engineer who's idea of a tidying up is pushing all his crap against one wall and marveling at his newfound floor space, will also creatively route your wires all over the place. If you really enjoy formatting your code, LabVIEW might be a good choice.

5. On the topic of wires: You never really appreciate how much context gets encoded in variable names until you don't have any. Compared to other issues it's not THAT big a deal, but you'll miss it.

6. Version control: The diff tool works most but not all of the time, and the merge tool rarely can even load vis and when it can, it's utterly worthless anyway. Resolve all merge conflicts with "theirs" or "ours", or just abandon a branch based workflow altogether. Also, those binary blobs spontaneously change sometimes when opened.

7. No built-in support for Key-Value data structures. This leads to a lot of LabVIEW code falling back to either awkward structs (anonymous or otherwise), or using just a bunch of wires that should just always go everywhere together.

8. The interface is not resizeable. You cannot zoom in, you cannot zoom out, and if you deign to complain about it to NI you'll be told that you can avoid zooming out by making more, smaller vis, which besides making the issues of having too many Vis even worse, also completely fails to address the fact that I want to zoom in so that the tiny 5 pixel wires are a little more legible.

9. On the topic of things NI is aware of but is either too stubborn or dimwitted to fix: LABVIEW BREAKS ALT-TAB. Yes, that's right, the language where you need to regularly juggle having dozens of windows open breaks the most basic form of shortcut navigation. When you alt-tab to a Vi window, it brings every Vi window on top of whatever else you were doing. All several dozen of them. If you had the misfortune of having a VI running while you did that, that VI doesn't appear on the alt-Tab menu list at all. It's still there, buried somewhere, but you're going to have to drag every last window around to dig for it, like a Saint Bernard looking for an avalanche survivor. Again, don't bother complaining to NI about this, since they'll just spout some crap about how they can't fix it because it's just how Windows works. Nevermind the fact that this is the ONLY program I've ever seen that fucks up Alt-Tab like this.

In short, don't use LabVIEW for anything, unless it's some kind of S&M thing between you and your engineers.