We need visual programming. No, not like that
Calls for “visual programming” often conflate two very different needs: using diagrams to understand complex software, and actually replacing text code with graphical tools. Commenters argue that fully visual general-purpose languages don’t scale, are hard to diff, search and debug, and tend to devolve into unmanageable node graphs, while visualizations of existing code (state machines, dataflows, call graphs, memory layouts, deployment diagrams) are extremely valuable for comprehension, debugging, teaching and domain-specific tasks like shaders, control systems or PLCs. Many conclude that the most promising path is text-first programming augmented by richer, domain-specific visualizations and tooling, rather than trying to make diagrams the primary source of truth for arbitrary programs.
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.