Re:Why Engineers Can't Be Rational About Programming Languages
by bmitc on Tuesday November 04, 2025 @08:16PM
(#45817915)
> 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.
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.