Spoken like someone who's never worked on a large-scale LABVIEW system. A moderately sized codebase (equivalent to a project with a million-odd lines of code) ends up with a project containing tens if not hundreds of thousands of files. Each file opens up two windows, so if you're working on anything nontrivial you're going to have dozens and dozens of windows open at a time. Compiling such a project takes upwards of an hour, and you can't rely on the interpreter environment because it has observably different behavior than the resulting builds (oh, and the compilation process happens in the same process as the IDE, so that's completely bricked during that hour or two).

No one ever names their wires, so there's no variable names anywhere. To see the name of a subvi (think function), you have to hover over it. Sure there's a little picture, but that just means instead of just merely naming my functions I have to draw a little picture. Don't even get me started on wire routing, which is a crucial, manual process for any vi of non-trivial complexity.

Then there's the fundamental engine bugs, which National Instruments' response to hearing about is approximately "get fucked". Like, for example, the GUI rendering breaking in subtle ways when Windows has an update queued. Imagine getting a bug report that consists of "We can't do feature X", and trying desperately to figure out if your code is wrong, or if your customer's just an idiot, only to discover that 0.1% of the buttons in your project just... don't exist sometimes.

Then there's version control, which is rudimentary at best. In order to compare two files, you need to load both files, which even with lazy loading takes what feels like an eternity. Merges? No automation whatsoever. Every merge is manual.

Extremely useful features (like metaprogramming, which is important because of just how miserable writing LABVIEW is) are locked behind shoving obscure keys into ini files like "ABANDONALLHOPEYEWHOENTERHERE=1" or "SuperSecretPrivateSpecialStuff=true" (That second one is real).

Don't get me wrong, LabVIEW has its place as a way to hack together a little control panel to talk to some instruments. But anyone suggesting adding a subvi should be shot, and the project should be rewritten in a real programming language.

> Spoken like someone who's never worked on a large-scale LABVIEW system.

That's exactly false. I've single-handedly developed multi-thousand VI projects on different systems, including heavily using the OOP system and actor frameworks.