Comment by thesuperbigfrog | Hacker News Reader

Comment by thesuperbigfrog | Hacker News Reader

Parent Full thread

thesuperbigfrog

>> visual programming remains an entirely unexplored area

Visual programming languages have been around since at least the 1970s:

https://en.wikipedia.org/wiki/Visual_programming_language

Several are used real-world production cases:

https://en.wikipedia.org/wiki/LabVIEW

https://en.wikipedia.org/wiki/Simulink

https://en.wikipedia.org/wiki/Pipeline_Pilot

https://en.wikipedia.org/wiki/IBM_Cognos_Analytics

While visual programming systems work better for some use cases, they are usually less agile versus text-based systems for several generalized programming tasks: 1) difference comparisons ("diffs"), 2) version control, 3) code search, and 4) code input (Most visual systems require a mouse and careful placement of connectors).

Visual programming systems tend to excel for domain-specific tasks carried out by non-technical or semi-technical users, but for generalized programming, text-based programming systems are more popular for highly technical software developers.

Another problem with visual programming is it forces your program to be planar, or at least nearly planar with some crossovers.

In my experience real code can't be represented legibly on a 2D plane. "Generate code map" features of IDEs usually produce incomprehensible graphs, when you try them on actual codebases.

I never tried CodeSee before it shut down, was it any better?

What is code in a text editor if not a legible 2D planar representation of the "real code"? The real difference between text and a graph of definition-use edges and nodes is that the text representation does not have any intrinsic information on the real code's structure and does not display definition-use edges - at least by default. Most code editors provide some way (via LSP/etc) to display the edges however - usually as a list of the other end of the edge in a dialog/window/similar separate from the code. Given that some textual representation (e.g. variable names) of source and target is possible, a graph-displaying editor can just "abbreviate" an edge (or: make it implicit) by using the other end of the edge. If a graph editor makes all edges implicit by a certain strategy of using names/whitespace/parentheses/etc, the result would be a text representation a text editor displays. The main issue is not in difference of display, but in the mode of editing: a text editor allows much more partial input that violates the structure a graph is expected to have: malformed definitions of programming constructs that are neither a node nor an edge in the graph. A graph editor must either allow such partial input in some way (e.g. enter temporary textual representation, transform into group) or use a different input model that doesn't allow such unrepresentable input, e.g. using mostly mouse, or an editing keyboard language like Vim's objects & verbs. On the other hand a text editor requires you to agree on a formatting style with your colleagues and running autoformatters, looking past useless formatty diffs in code review, fixing syntax errors, dangling else,...

i think the parent meant "planar" in the graph sense, that is, capable of being drawn in a plane with edges not crossing each other.

And text forces you to be linear. It’s no coincidence that everything asynchronous is treated as a minefield of potential race conditions and ephemeral bugs.

“Real code” allows you to hide the mess behind imports (I think everyone had experience of dealing with accidentally circular imports at least once in their career) and abstractions. But once you put your code as a graph on a 2D plane, you realise what kind of horror you are dealing with. And sometimes even this trick doesn’t work: For example, it’s hard to abstract away the states and transitions of a finite state machine; so while they may look fine on a diagram, they often look like a mess of spaghetti as code.

Or if you do functional Scheme Bricks is perfect visual programming language for scheme/lisp

https://github.com/nebogeo/scheme-bricks

Text vs visual programming is a topic that comes round regularly. I've tried to write summary of why both have their place here:

https://successfulsoftware.net/2024/01/16/visual-vs-text-bas...

It agrees with quite a few of the points you make above.

There are also the three graphical PLC languages standardized by the IEC - Ladder, Function Block Diagram, and Sequenced Function Chart.

They're used everywhere - anywhere you see a shiny metal cabinet with conduit running in and out, there's a chance there's a PLC plugging away in there.

Ladder dates back to the 70s and I'm willing to bet is the most used graphical language in existence. It looks like the relay diagrams that electricians use.

I used LabVIEW for a couple of years. The big issue for me was ergonomics. Coding was physically laborious, and I went home with splitting eyestrain headaches. It occurred to me at the time that a dataflow programming language could support either text or graphical input, depending on the user's ergonomic preferences. I have the same problem with CAD.

If you count flowcharts (which one should, IMO), it has been around older than any text programming languages even.

Reply on news.ycombinator.com