We don’t want to program visually, we want to think visually, observe the state, and interact with large parts of the program. UI should give us clues and hints or help where it can, but not be the main interaction point as long as we operate it with a mouse.

HN discussion https://news.ycombinator.com/item?id=22978454

HN discussion is pretty good

I think that visually programming can be a solution for programming on "application level". The deeper stuff can be coded inside plugins. The underlaying format can be a graph stored in json format which can be read and processed in a lot of languages. An advantage of a visual programming environment is also that it can serve as part of the documentation needed for a project

It doesn't really matter what grizzled veterans think about text vs. visual programming; the newbies have spoken, and for a generation brought up on video games, they insist that a more graphical way of programming be offered. So we gotta build it, because that is what the customers (i.e. new programmers) demand. There are about 100 million people learning to program now. Enormous competition going on to build the tools acceptable to this new generation.

I have always wondered if visual vs textual programming is a fashion, a matter of personal preference, or a domain-dependent result of satisficing. Did anyone explore this question? I see mainly people for who visual programming is evidently the way to go, and people who don't care much about it (myself included).

I don't see how visual studio code with all the popups, squiggly lines, annotations on the line number, code overview on the right and autocomplete is just "plain text" programming. there's a spectrum between 70's text and visual, and we haven't explored much of it.

Visual studio code is offcourse a great tool for programming (I love it and use it daily) but not "visual programming" I think. Although it has lots of visual helpers. For me visually programming is visually connecting nodes that represent plugins/variables or can call a "sub-flow" (a function in normal programming), but you still need code to wire it up and provide additional functionality depending on the application (if you write a webapp server flow this could be the connection with the webserver to handle http endpoints in the visual environment for example)

This comment about Luna/Enso was useful: https://lobste.rs/s/9t0pjr/maybe_visual_programming_is_answer_maybe#c_admgsr

Visual programming for visual components. Find appropriate metaphors for other types of components.

A great discussion on on visual programming is found on one of Harel's statecharts papers. He introduces the idea of topology being more fundamental than geometry

I think it best to avoid using vague terms like topology and geometry. The nested expression f(g(h(j(k)))) can be represented in some notations as a sequence of chained operations like j(k) | h | g | f, so what was inside becomes a linear flow. Conceptually you are taking the output of a subprocedure and sending onwards to another subprocedure. Is this topology or geometry? in the classic sense of the words neither. And if some of these processes operate in parallel, then how do you notate that? Mathematics which is thousands of years old evolved from single values and calculations, and a notation that matched that, and there is very little in math history to help us when we encounter synchronized parallel processes. Really its a new offshoot of discrete math we are exploring here, and a new notation needs to be invented, because all the unicode symbols that we already have are fairly useless! I know i sifted through the 1000 of them, hoping to find some good stuff, but they mostly render poorly because typographically the graphic artists not knowing any math, designed them to be the same EM width as regular letters, making them mostly useless. Don't get me started on the problems with TeX. The inability of the regular structures of the past, most notably the n-tuple and the matrix, were insufficiently general for my needs, hence the graph database inside Beads language, which subsumes n-tuples, matrices, and also eliminates the relational database, which i loathe.

Topology and Geometry are pretty well defined terms... when talking about visual programming the questions on the geometry of the objects presented on screen are front and center, and I think the main objection of ppl is that the resulting programs are hard to follow and understand because they become a tangle of nodes and arcs between them

My point was that much of math, especially topology, is extremely abstract, and super high abstraction is actually the opposite of what visual programming is trying to do, which is make things easier to understand. State transition diagrams as shown in the Harel notes are actually much harder to understand than some purely textual finite state transition syntaxes. The more wires you have the worse the graphical form evolves into a hairball. That's why dependency charts of programs are often useless; above a certain crosslink percentage you get a hairball again, which provides near zero insights beyond the fact that you have made a mess of your program. I studied many abstract mathematics branches hoping to find some great unused branch, and unfortunately what i found is that Mathematicians in general are so unconcerned with practical things that they go off into outer space, and often spend their time proving that all X is Y, or that there are only 3 solutions to Z, or that if A is true then B cannot be true, or that there are an infinite number of solutions to things. Existence, counting, classifying are their main preoccupations, and in computer programming we know what we want to do exists, and the count is based on the user input data, and classifying things gets us not much, so the intersection with pure mathematics is surprisingly weak.