Folk wisdom on visual programming
Yeah, this is going to be yet another &quot;visual programming&quot; topic.<p>I sort of disagree with the intro to LabVIEW:<p>&gt; There are a large number of visual programming tools that are roughly in the paradigm of ‘boxes with some arrows between them’, like the LabVIEW example above. I think the technical term for these is ‘node-based’, so that’s what I’ll call them.<p>There are NOT a &quot;large number&quot; of visual programming tools that are roughly in the paradigm [...] like LabVIEW. I am sure there are some but, really, how many active ones?<p>Also, &quot;node-based&quot; is not the main concept. The most essential concept of LabVIEW is known as &quot;data-flow&quot; (<a href="https:&#x2F;&#x2F;labviewwiki.org&#x2F;wiki&#x2F;Data_flow" rel="nofollow">https:&#x2F;&#x2F;labviewwiki.org&#x2F;wiki&#x2F;Data_flow</a>). Data generated by a node &quot;flows&quot; to the other nodes it is connected to and when any node has data on all it&#x27;s inputs, it executes and produces data which flows to whatever nodes it&#x27;s connected to. This happens asynchronously. You get concurrency &quot;out of the box&quot; with LabVIEW. That&#x27;s extremely powerful and much easier to reason about, IMHO, than the concurrency constructs in virtually any mainstream computer language.<p>I think there&#x27;s plenty of room for all kinds of languages (both text and visual) as DSL&#x27;s. If they&#x27;re well-designed and intuitive, they&#x27;re like a hot-knife through butter for a domain expert. The nice thing about a really good DSL is that you use it more like a library, whereas with a general purpose language you would be reaching for a framework. It gives you a lot of creative latitude and it feels right. The problems start when people start using them as golden hammers, or use them for things which they&#x27;re not good at.