This is a great write up and thank you to the author! Just a note that graphviz dot is not purely Sugiyama’s, there is a paper on the site that details the actual implementation.
Also judging from the final two images (dot vs iongraph for the same large graph) it’s clear that dot is optimized for minimal area where iongraph does not. That’s the trade off. The author claims one is more easy to navigate than the other, I think that’s debatable.
Ultimately I found that visualizing large graphs is rarely helpful in practice; they can certainly look nice for some well defined graphs, but I rarely saw well defined graphs in the wild. Ymmv but maybe some would agree?
Visualizing large graphs is a "tarpit idea," one that initially seems appealing but never succeeds in practice.
Fundamentally, the problem is that visual aids can only really represent a few dozen things before they become as complicated as the thing you were trying to understand in the first place.
And when analyzing messy node diagrams, it’s not just the nodes we’re trying to visualize, but the lines connecting the nodes (the “edges”). We can only visualize a few dozen of those, and that typically means we can visualize only a handful of nodes at a time.
Visualization only works in trivial examples where you don’t need it; it fails in complex environments where you need it the most.
This is my problem with node based editors, the one I am most familiar with being blenders shader editor. I mean, sure, I guess it represents the internal structure. But it always feels so messy. Sometimes I wish blender would just let me work with a netlist.
There's a threshold, of both user ability and scale of 'problem'
I mostly agree with you dfabulich - the repeated efforts to create node/pipeline tools "visual programming languages" are not built for us, and feel redundant.
But I took issue with "where you don't need it" as this is very much dependent on who "you" is.
I would go further. The fundamental problem is the idea that there is a fundamentally correct representation of something. This actually goes further than even the visualization of the graph. Symbolic representations have the same trap.
I agree that we haven’t gained much yet from looking at large graphs. Usually we can reduce any problem of interest to something small. Still, Graphviz produces very ugly results even for small graphs, whereas this is where iongraph shines.
To be clear, what I think makes the latter graph more readable is particularly that the wires are easier to follow. Yes, it’s subjective, but backed up by my own personal experience. Long term I think we can add more interactive features to help us in such cases, e.g. search and dimming irrelevant wires.
I confess I found the graphs GraphViz made for me in https://taeric.github.io/many_sums.html oddly pretty. :D
"Ultimately I found that visualizing large graphs is rarely helpful in practice; they can certainly look nice for some well defined graphs, but I rarely saw well defined graphs in the wild."
Yes, I'm with you: https://jerf.org/iri/post/2025/on_layers_and_boxes_and_lines...
Since writing that I'm finding my frustration at the inability of diagrams to link out or be linked into is growing. In hindsight it seems a super obvious way of using diagrams in a useful manner and nothing supports it worth a crap, even things that really ought to like Mermaid (which permits out links in text but holds it at arm's length (requiring you to set the diagram to "unsafe"[1]) and as near I can tell in a quick search never mentions this as a thing you can do in its docs, and still has no particular support I can find for linking in to a graph). This has turned into a "can't unsee" for me.
(Obviously I have not used every diagramming solution ever, so maybe there is something out there that supports linking in and/or out, and I'd love to hear about it... however, bear in mind I'm looking for what you might call "first class" support, that is, a feature clearly considered important in the design phase of the project, not the sort of accidental-combination-of-features accidental support that Mermaid half has, if you flip some obscure settings to "lower security" somewhere.)
[1]: https://stackoverflow.com/questions/41960529/how-to-add-a-li...
> There are three basic types of “boxes and lines” (as I derisively refer to them) diagrams:
the point of a boxes-and-lines diagram is to express relationships between components at a single layer/level of abstraction
the best metric for the "quality" of a diagram isn't the number of boxes, rather it's the number of edge-crossings, where >0 is a pretty reliable signal that either (a) the diagram is trying to show too much, or (b) the architecture is sub-optimal
any non-trivial system will always require multiple boxes-and-lines diagrams to be accurately described, one per abstraction-layer
and not really sure that linking between diagram and code is a core requirement, diagrams will generally include identifiers that are unambiguously grep-able, i guess...
Enterprise architect ($$) had that buried in the gui, and wondered for long if obsidian canvas could do the same, reports wanted.
Yep, agreed. CMake does deps graphviz (been there), that is better than nothing. But big diagrams need support for exploding subdiagrams and going back.