[bmitc]

> Moving from LABVIEW to a real programming language ... Switching from C++ to Rust? Probably not.

Weird. LabVIEW is a real programming language. And both LabVIEW and Rust make entire classes of bugs that you often hit in C++ go away, especially for concurrent programs.

> remotely modern development tooling

I would make the argument that it is the tooling, i.e., Git and Diff, that is ancient and not remotely modern. Continually demanding that anything worth source controlling is text-based, and even further line-based, is as antiquated as it gets.

[bri3d]

> Continually demanding that anything worth source controlling is text-based, and even further line-based, is as antiquated as it gets.

Do you have examples of working version control for non-text programs, including the ability to combine work from two parallel workstreams (aka, merge)? I worked for a long time at probably one of the largest companies using non-text based programming and version control was never even close to solved, and my subsequent forays into the literature when I worked in the "no code workflow" space still came up empty handed for working solutions here. We always fell back to "try to represent the structure of the change in some text-based way."

[OkayPhysicist]

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.

[bmitc]

> 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.