Visual Programming Is Stuck on the Form
Posted4 months agoActive4 months ago
interjectedfuture.comTechstory
calmmixed
Debate
60/100
Visual ProgrammingSoftware DevelopmentUi/ux
Key topics
Visual Programming
Software Development
Ui/ux
The article argues that visual programming is stuck in a paradigm that mimics traditional coding, and the discussion explores alternative approaches and successful examples of visual programming.
Snapshot generated from the HN discussion
Discussion Activity
Moderate engagementFirst comment
3h
Peak period
8
4-6h
Avg / period
3.1
Comment distribution31 data points
Loading chart...
Based on 31 loaded comments
Key moments
- 01Story posted
Sep 13, 2025 at 9:53 PM EDT
4 months ago
Step 01 - 02First comment
Sep 14, 2025 at 1:20 AM EDT
3h after posting
Step 02 - 03Peak activity
8 comments in 4-6h
Hottest window of the conversation
Step 03 - 04Latest activity
Sep 15, 2025 at 3:00 AM EDT
4 months ago
Step 04
Generating AI Summary...
Analyzing up to 500 comments to identify key contributors and discussion patterns
ID: 45236774Type: storyLast synced: 11/20/2025, 12:35:35 PM
Want the full context?
Jump to the original sources
Read the primary article or dive into the live Hacker News thread when you're ready.
Maybe there's an unobvious way to make visual programming actually useful?
Probably quite a few people have wondered that throughout the ages. I know I have.
In the meantime, this AI thing happened, emphasizing even more the use of text/voice as a mode of creative expression.
Erlang-Red is inspired by Node-RED which itself is inspired by flow based programming.
[1] https://github.com/gorenje/erlang-red
Disclaimer: I’m the author of Erlang-Red.
I'd think it would be finding the optimal parameters for an algorithm that is probably better expressed in another language.
Even though they are all Turing complete, any programming paradigm is biased towards solving certain kinds of problems.
It seems "visual programming" is biased towards the computationally irreducable[1]. This is a class of problem very sensitive to initial conditions. The chaotic behavior may eventually settle towards a stable state. So, the image of that stable state then encodes the parameters you'd want to use on the algorithm you wrote in another language.
That's not meant to be harsh. This gets directly to the heart of why we may want to write the same ideas in different ways even if those writings seem logically equivalent. One way is just easier to understand than the other depending on what part of the problem you're trying to tackle. These multiple writings are not redundant, but the facets necessary to more thoroughly explain a problem. In fact, upon closer inspection you'd find that what seems like the same algorithm written two different ways is actually not the same because they are executed differently.
[1]: https://en.wikipedia.org/wiki/Computational_irreducibility
If we really leaned into the visual cortex, maybe we’d get something where zooming out shows the big picture and zooming in shows the gritty details, like Google Maps for code. Until then, node‑and‑wire diagrams are just UML diagrams that decided to cosplay as circuit boards.
I'm not aware of any that were very successful.
That's how KiCAD and other CADs for electronics make PCBs. You will put big parts (that's usually hardware design driven), then you will put smaller parts around it and then you are trying to connect each smaller part with correct signal without crossing each other.
Simulink is getting more expensive every year, and licensing is a huge barrier to open source models.
Edit: basically, we want Dyad (https://juliahub.com/products/dyad) except free.
Killer features that come to mind are:
You can drag and drop asset references instead of relying on textual tokens.
You can build a framework where incorrect code does not fit together, or pins dont connect, or draggables do not allow for blocking. It's a much better feedback to a certain type of person than a textual error.
Then the article seems to go on and on about knowing how to make a great visual programming language despite not producing one.
I've implemented many VPLs in video games and I've used Blueprints extensively. I've probably made all the classic "mistakes" designing VPLs, many of which are mentioned in this article. I don't think I am very good at designing VPLs despite having done it on and off for 30 years.
I think BPs are the best example of a VPL out there at the moment. Certainly in video games. However it still falls short of the ideals of VPLs.
Essentially BPs trick people in to being programmers. They still have to understand the "ways" of programming (for loops, if then, etc). With a little context switch and training they would probably be more productive with a text based interface. So the abstraction BPs provide is very limited.
BPs are a general programming tool used for materials, game play logic, animation trees etc. Because of this there are few, if any, high level abstractions that relieve the user of the burden of programming. Don't get me wrong, this is hard, very hard, so I am not calling anyone out. It requires sitting down with a non-technical person and really understanding how they think and what they need. Turning that in to something that isn't node + wire is hard. The fact that the industry has created technical artists to fill the void says to me that BPs are failing to a certain extent (and TAs can just use text based programming and do in many studios).
Overall I agree that the field of VPLs is stuck at a local minima and the 10x productivity improvement for non programmers is still illusive.
I did a survey of the popular VPL environments last year and found Blender's implementation notable for what it didn't do. It exposes node-and-wire UI elements and the scripting for them in Python; all further details are delegated to each subsystem. So shaders, video, etc. have no relationship within their programming model, just UI similarity.
Add to that the aspect of - why are programming languages always going for plaintext representation - and it's because of the tooling ecosystem. We have a huge investment in text editing and text processing, and in typing on standardized keyboard layouts, on speech-to-text and vice versa, and lately, on text generation language models. We have made that stuff really cheap and fast for everyone, in the same way that when Blender did node-and-wire, they elected to make the paradigm as a whole cheaper to reuse in a customized way, versus investing heavily in one particular implementation and trying to extend it to many scenarios.
I think part of the issue is that we design VPLs without taking any interest in draftsmanship - the traditional core skillset for working with "visual language". Instead we use mouse pointers and touchpads and treat it as a data entry problem that has to be structured right away instead of allowing sloppy syntax.
I think the greatest challenge of VPLs is how they don't have an inherent linear structure, so reading and understanding them for modification requires a nonlinear scan of a node soup. This puts them in the class of tools that struggle to make large programs readable, like Bash or Forth.
https://dev.epicgames.com/documentation/en-us/unreal-engine/...
If you're looking for a gui configuration tool instead of a VPL... those exist too. They exist by being declarative data editors.
StateTree editors, Animation Blueprints, and discrete state machines are some possible examples of visual editors that change app functionality that strip away core programming concepts for simplicity. There's plenty of these floating around but I feel like they "don't count" while simultaneously being exactly what is asked for.
Also important to reflect on this, I think: it’s a dynamic functional programming language with annoyingly weak and limited types, with inconsistent string parsing, and the most obtuse and uninformative error messages, and it still works wonderfully.
DonHopkins on April 2, 2021 | parent | context | favorite | 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.
Taxonomies of Visual Programming (1990) [pdf] (cmu.edu)
https://news.ycombinator.com/item?id=26057530
https://www.cs.cmu.edu/~bam/papers/VLtax2-jvlc-1990.pdf
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
>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-ab...
HN Discussion:
https://news.ycombinator.com/item?id=20417967
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.
https://news.ycombinator.com/item?id=26057530
Taxonomies of Visual Programming (1990) [pdf] (cmu.edu) 107 points by mr_tyzik on Feb 7, 2021 | hide | past | favorite | 49 comments
BradAMyers on Feb 7, 2021 | next [–]
Thanks for your interest in my old article! That version is a draft update of this article: Brad A. Myers. "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.
http://www.cs.cmu.edu/~bam/papers/chi86vltax.pdf
There was a big explosion of weird and wonderful visual programming languages in the 1980s, such as CASE tools, loads of commercial 8 bit game-making systems, HP's early 80s workstations, and dozens of BASIC variants (which weren't very visual, but let you draw things with extreme ease). I wonder if there are any under-explored ideas there.
Tables are super visual (even in forms like CSV).
I thought that I was the only one that understood that the rules for transforming structures are emergent properties of the structure itself.
I'm not an academic, can you point me to where you encountered this idea of emergent notations??
Or anything regarding computational structures and web development. Such a thing seems like alien technology to me right now.
https://cs.brown.edu/~spr/codebubbles/
https://www.doxygen.nl/#diagrams
This is only true if you prefer whimsical metaphor over concise description and cleaning up unexpected behavior instead of precisely defining what you want upfront.
Here there is embrace of beauty and structure emerging from rethought low level expressions, but how does this work with typing, Windows, Mac Foundation Kit or whatever else?
All are using blocks with input and output which are either having predefined function or you can define the block function with a code. Reading these programming schematics is sometimes great to understand the high level of how program is working with input data (left) towards output (right). However the moment you will introduce loops, visual programming will just fall apart like a glass hit by a hammer.
2 more comments available on Hacker News