We need visual programming. No, not like that

Original Article ↗ Hacker News Discussion ↗

Limits of general-purpose visual programming

  • Many argue that mapping complex, non-planar program graphs into 2D (or even 3D) spaces leads to “spaghetti” diagrams that don’t scale.
  • Text is seen as “1D with names” and symbolic references; diagrams often replace names with wires, creating clutter and overloading visual memory.
  • Visual tools frequently obscure control flow and time. Sequential execution, state changes, and concurrency are often clearer in text.
  • Several people report professional experience with visual-only systems (e.g., integration platforms, graphical UML tools) that became harder to maintain than text, especially as complexity grew.

Where visual approaches work well

  • Strong support for domain-specific, mostly dataflow or signal-flow systems: shaders, audio/SDR graphs, 3D/material nodes, PLC ladder/FBD/SFC, Simulink, Grasshopper, Max/MSP, Unreal Blueprints (to a point).
  • Visual state machines, sequence/swimlane diagrams, and timing diagrams are widely valued for understanding protocols, concurrency, and control systems.
  • In education, Scratch and similar block languages are seen as successful on-ramps, not long-term replacements.

Visualizations of code vs. visual programming

  • Many distinguish “programming via diagrams” (generally disliked) from “diagrams generated from or tightly linked to code” (strongly desired).
  • Examples wanted: codebase architecture maps, call graphs, memory layout and cache-fit views, dependency and deployment diagrams, and runtime traces.
  • Several emphasize diagrams as executable specifications or as inputs to code generation and formal verification, but with the underlying declarative source as the main truth.

Tooling, collaboration, and version control

  • Text wins on search, refactoring, diffs/merges, and integrating with existing tooling; visual systems often lack robust version control and diffing.
  • Visual tools that hide parameters in dialogs are criticized as unsearchable and opaque to new maintainers.
  • Some note that abstraction and modularity matter more than representation; many bad visual systems encourage dumping logic into one giant graph.

Alternative directions

  • Proposals include: richer “2D text” and symbolic notations, stronger type systems and static analysis, moldable development environments, and hybrid visual–text systems.
  • AI is expected by some to make “diagram → code” translation easier, possibly outcompeting bespoke visual languages.