<story><title>Folk wisdom on visual programming</title><url>https://drossbucket.com/2021/06/30/hacker-news-folk-wisdom-on-visual-programming/</url></story><parent_chain><item><author>bmitc</author><text>&amp;gt; I used LabVIEW extensively for a few months&lt;p&gt;I’m not sure that a few months is enough to understand the true pros and cons of a language. I’m using Elixir in my day job now and have used F# for side projects, and it’s not clear to me any one is faster to program in, especially for GUIs. LabVIEW actually shines, contrary to popular but inexperienced opinion, for large projects. I have used LabVIEW rather extensively, and it seems any project would have seen massive delays if I used something else, which is why I didn’t.&lt;p&gt;But I can indeed see an argument for strain when using the mouse so much. I have experienced that before and improved my ergonomic setup. As an aside, it is curious to me that many programmers are heavy PC gamers as the one true way to game and don’t complain about the mouse use there but will throw out all sorts of complaints when using it to program or use tools.&lt;p&gt;&amp;gt; New ideas in graphical software require software intensive effort to try out.&lt;p&gt;This “problem” isn’t inherent to graphical programming though. It’s because legions of programmers are convinced that text=programming and have spent decades writing text-only tools. You see this friction when using LabVIEW with GitHub, whose tooling is incompatible with the diff and merge tools that come with LabVIEW, which makes GitHub look outdated and not LabVIEW.&lt;p&gt;I’m actually working on ideas to build a toolkit for graphical programming languages. There are certainly challenges though, such as the desktop GUI ecosystem being a mess and reliance upon graph data structures and algorithms (like automatic layout).&lt;p&gt;&amp;gt; On the other hand, there does seem to be something about data flow programming (LabVIEW, Excel) that is attractive to beginners&lt;p&gt;Dataflow is attractive to advanced users as well, which is part of the draw to languages like F#, Elixir, Racket, Clojure, etc. Although, the dataflow in LabVIEW is actually more advanced, which is basically a multithreaded and branched version of the single threaded linear pipelines found in the languages I mentioned. Working in F# and Elixir with pipes can be pretty irritating sometimes given my knowledge of LabVIEW.</text></item><item><author>analog31</author><text>The author alludes to problems related to complexity, modularity, and formatting, of visual code. I think a hard problem for visual languages is the sheer physical labor of creating code using drawing tools.&lt;p&gt;I used LabVIEW extensively for a few months, and ended up with crippling wrist fatigue and eyestrain headaches from all of the fine mouse work and menu selections needed to write even small programs. This is an ergonomic problem with all graphical software, but is particularly acute with programming because of the amount of code that gets written.&lt;p&gt;Another problem is innovation. You can quickly spin up an experimental language and try it out because the infrastructure -- editor and command shell -- already exist. This is one reason why we enjoy such a proliferation of new language ideas. New ideas in graphical software require intensive effort to try out.&lt;p&gt;On the other hand, there does seem to be something about data flow programming (LabVIEW, Excel) that is attractive to beginners, that can&amp;#x27;t be overlooked. Excel is probably the number-one programming tool in use right now.</text></item></parent_chain><comment><author>dkersten</author><text>&amp;gt; But I can indeed see an argument for strain when using the mouse so much. I have experienced that before and improved my ergonomic setup. As an aside, it is curious to me that many programmers are heavy PC gamers as the one true way to game and don’t complain about the mouse use there but will throw out all sorts of complaints when using it to program or use tools.&lt;p&gt;I wonder also how using visual languages like LabVIEW compares to other mouse-heavy computer users like photo editors&amp;#x2F;graphic designers, CAD users etc.&lt;p&gt;&amp;gt; Dataflow is attractive to advanced users as well&lt;p&gt;I quite enjoyed using Max&amp;#x2F;MSP a few years ago when I did some stuff with it for a few months. I&amp;#x27;ve always wished I had it available as a general purpose language in my programming toolbox since. As for other advanced users who use (visual) dataflow, my go to example is Ansys&amp;#x27; SCADE Suite[1][2][3], which is used for critical systems like trains, helicopters and power plants.&lt;p&gt;[1] &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;www.ansys.com&amp;#x2F;products&amp;#x2F;embedded-software&amp;#x2F;ansys-scade-suite&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;www.ansys.com&amp;#x2F;products&amp;#x2F;embedded-software&amp;#x2F;ansys-scade...&lt;/a&gt;&lt;p&gt;[2] &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;www.ansys.com&amp;#x2F;content&amp;#x2F;dam&amp;#x2F;product&amp;#x2F;embedded-software&amp;#x2F;ansys-scade-suite&amp;#x2F;ansys-scade-suite-2021-r2-datasheet.pdf&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;www.ansys.com&amp;#x2F;content&amp;#x2F;dam&amp;#x2F;product&amp;#x2F;embedded-software&amp;#x2F;...&lt;/a&gt;&lt;p&gt;[3] &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;www.youtube.com&amp;#x2F;watch?v=5z0h-WeScqw&amp;amp;list=PL0lZXwHtV6Ok5s-iSkBjHirM1fu53_Phv&amp;amp;index=1&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;www.youtube.com&amp;#x2F;watch?v=5z0h-WeScqw&amp;amp;list=PL0lZXwHtV6...&lt;/a&gt; (the third video introduces the visual language)</text></comment>
<story><title>Folk wisdom on visual programming</title><url>https://drossbucket.com/2021/06/30/hacker-news-folk-wisdom-on-visual-programming/</url></story><parent_chain><item><author>bmitc</author><text>&amp;gt; I used LabVIEW extensively for a few months&lt;p&gt;I’m not sure that a few months is enough to understand the true pros and cons of a language. I’m using Elixir in my day job now and have used F# for side projects, and it’s not clear to me any one is faster to program in, especially for GUIs. LabVIEW actually shines, contrary to popular but inexperienced opinion, for large projects. I have used LabVIEW rather extensively, and it seems any project would have seen massive delays if I used something else, which is why I didn’t.&lt;p&gt;But I can indeed see an argument for strain when using the mouse so much. I have experienced that before and improved my ergonomic setup. As an aside, it is curious to me that many programmers are heavy PC gamers as the one true way to game and don’t complain about the mouse use there but will throw out all sorts of complaints when using it to program or use tools.&lt;p&gt;&amp;gt; New ideas in graphical software require software intensive effort to try out.&lt;p&gt;This “problem” isn’t inherent to graphical programming though. It’s because legions of programmers are convinced that text=programming and have spent decades writing text-only tools. You see this friction when using LabVIEW with GitHub, whose tooling is incompatible with the diff and merge tools that come with LabVIEW, which makes GitHub look outdated and not LabVIEW.&lt;p&gt;I’m actually working on ideas to build a toolkit for graphical programming languages. There are certainly challenges though, such as the desktop GUI ecosystem being a mess and reliance upon graph data structures and algorithms (like automatic layout).&lt;p&gt;&amp;gt; On the other hand, there does seem to be something about data flow programming (LabVIEW, Excel) that is attractive to beginners&lt;p&gt;Dataflow is attractive to advanced users as well, which is part of the draw to languages like F#, Elixir, Racket, Clojure, etc. Although, the dataflow in LabVIEW is actually more advanced, which is basically a multithreaded and branched version of the single threaded linear pipelines found in the languages I mentioned. Working in F# and Elixir with pipes can be pretty irritating sometimes given my knowledge of LabVIEW.</text></item><item><author>analog31</author><text>The author alludes to problems related to complexity, modularity, and formatting, of visual code. I think a hard problem for visual languages is the sheer physical labor of creating code using drawing tools.&lt;p&gt;I used LabVIEW extensively for a few months, and ended up with crippling wrist fatigue and eyestrain headaches from all of the fine mouse work and menu selections needed to write even small programs. This is an ergonomic problem with all graphical software, but is particularly acute with programming because of the amount of code that gets written.&lt;p&gt;Another problem is innovation. You can quickly spin up an experimental language and try it out because the infrastructure -- editor and command shell -- already exist. This is one reason why we enjoy such a proliferation of new language ideas. New ideas in graphical software require intensive effort to try out.&lt;p&gt;On the other hand, there does seem to be something about data flow programming (LabVIEW, Excel) that is attractive to beginners, that can&amp;#x27;t be overlooked. Excel is probably the number-one programming tool in use right now.</text></item></parent_chain><comment><author>sideshowb</author><text>&amp;gt; As an aside, it is curious to me that many programmers are heavy PC gamers as the one true way to game and don’t complain about the mouse use there but will throw out all sorts of complaints when using it to program&lt;p&gt;Are those definitely the same people? Mouse use is certainly one of the reasons I gave up gaming. (The other being that an X hour working day is quite enough time to spend in front of a computer already).</text></comment>