2 ms·
As someone currently employed to port an absolutely gargantuan (~10,000 vi) LabVIEW project to C#, there are very good reasons to not use visual programming lan
by OkayPhysicist 4y ago
As someone currently employed to port an absolutely gargantuan (~10,000 vi) LabVIEW project to C#, there are very good reasons to not use visual programming languages.
1. Writing it is a pain. This is a minor gripe, comparably, but if you already know what you want it is very, very hard to beat just typing out a word. Dragging and dropping through menus makes every little action take too long for comfort. You also miss out on the syntactic sugar that makes coding so much more bearable: little, everyday things, like indexing into an array, or incrementing a value, end up taking just as long as putting in any other function.
2. The information density is atrociously low. Intuitively, it seems like the opposite should be true, after all, in a real programming language you're missing out on pictures and icons and a whole dimension of space. But it turns out that the whole "function reads top-to-bottom" thing packs a lot of flow information.
3. Flow-based value passing robs you of variable naming. In a language like LabVIEW, you very rarely use typed out variable names. Most are replaced by unnamed wires. This subtle feature strips the program of a lot of contextual information, making it hard to read.
4. Linting. If you thought making consistent, presentable code is hard in 1D space, in 2D it's basically intractable. The amount of time I spend futzing with wire pathing is infuriating.
If there is any chance that a project will require software developers some day (if you're starting a business, or inventing something novel, it will) just bite the bullet and use a real programming language. Visual programming just attempts to make the easiest part of programming easier, and makes everything else more painful in the process.
- analog31 4y agoI used LabVIEW quite extensively in a past job, and eventually switched to Visual Basic. The stuff I was doing didn't need the performance of LV. I found graphical programming to be physically debilitating due to eyestrain and wrist fatigue. Granted, this affects each person differently, and I also don't use CAD for the same reason. I can type text with my eyes closed, or while I shift my visual focus away from the screen. I think a reason why LV programs always seem so unreadable is that the sheer physical effort to clean them up gets the best of the people doing the programming. A general issue with graphical programming is that you're responsible for the developer interface, and really sweating the details to make it tolerably ergonomic is phenomenally costly in time and effort -- think of how many programmers are employed by Apple or Microsoft. In contrast, when experimenting with a new or improved text based language, you can piggyback off of existing IDE's or even basic text editors, and get a running head start on adoption by a user community. And the economics are such that languages and IDEs can be supported as open source projects. There are text based dataflow programming langauges, and I think if LV adopted one of them as an option, folks would stop using the graphical environment after getting over the initial hump of learning to program. I always show people this: https://www.ni.com/docs/en-US/bundle/labview/page/gmath/nonlinear_curve_fit.html https://www.ni.com/docs/en-US/bundle/labview/page/gmath/nonl...