>>> I've programmed LabVIEW professionally and didn't have to take breaks every few minutes.
It might vary with individual physiology. I worked in LabVIEW for several months, more than 25 years ago, and the combination of eyestrain headaches and wrist truma were practically debilitating. To be fair, I also had problems with any software that involved tiny graphics, elaborate menus, and fine mouse work, such as CAD.
Text based programming, and plain text editing, are actually things that I use as a refuge from the physical demands of operating GUI based software.
Yeah to be fair, LabVIEW is the absolute worst graphical programming system. For something that is literally all about graphics you'd think they'd hire a graphic designer. LabVIEW looks like they tried to make an example of how not to do it.
I'm not a fan of graphical systems in general for other reasons, but we probably shouldn't decide anything based on something as bad as LabVIEW. Simulink is way better for example.
Nobody should write programs like that. That would not pass code review in a serious LabVIEW team.
> Yeah to be fair, LabVIEW is the absolute worst graphical programming system.
That's a strong statement. I am unaware of any visual programming environment as powerful as LabVIEW. Nothing is close. LabVIEW has several features over text-base languages as well.
However, I am a strong critic of LabVIEW, but not for the reasons you list. The UX could definitely be improved, and this is something I'm looking into.
NI did embark on the LabVIEW NXG (next-generation) project but boggled it. It is tough. LabVIEW is thirty something years old. The only remaining product from the NXG endeavor is the LabVIEW NXG Web Module. There were some improvements but there could have been more. It failed due to mismanagement.
I tend to separate LV into the language and its graphical representation. The language is highly optimized dataflow programming with extensive hardware libraries for data acquisition and control. If your problem lends itself to a performant dataflow solution, LV is worth checking out. The machine that discovered the Higgs Boson was programmed in a custom LabVIEW.
There's a belief that LV is easy for novices to learn, such as test technicians and engineers. Interestingly, the other easy "language for the rest of us," Excel, is also a dataflow programming environment.
The graphical "language" was introduced for the Apple Mac II at a time when there was a lot of excitement for "graphical everything," and again a view that the graphical flow chart would make it intuitive for non-programming engineers. The simplest LV programs had an almost 1:1 correspondence to things that were familiar in test hardware such as knobs, switches, meters, and so forth.
Now my main critique is the sheer physical labor required to write and edit programs. This could actually lead to sloppy code, if it's too painful to refactor things. I think that if there were a good text based dataflow language, and LV adopted it, the graphical language would fall into much more limited use (e.g., for adding user interfaces to programs). That's just my hunch.
It might vary with individual physiology. I worked in LabVIEW for several months, more than 25 years ago, and the combination of eyestrain headaches and wrist truma were practically debilitating. To be fair, I also had problems with any software that involved tiny graphics, elaborate menus, and fine mouse work, such as CAD.
Text based programming, and plain text editing, are actually things that I use as a refuge from the physical demands of operating GUI based software.