5 ms·

Yeah, this is going to be yet another "visual programming" topic. I sort of disagree with the intro to LabVIEW: > There are a large number of visual programmi

Yeah, this is going to be yet another "visual programming" topic. I sort of disagree with the intro to LabVIEW: > 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. There are NOT a "large number" of visual programming tools that are roughly in the paradigm [...] like LabVIEW. I am sure there are some but, really, how many active ones? Also, "node-based" is not the main concept. The most essential concept of LabVIEW is known as "data-flow" (https://labviewwiki.org/wiki/Data_flow https://labviewwiki.org/wiki/Data_flow). Data generated by a node "flows" to the other nodes it is connected to and when any node has data on all it's inputs, it executes and produces data which flows to whatever nodes it's connected to. This happens asynchronously. You get concurrency "out of the box" with LabVIEW. That's extremely powerful and much easier to reason about, IMHO, than the concurrency constructs in virtually any mainstream computer language. I think there's plenty of room for all kinds of languages (both text and visual) as DSL's. If they're well-designed and intuitive, they'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're not good at.

jayd16 5y ago
>There are NOT a "large number" of visual programming tools that are roughly in the paradigm [...] like LabVIEW. They list half a dozen or so. Most of the node based systems are also flow oriented, aka nodes are functional and stateless which allows them to be mapped across any amount of input. It's a neat pattern but it's really not as uncommon as you think. The mainstream shader languages work this way, for example.
koolhaas 5y ago
> Data generated by a node "flows" to the other nodes it is connected to and when any node has data on all it's inputs, it executes and produces data which flows to whatever nodes it's connected to. I think you just described flow programming. There are at least 10+ visual languages / environments that work like this.
bmitc 5y ago
In my opinion, LabVIEW is the most general purpose and powerful visual programming language. Others I know of are vvvv gamma where the recent update basically makes it a .NET language (although LabVIEW also has .NET integration) and Pure Data. Other tools are Simulink, TouchDesigner, Max/MSP, and Grasshopper for Rhino. After that, it drops off pretty rapidly to a collection of barely used or even known about tools pr highly specialized node-based tools.
- auxym 5y ago
  Another example is ncode Glyohworks, which was used by a very large company I used to work for, for test data post-processing.
deleted 5y ago
[deleted]
DonHopkins 5y ago
If not a "large number", then more like a "huge number". Even the single application Blender itself has several different visual node based programming systems (most but not all built on top of the same framework, and applied to different kinds of programming), for shader programming, CPU image processing, video compositing, lighting, animation and constraints, particle systems, physics simulations, procedural mesh generation, and the Blender Foundation and third parties are developing even more, like procedural city generation: Procedural city generation: https://www.youtube.com/watch?v=jb_jwsyfQc4&ab_channel=derbender https://www.youtube.com/watch?v=jb_jwsyfQc4&ab_channel=derbe... Everything nodes: https://code.blender.org/2020/12/everything-nodes-and-the-scattered-stone/ https://code.blender.org/2020/12/everything-nodes-and-the-sc... Nodes Workshop - 22 - 25 June 2021 https://devtalk.blender.org/t/nodes-workshop-22-25-june-2021/19321 https://devtalk.blender.org/t/nodes-workshop-22-25-june-2021... >“It is like compositor but for physics”. The complete beginners guide to Blender nodes, Eevee, Cycles and PBR: https://artisticrender.com/the-complete-beginners-guide-to-blender-nodes-eevee-cycles-and-pbr/ https://artisticrender.com/the-complete-beginners-guide-to-b... >Blender has a few nodes systems. The first and obvious one is Blenders shading system for Cycles and Eevee. This is the node system that we will focus on in this article. >But we also have nodes for compositing, lighting and textures, even if the use case and future for texture nodes are uncertain at this point. >We can also extend Blender with other node systems through add-ons. The most well-known is probably animation nodes that come bundled with Blender. >There are also other node systems available for Blender. AMD ProRender for example, a third-party render engine that has its own shader node system. Another example is Luxrender. There is also mTree for generating trees with nodes and Sverchok that can manipulate all kinds of data with nodes. Reposting this from a few years ago: https://news.ycombinator.com/item?id=18496880 https://news.ycombinator.com/item?id=18496880 There's so much interesting prior work! I really enjoyed this paper “A Taxonomy of Simulation Software: A work in progress” from Learning Technology Review by Kurt Schmucker at Apple. It covered many of my favorite systems. http://donhopkins.com/home/documents/taxonomy.pdf http://donhopkins.com/home/documents/taxonomy.pdf It reminds me of the much more modern an comprehensive "Gadget Background Survey" that Chaim Gingold did at HARC, which includes Alan Kay's favorites, Rockey’s Boots and Robot Odyssey, and Chaim's amazing SimCity Reverse Diagrams and lots of great stuff I’d never seen before: http://chaim.io/download/Gingold%20(2017)%20Gadget%20(1)%20Survey.pdf http://chaim.io/download/Gingold%20(2017)%20Gadget%20(1)%20S... I've also been greatly inspired by the systems described in the classic books “Visual Programming” by Nan C Shu, and “Watch What I Do: Programming by Demonstration” edited by Alan Cypher. https://archive.org/details/visualprogrammin00shu_2pf https://archive.org/details/visualprogrammin00shu_2pf https://archive.org/details/watchwhatido00alle https://archive.org/details/watchwhatido00alle Brad Myers wrote several articles in that book about his work on PERIDOT and GARNET, and he also developed C32: C32: CMU's Clever and Compelling Contribution to Computer Science in CommonLisp which is Customizable and Characterized by a Complete Coverage of Code and Contains a Cornucopia of Creative Constructs, because it Can Create Complex, Correct Constraints that are Constructed Clearly and Concretely, and Communicated using Columns of Cells, that are Constantly Calculated so they Change Continuously, and Cancel Confusion http://www.cs.cmu.edu/~bam/acronyms.html http://www.cs.cmu.edu/~bam/acronyms.html Also, here's an interesting paper about Fabrik: https://donhopkins.com/home/Fabrik%20PE%20paper.pdf https://donhopkins.com/home/Fabrik%20PE%20paper.pdf Danny Ingalls, one of the developers of Fabrik at Apple, explains: "Probably the biggest difference between Fabrik and other wiring languages was that it obeyed modular time. There were no loops, only blocks in which time was instant, although a block might ’tick’ many times in its enclosing context. This meant that it was real data flow and could be compiled to normal languages like Smalltalk (and Pascal for Apple at the time). Although it also behaved bidirectionally (e.g. temp converter), a bidirectional diagram was really only a shorthand for two diagrams with different sources (this extended to multidirectionality as well)"
DonHopkins 5y ago
Also, spreadsheets are certainly one of the most popular, widely used, easily accessible, and important visual programming languages. It's not an understatement to say that the economy would grind to a halt and civilization as we know it would collapse if spreadsheets suddenly disappeared tomorrow. The article quoted one of my earlier posts on that subject, but I've written more about spreadsheets as visual programming, and cited Brad Myer's work and articles about visual programming languages, and there's more in the HN discussion of his classic 1989 paper "Visual Programming, Programming by Example, and Program Visualization; A Taxonomy," Proceedings SIGCHI '86: Human Factors in Computing Systems. Boston, MA. April 13-17, 1986. pp. 59-66: https://news.ycombinator.com/item?id=26645253 https://news.ycombinator.com/item?id=26645253 DonHopkins 3 months ago | on: Spreadsheet is a software development paradigm Spreadsheet certainly are visual programming languages: by any measure, by far one of the most common most widely used types of visual programming languages in the world. HN discussion: https://news.ycombinator.com/item?id=26057530 https://news.ycombinator.com/item?id=26057530 Taxonomies of Visual Programming (1990) [pdf] (cmu.edu) https://www.cs.cmu.edu/~bam/papers/VLtax2-jvlc-1990.pdf https://www.cs.cmu.edu/~bam/papers/VLtax2-jvlc-1990.pdf https://news.ycombinator.com/item?id=26061576 https://news.ycombinator.com/item?id=26061576 Brad Myers' paper answers the age-old argument about whether or not spreadsheets are visual programming languages! https://news.ycombinator.com/item?id=20425821 https://news.ycombinator.com/item?id=20425821 >DonHopkins on July 13, 2019 | on: I was wrong about spreadsheets (2017) >Google sheets (and other google docs) can be programmed in "serverless" JavaScript that runs in the cloud somewhere. It's hellishly slow making sheets API calls, though. Feels like some kind of remote procedure call. (Slower than driving Excel via OLE Automation even, and that's saying something!) Then it times out on a wall clock (not cpu time) limit, and breaks if you take too long. >A CS grad student friend of mine was in a programming language class, and the instructor was lecturing about visual programming languages, and claimed that there weren't any widely used visual programming languages. (This was in the late 80's, but some people are still under the same impression.) >He raised his hand and pointed out that spreadsheets qualified as visual programming languages, and were pretty darn common. >They're quite visual and popular because of their 2D spatial nature, relative and absolute 2D addressing modes, declarative functions and constraints, visual presentation of live directly manipulatable data, fonts, text attributes, background and foreground colors, lines, patterns, etc. Some even support procedural scripting languages whose statements are written in columns of cells. >Maybe "real programmers" would have accepted spreadsheets more readily had Lotus named their product "Lotus 012"? (But then normal people would have hated it!) I Was Wrong About Spreadsheets And I'm Sorry: https://www.reifyworks.com/writing/2017-01-25-i-was-wrong-about-spreadsheets-and-im-sorry https://www.reifyworks.com/writing/2017-01-25-i-was-wrong-ab... HN Discussion: https://news.ycombinator.com/item?id=26668885 https://news.ycombinator.com/item?id=26668885 Excerpt from "Taxonomies of Visual Programming and Program Visualization", by Brad A Myers, 1990/3/1, Journal of Visual Languages & Computing, Volume 1, Issue 1, pages 97-123: Spreadsheets, such as those in VisiCalc or Lotus 1-2-3, were designed to help nonprogrammers manage finances. Spreadsheets incorporate programming features and can be made to do general purpose calculations [71] and therefore qualify as a very-high level Visual Programming Language. Some of the reasons that spreadsheets are so popular are (from [43] and [1]): 1. the graphics on the screen use familiar, concrete, and visible representation which directly maps to the user's natural model of the data, 2. they are nonmodal and interpretive and therefore provide immediate feedback, 3. they supply aggregate and high-level operations, 4. they avoid the notion of variables (all data is visible), 5. the inner world of computation is suppressed, 6. each cell typically has a single value throughout the computation, 7. they are nondeclarative and typeless, 8. consistency is automatically maintained, and 9. the order of evaluation (flow of control) is entirely derived from the declared cell dependencies. The first point differentiates spreadsheets from many other Visual Programming Languages including flowcharts which are graphical representations derived from textual (linear) languages. With spreadsheets, the original representation in graphical and there is no natural textual language. Action Graphics [41] uses ideas from spreadsheets to try to make it easier to program graphical animations. The 'Forms' system [43] uses a more conventional spreadsheet format, but adds sub-sheets (to provide procedural abstraction) which can have an unbounded size (to handle arbitrary parameters). A different style of system is SIL-ICON [49], which allows the user to construct 'iconic sentences' consisting of graphics arranged in a meaningful two-dimensional fashion, as shown in Figure 5. The SIL-ICON interpreter then parses the picture to determine what it means. The interpreter itself is generated from a description of the legal pictures, in the same way that conventional compilers can be generated from BNF descriptions of the grammar. 10. Conclusions Visual Programming and Program Visualization are interesting areas that show promise for improving the programming process, especially for non-programmers, but more work needs to be done. The success of spreadsheets demonstrates that if we find the appropriate paradigms, graphical techniques can revolutionize the way people interact with computers. DonHopkins 3 months ago [–] https://news.ycombinator.com/item?id=26112751 https://news.ycombinator.com/item?id=26112751 Here's an example of a thread where somebody was fruitlessly trying to argue that a spreadsheet isn't a visual programming language: https://news.ycombinator.com/item?id=22984831 https://news.ycombinator.com/item?id=22984831 >lmm 9 months ago | on: Maybe visual programming is the answer, maybe not >If there was a visual programming language with anywhere near the popularity of Ruby, I'd be willing to consider that maybe the idea has some merit. >DonHopkins 9 months ago [–] >Excel. >I could turn your argument around: If Ruby were anywhere near as popular, widely used, and successful as Excel, I'd be willing to consider that maybe the idea that Ruby is a viable programming language has some merit. >But I won't, because whether or not something is a visual programming language isn't up to a popularity contest. >Can you come up with a plausible definition of visual programming languages that excludes Excel, without being so hopelessly contrived and gerrymandered that it also arbitrarily excludes other visual programming languages? [...] (TL;DR: he couldn't, since he was under the mistaken impression that Excel not programmable, and was less popular than Ruby...) That thread was on an earlier discussion about a blog posting from 2020 about the same 1989 paper by Brad Myers that we're currently discussing. https://news.ycombinator.com/item?id=22978454 https://news.ycombinator.com/item?id=22978454 https://blog.metaobject.com/2020/04/maybe-visual-programming-is-answer.html https://blog.metaobject.com/2020/04/maybe-visual-programming... >Maybe Visual Programming is The Answer. Maybe Not >Whenever discussing problems with programming today and potential solutions, invariably someone will pop up and declare that the problem is obviously the fact that programs are linear text and if only programming were visual, all problems would immediately disappear in some unspecified way. >I understand the attraction of visual programming, particularly for visual thinkers. However, it's not as if this hasn't been tried, with so far very limited success. Brad Myers, in his 1989 paper Taxonomies of Visual Programming gave, along with the titular taxonomy, a non-exhaustive summary of the problems, starting with visual languages in general: [...]

jayd16 5y ago

>There are NOT a "large number" of visual programming tools that are roughly in the paradigm [...] like LabVIEW. They list half a dozen or so. Most of the node based systems are also flow oriented, aka nodes are functional and stateless which allows them to be mapped across any amount of input. It's a neat pattern but it's really not as uncommon as you think. The mainstream shader languages work this way, for example.

koolhaas 5y ago

> Data generated by a node "flows" to the other nodes it is connected to and when any node has data on all it's inputs, it executes and produces data which flows to whatever nodes it's connected to. I think you just described flow programming. There are at least 10+ visual languages / environments that work like this.

bmitc 5y ago

In my opinion, LabVIEW is the most general purpose and powerful visual programming language. Others I know of are vvvv gamma where the recent update basically makes it a .NET language (although LabVIEW also has .NET integration) and Pure Data. Other tools are Simulink, TouchDesigner, Max/MSP, and Grasshopper for Rhino. After that, it drops off pretty rapidly to a collection of barely used or even known about tools pr highly specialized node-based tools.

auxym 5y ago
Another example is ncode Glyohworks, which was used by a very large company I used to work for, for test data post-processing.

deleted 5y ago

[deleted]

DonHopkins 5y ago

If not a "large number", then more like a "huge number". Even the single application Blender itself has several different visual node based programming systems (most but not all built on top of the same framework, and applied to different kinds of programming), for shader programming, CPU image processing, video compositing, lighting, animation and constraints, particle systems, physics simulations, procedural mesh generation, and the Blender Foundation and third parties are developing even more, like procedural city generation: Procedural city generation: https://www.youtube.com/watch?v=jb_jwsyfQc4&ab_channel=derbender https://www.youtube.com/watch?v=jb_jwsyfQc4&ab_channel=derbe... Everything nodes: https://code.blender.org/2020/12/everything-nodes-and-the-scattered-stone/ https://code.blender.org/2020/12/everything-nodes-and-the-sc... Nodes Workshop - 22 - 25 June 2021 https://devtalk.blender.org/t/nodes-workshop-22-25-june-2021/19321 https://devtalk.blender.org/t/nodes-workshop-22-25-june-2021... >“It is like compositor but for physics”. The complete beginners guide to Blender nodes, Eevee, Cycles and PBR: https://artisticrender.com/the-complete-beginners-guide-to-blender-nodes-eevee-cycles-and-pbr/ https://artisticrender.com/the-complete-beginners-guide-to-b... >Blender has a few nodes systems. The first and obvious one is Blenders shading system for Cycles and Eevee. This is the node system that we will focus on in this article. >But we also have nodes for compositing, lighting and textures, even if the use case and future for texture nodes are uncertain at this point. >We can also extend Blender with other node systems through add-ons. The most well-known is probably animation nodes that come bundled with Blender. >There are also other node systems available for Blender. AMD ProRender for example, a third-party render engine that has its own shader node system. Another example is Luxrender. There is also mTree for generating trees with nodes and Sverchok that can manipulate all kinds of data with nodes. Reposting this from a few years ago: https://news.ycombinator.com/item?id=18496880 https://news.ycombinator.com/item?id=18496880 There's so much interesting prior work! I really enjoyed this paper “A Taxonomy of Simulation Software: A work in progress” from Learning Technology Review by Kurt Schmucker at Apple. It covered many of my favorite systems. http://donhopkins.com/home/documents/taxonomy.pdf http://donhopkins.com/home/documents/taxonomy.pdf It reminds me of the much more modern an comprehensive "Gadget Background Survey" that Chaim Gingold did at HARC, which includes Alan Kay's favorites, Rockey’s Boots and Robot Odyssey, and Chaim's amazing SimCity Reverse Diagrams and lots of great stuff I’d never seen before: http://chaim.io/download/Gingold%20(2017)%20Gadget%20(1)%20Survey.pdf http://chaim.io/download/Gingold%20(2017)%20Gadget%20(1)%20S... I've also been greatly inspired by the systems described in the classic books “Visual Programming” by Nan C Shu, and “Watch What I Do: Programming by Demonstration” edited by Alan Cypher. https://archive.org/details/visualprogrammin00shu_2pf https://archive.org/details/visualprogrammin00shu_2pf https://archive.org/details/watchwhatido00alle https://archive.org/details/watchwhatido00alle Brad Myers wrote several articles in that book about his work on PERIDOT and GARNET, and he also developed C32: C32: CMU's Clever and Compelling Contribution to Computer Science in CommonLisp which is Customizable and Characterized by a Complete Coverage of Code and Contains a Cornucopia of Creative Constructs, because it Can Create Complex, Correct Constraints that are Constructed Clearly and Concretely, and Communicated using Columns of Cells, that are Constantly Calculated so they Change Continuously, and Cancel Confusion http://www.cs.cmu.edu/~bam/acronyms.html http://www.cs.cmu.edu/~bam/acronyms.html Also, here's an interesting paper about Fabrik: https://donhopkins.com/home/Fabrik%20PE%20paper.pdf https://donhopkins.com/home/Fabrik%20PE%20paper.pdf Danny Ingalls, one of the developers of Fabrik at Apple, explains: "Probably the biggest difference between Fabrik and other wiring languages was that it obeyed modular time. There were no loops, only blocks in which time was instant, although a block might ’tick’ many times in its enclosing context. This meant that it was real data flow and could be compiled to normal languages like Smalltalk (and Pascal for Apple at the time). Although it also behaved bidirectionally (e.g. temp converter), a bidirectional diagram was really only a shorthand for two diagrams with different sources (this extended to multidirectionality as well)"

DonHopkins 5y ago

Also, spreadsheets are certainly one of the most popular, widely used, easily accessible, and important visual programming languages. It's not an understatement to say that the economy would grind to a halt and civilization as we know it would collapse if spreadsheets suddenly disappeared tomorrow. The article quoted one of my earlier posts on that subject, but I've written more about spreadsheets as visual programming, and cited Brad Myer's work and articles about visual programming languages, and there's more in the HN discussion of his classic 1989 paper "Visual Programming, Programming by Example, and Program Visualization; A Taxonomy," Proceedings SIGCHI '86: Human Factors in Computing Systems. Boston, MA. April 13-17, 1986. pp. 59-66: https://news.ycombinator.com/item?id=26645253 https://news.ycombinator.com/item?id=26645253 DonHopkins 3 months ago | on: Spreadsheet is a software development paradigm Spreadsheet certainly are visual programming languages: by any measure, by far one of the most common most widely used types of visual programming languages in the world. HN discussion: https://news.ycombinator.com/item?id=26057530 https://news.ycombinator.com/item?id=26057530 Taxonomies of Visual Programming (1990) [pdf] (cmu.edu) https://www.cs.cmu.edu/~bam/papers/VLtax2-jvlc-1990.pdf https://www.cs.cmu.edu/~bam/papers/VLtax2-jvlc-1990.pdf https://news.ycombinator.com/item?id=26061576 https://news.ycombinator.com/item?id=26061576 Brad Myers' paper answers the age-old argument about whether or not spreadsheets are visual programming languages! https://news.ycombinator.com/item?id=20425821 https://news.ycombinator.com/item?id=20425821 >DonHopkins on July 13, 2019 | on: I was wrong about spreadsheets (2017) >Google sheets (and other google docs) can be programmed in "serverless" JavaScript that runs in the cloud somewhere. It's hellishly slow making sheets API calls, though. Feels like some kind of remote procedure call. (Slower than driving Excel via OLE Automation even, and that's saying something!) Then it times out on a wall clock (not cpu time) limit, and breaks if you take too long. >A CS grad student friend of mine was in a programming language class, and the instructor was lecturing about visual programming languages, and claimed that there weren't any widely used visual programming languages. (This was in the late 80's, but some people are still under the same impression.) >He raised his hand and pointed out that spreadsheets qualified as visual programming languages, and were pretty darn common. >They're quite visual and popular because of their 2D spatial nature, relative and absolute 2D addressing modes, declarative functions and constraints, visual presentation of live directly manipulatable data, fonts, text attributes, background and foreground colors, lines, patterns, etc. Some even support procedural scripting languages whose statements are written in columns of cells. >Maybe "real programmers" would have accepted spreadsheets more readily had Lotus named their product "Lotus 012"? (But then normal people would have hated it!) I Was Wrong About Spreadsheets And I'm Sorry: https://www.reifyworks.com/writing/2017-01-25-i-was-wrong-about-spreadsheets-and-im-sorry https://www.reifyworks.com/writing/2017-01-25-i-was-wrong-ab... HN Discussion: https://news.ycombinator.com/item?id=26668885 https://news.ycombinator.com/item?id=26668885 Excerpt from "Taxonomies of Visual Programming and Program Visualization", by Brad A Myers, 1990/3/1, Journal of Visual Languages & Computing, Volume 1, Issue 1, pages 97-123: Spreadsheets, such as those in VisiCalc or Lotus 1-2-3, were designed to help nonprogrammers manage finances. Spreadsheets incorporate programming features and can be made to do general purpose calculations [71] and therefore qualify as a very-high level Visual Programming Language. Some of the reasons that spreadsheets are so popular are (from [43] and [1]): 1. the graphics on the screen use familiar, concrete, and visible representation which directly maps to the user's natural model of the data, 2. they are nonmodal and interpretive and therefore provide immediate feedback, 3. they supply aggregate and high-level operations, 4. they avoid the notion of variables (all data is visible), 5. the inner world of computation is suppressed, 6. each cell typically has a single value throughout the computation, 7. they are nondeclarative and typeless, 8. consistency is automatically maintained, and 9. the order of evaluation (flow of control) is entirely derived from the declared cell dependencies. The first point differentiates spreadsheets from many other Visual Programming Languages including flowcharts which are graphical representations derived from textual (linear) languages. With spreadsheets, the original representation in graphical and there is no natural textual language. Action Graphics [41] uses ideas from spreadsheets to try to make it easier to program graphical animations. The 'Forms' system [43] uses a more conventional spreadsheet format, but adds sub-sheets (to provide procedural abstraction) which can have an unbounded size (to handle arbitrary parameters). A different style of system is SIL-ICON [49], which allows the user to construct 'iconic sentences' consisting of graphics arranged in a meaningful two-dimensional fashion, as shown in Figure 5. The SIL-ICON interpreter then parses the picture to determine what it means. The interpreter itself is generated from a description of the legal pictures, in the same way that conventional compilers can be generated from BNF descriptions of the grammar. 10. Conclusions Visual Programming and Program Visualization are interesting areas that show promise for improving the programming process, especially for non-programmers, but more work needs to be done. The success of spreadsheets demonstrates that if we find the appropriate paradigms, graphical techniques can revolutionize the way people interact with computers. DonHopkins 3 months ago [–] https://news.ycombinator.com/item?id=26112751 https://news.ycombinator.com/item?id=26112751 Here's an example of a thread where somebody was fruitlessly trying to argue that a spreadsheet isn't a visual programming language: https://news.ycombinator.com/item?id=22984831 https://news.ycombinator.com/item?id=22984831 >lmm 9 months ago | on: Maybe visual programming is the answer, maybe not >If there was a visual programming language with anywhere near the popularity of Ruby, I'd be willing to consider that maybe the idea has some merit. >DonHopkins 9 months ago [–] >Excel. >I could turn your argument around: If Ruby were anywhere near as popular, widely used, and successful as Excel, I'd be willing to consider that maybe the idea that Ruby is a viable programming language has some merit. >But I won't, because whether or not something is a visual programming language isn't up to a popularity contest. >Can you come up with a plausible definition of visual programming languages that excludes Excel, without being so hopelessly contrived and gerrymandered that it also arbitrarily excludes other visual programming languages? [...] (TL;DR: he couldn't, since he was under the mistaken impression that Excel not programmable, and was less popular than Ruby...) That thread was on an earlier discussion about a blog posting from 2020 about the same 1989 paper by Brad Myers that we're currently discussing. https://news.ycombinator.com/item?id=22978454 https://news.ycombinator.com/item?id=22978454 https://blog.metaobject.com/2020/04/maybe-visual-programming-is-answer.html https://blog.metaobject.com/2020/04/maybe-visual-programming... >Maybe Visual Programming is The Answer. Maybe Not >Whenever discussing problems with programming today and potential solutions, invariably someone will pop up and declare that the problem is obviously the fact that programs are linear text and if only programming were visual, all problems would immediately disappear in some unspecified way. >I understand the attraction of visual programming, particularly for visual thinkers. However, it's not as if this hasn't been tried, with so far very limited success. Brad Myers, in his 1989 paper Taxonomies of Visual Programming gave, along with the titular taxonomy, a non-exhaustive summary of the problems, starting with visual languages in general: [...]