Here is a long list of reasons this is a bad idea: https://blueprintsfromhell.tumblr.com/ https://blueprintsfromhell.tumblr.com/ Having used my fair share of l

Here is a long list of reasons this is a bad idea: https://blueprintsfromhell.tumblr.com/ https://blueprintsfromhell.tumblr.com/ Having used my fair share of labview i know such examples are reality. Common mistake of the model is the sentiment that because it's visual everybody can do it! Biggest wtf i experienced was when system engineers wrote half completed "reference-implementations" in labiew, which coders then had to translate to Java for production, to sort out all the edge cases, because these visual tools (and the people that use them) are very bad at expressing edge cases. They might as well have given us graphs drawn on paper because the references were so far from reality you could never run them. Together with that, when the only tool you have is a hammer, everything looks like a nail. Take https://blueprintsfromhell.tumblr.com/image/162487395171 https://blueprintsfromhell.tumblr.com/image/162487395171 as an example, it's actually one of the simpler graphs from that page. But if you take a look at it you see it's just doing standard function calls in a sequence, like trunctate(), toText() setText(), what's then the point of making it visual?! For simple signal control loops with only mathematical operations the labview model works really well, but when you start doing things like subString, groupBy or indexOf and don't realize you should change domain, that's when you get the worst spaghetti. The benefit of a visual representation is that there are different ways to visualize things and you can choose which one fits the problem best. You have sequence, dependency, state, class, call-graphs, signals, lexical parsers, tables, charts, etc. Most visual environments only implement one of these and very soon you are using the wrong tool for the job.