4 ms·

> The problem with visual programming languages (the focus of the articles seems to be on them) is that they don't scale in size and complexity. For large proje

by bmitc 4y ago

> The problem with visual programming languages (the focus of the articles seems to be on them) is that they don't scale in size and complexity. For large projects, you end up with visualizations like the LabView one in the article. That is not true. (1) No one programs LabVIEW like that, and if they do, then they aren't doing code reviews or taking software development seriously. In fact, the visual 2D nature of LabVIEW is a feature, because it becomes immediately and visually apparent if your code is actual spaghetti or not, as in the meme-like picture that gets posted constantly. Spaghetti code certainly exists in text-based languages, but it is not so readily apparent. (2) I have built large, complex systems with LabVIEW, in fact larger than any text-based program I've worked on in industry. I wish they were publicly available/publishable to show, but they are not, unfortunately. LabVIEW scales well for the same reason that languages like Erlang and Elixir scale well. It has built-in concurrency and multi-threading and the core data types, including its OOP objects, are immutable. When scaling, the issues one comes across do not relate to the visual representation but rather other issues specific to the implementation of the LabVIEW IDE.

IshKebab 4y ago
> No one programs LabVIEW like that. You mean it's possible to not program LabVIEW like that. Probably true but in my experience people do make programs like that (though not as extreme). I think that meme is a real program. In fairness to visual programming I think LabVIEW does give it an unnecessarily bad name purely because it is so damn ugly and unreadable. They didn't have to make everything out of Windows 3.1 16x16px icons and the ugliest line styles you could come up with. Simulink looks way nicer for example. But I still think they make little sense. Editing them is a huge pain, and adding comments is enough of a pain that nobody does it (I'm generalising; I'm sure you are the rare exception). I think it's pretty telling that logic designers use SystemVerilog and not some graphical circuit diagram type thing even though they're literally designing circuits.
- docfort 4y ago
  I take your meaning, but just to nitpick one thing here in your argument: SystemVerilog is commonly used to model an abstract machine which is then synthesized into realizable circuits. Its selling point was compatibility and similarity to C, Verilog, and VHDL, all textual languages because the proprietary processing code was built that way. It doesn’t necessarily have to be this way, but it turned out this way, so logic designers don’t have another realistic option. Combine this with the misconception that HDLs are programming instead of modeling, and you have a setup for confusion. https://research.ibm.com/haifa/Workshops/verification2004/papers/system_verilog_overview-ibm-symposium-johny_srouji.pdf https://research.ibm.com/haifa/Workshops/verification2004/pa...
  - IshKebab 4y ago
    > It doesn’t necessarily have to be this way, but it turned out this way, so logic designers don’t have another realistic option. I mean, I think if graphical programming were really that compelling another option would have presented itself. People are constantly trying to introduce new graphical programming systems. > Combine this with the misconception that HDLs are programming instead of modeling I don't think that's really a misconception unless you have an especially pedantic definition of "programming". As you literally just said, Verilog was originally designed for simulation only - you literally were writing a simulation program. The act of programming Verilog is not really that different from programming C. The only difference is that the abstract machine your code runs in is very different (for synthesisable code anyway).
- bmitc 4y ago
  You can program an FPGA in LabVIEW easier and faster than you can with straight toolchains like what Xilinx provides. The problem there is that you're bound to NI's hardware (which is both the pro and con). But several people are moving to higher-level DSLs, like Chisel. I learned LabVIEW before I learned VHDL. It felt kind of silly learning VHDL when you draw out chips and think about them visually but then have to "compile" them down to VHDL yourself. Mathworks makes visual tools for coding FPGAs as well. I think there's a future for tools that make FPGAs easier to design. > adding comments is enough of a pain that nobody does it Interesting. Adding comments is as easy as double-clicking on the diagrams. It's even nice because you can paste in picture comments easily, from presentations, manuals, references, etc.
zwieback 4y ago
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.

by bmitc 4y ago

IshKebab 4y ago

> No one programs LabVIEW like that. You mean it's possible to not program LabVIEW like that. Probably true but in my experience people do make programs like that (though not as extreme). I think that meme is a real program. In fairness to visual programming I think LabVIEW does give it an unnecessarily bad name purely because it is so damn ugly and unreadable. They didn't have to make everything out of Windows 3.1 16x16px icons and the ugliest line styles you could come up with. Simulink looks way nicer for example. But I still think they make little sense. Editing them is a huge pain, and adding comments is enough of a pain that nobody does it (I'm generalising; I'm sure you are the rare exception). I think it's pretty telling that logic designers use SystemVerilog and not some graphical circuit diagram type thing even though they're literally designing circuits.

docfort 4y ago
I take your meaning, but just to nitpick one thing here in your argument: SystemVerilog is commonly used to model an abstract machine which is then synthesized into realizable circuits. Its selling point was compatibility and similarity to C, Verilog, and VHDL, all textual languages because the proprietary processing code was built that way. It doesn’t necessarily have to be this way, but it turned out this way, so logic designers don’t have another realistic option. Combine this with the misconception that HDLs are programming instead of modeling, and you have a setup for confusion. https://research.ibm.com/haifa/Workshops/verification2004/papers/system_verilog_overview-ibm-symposium-johny_srouji.pdf https://research.ibm.com/haifa/Workshops/verification2004/pa...
- IshKebab 4y ago
  > It doesn’t necessarily have to be this way, but it turned out this way, so logic designers don’t have another realistic option. I mean, I think if graphical programming were really that compelling another option would have presented itself. People are constantly trying to introduce new graphical programming systems. > Combine this with the misconception that HDLs are programming instead of modeling I don't think that's really a misconception unless you have an especially pedantic definition of "programming". As you literally just said, Verilog was originally designed for simulation only - you literally were writing a simulation program. The act of programming Verilog is not really that different from programming C. The only difference is that the abstract machine your code runs in is very different (for synthesisable code anyway).
bmitc 4y ago
You can program an FPGA in LabVIEW easier and faster than you can with straight toolchains like what Xilinx provides. The problem there is that you're bound to NI's hardware (which is both the pro and con). But several people are moving to higher-level DSLs, like Chisel. I learned LabVIEW before I learned VHDL. It felt kind of silly learning VHDL when you draw out chips and think about them visually but then have to "compile" them down to VHDL yourself. Mathworks makes visual tools for coding FPGAs as well. I think there's a future for tools that make FPGAs easier to design. > adding comments is enough of a pain that nobody does it Interesting. Adding comments is as easy as double-clicking on the diagrams. It's even nice because you can paste in picture comments easily, from presentations, manuals, references, etc.

zwieback 4y ago

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.