3 ms·

Everyone I know who programs LabVIEW programs like the anti-example shown in the article. It's not LabVIEW's fault, you can certainly develop cleanly. The probl

Everyone I know who programs LabVIEW programs like the anti-example shown in the article. It's not LabVIEW's fault, you can certainly develop cleanly. The problem is that quick proof-of-concepts developed by non programmers (technicians, scientists) turn into solutions that become unsupportable. This isn't to say that traditional languages and programming tools offer better solutions to current LabVIEW users, though.

bmitc 4y ago
I worked in LabVIEW for close to a decade. I never saw something close to that screenshot. I did see bad LabVIEW programs for sure, and nothing ever met my personal standards. I also saw a Python file that was the entire program with over 10,000 lines and function signatures / argument lists that were 10-30 lines long. Just the signatures / argument lists, not including the actual function body. My introduction to LabVIEW though was people taking it seriously as a programming language. We used Perforce and did code reviews using graphical code review systems. It was actually pretty nice. My main point is that there is nothing inherent to the visual paradigm that causes this. It's mainly a merger of two things: the visual paradigm making it more apparent than text-based programs, and the makeup of people writing the programs. Any language can support a bad programming making all the foot guns they'd like. The fact that that screenshot keeps appearing tells me it's reposted by people who have never actually worked in LabVIEW. It's just the first thing that comes up when they search for it. I have some LabVIEW code here: https://github.com/slo-systems https://github.com/slo-systems. It's just a couple of libraries I developed in my spare time at the moment and not big systems, but it's at least in a step in the direction of what I'd consider good code. All that to say, can LabVIEW be improved? Yes, in the same way that any language and IDE can be improved. We have a long way to go for software development.

bmitc 4y ago

I worked in LabVIEW for close to a decade. I never saw something close to that screenshot. I did see bad LabVIEW programs for sure, and nothing ever met my personal standards. I also saw a Python file that was the entire program with over 10,000 lines and function signatures / argument lists that were 10-30 lines long. Just the signatures / argument lists, not including the actual function body. My introduction to LabVIEW though was people taking it seriously as a programming language. We used Perforce and did code reviews using graphical code review systems. It was actually pretty nice. My main point is that there is nothing inherent to the visual paradigm that causes this. It's mainly a merger of two things: the visual paradigm making it more apparent than text-based programs, and the makeup of people writing the programs. Any language can support a bad programming making all the foot guns they'd like. The fact that that screenshot keeps appearing tells me it's reposted by people who have never actually worked in LabVIEW. It's just the first thing that comes up when they search for it. I have some LabVIEW code here: https://github.com/slo-systems https://github.com/slo-systems. It's just a couple of libraries I developed in my spare time at the moment and not big systems, but it's at least in a step in the direction of what I'd consider good code. All that to say, can LabVIEW be improved? Yes, in the same way that any language and IDE can be improved. We have a long way to go for software development.