Hacker News new | past | comments | ask | show | jobs | submit login

Having spent a lot of time using Labview I would agree that it can be an amazingly useful tool (highly performant code and easily interfaces with data acquisition devices). That being said, LabView shows the limitations of Visual Coding:

Sharp Learning Curve Difficult to find help or code snippets online Lack of decent Version Control Finding the function you want is hard (requires navigating several submenus) *All of the icon symbols look the same

Also, while LabView offers a great platform for an object oriented coding style, I feel like the 2d layout always results in a messy sprawl rather than layers of abstraction. This could be because LabView is used by people with less traditional software background, or it may be that making new functions in a bit of a pain in LV.

Some of your complaints come from the fact that LabVIEW is pretty niche. It would need at least an order of magnitude more developers to see numbers like C/C++. That's why you're not finding much online help.

There is also the fact that LabVIEW is old. Like REALLY old. LabVIEW came out over 30 years ago and as such has a lot of legacy cruft along with lacking some of the more modern goals such as good scaling source control. LabVIEW was also designed by a hardware first company and has always been geared towards building that hardware ecosystem.

Finally, yea, poor programming practices exist in all languages. In visual languages, it makes them hard to read. Sometimes this forces you to be clever to reduce the flow complexity by increasing the logic or mathematical complexity which is it's own can of programming worms we could debate for hours.

Fair points. A lot of the issues with Visual Programming are related to the supporting tools - something the author mentions. That being said, text input easily supports search, pattern matching and code sharing, so what are the benefits to visual coding to justify building all these tools?

In my experience it is harder to implement good programing practices in a visual programing environment. For example, abstracting, consolidating and refactoring visual code is much more challenging because of the sprawl of wires...

Code sharing is actually really good in visual languages if done right because you are forced to have well defined inputs and outputs for your nested structure. Search is getting better and is not bad in Simulink. Pattern matching would be an interesting research project. Those big wire rats nests typically come about because the people using visual languages (especially Simulink and LabVIEW) are only doing that as their secondary or tertiary job. It's more important to get something working out the door than to do it well and proper and maintainable. Besides, it's hardly limited to visual languages; I'm sure nearly everyone here has gone back to some code they wrote in the past and found it nearly indecipherable.

The main benefits of visual languages is that they allow domain specific people to work in methods that are natural to the problem and closer to what they are used to. Some problems can be represented very easily visually but are a big pain in code such as physical systems. Data flow and timing diagrams lend themselves very well to visual descriptions and can help prevent race conditions. WYSIWYG editors open up software domains to huge swaths of people who go on to produce some incredible work. Yeah, ultimately, people run up against the limitations of these programming environments and then you either transition to a less friendly but more scalable code, turn into spaghetti mess, or give up.

I think the biggest thing text based code development has for it is that text is inherently "open" and simple to share so tools get built for it while most visual languages tend to be proprietary, niche, and locked down. Maybe one day we will see a solid FOSS visual programming language/environment that hits above it's weight and can drop into other languages specifically for handling types of problems. I think that would be ideal but articles like this one that are close to straw man arguments don't help get anyone excited to work on it.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact