Diagramming Program Values by Spatial Refinement looks like an interesting tool for visualizing complex data structures.

FWIW: As I read this, I find myself agreeing that this is interesting, but, that it is backwards. Diagrams are definitely useful for expressing various concepts. Instead of finding ways to deal with diagrams via text, though, we should be building "compilers" that use DaS (Diagrams as Syntax) and produce textual code in existing languages from diagrams. I would even say that transmogrifying diagrams is easier than disassembling text and controlling diagram layout from text (and can give proof - it's so easy that even I can do it :-). Additionally, Alan Kay is on record stating that we should be using existing languages as "assembler" for newer languages.

The authors' goal is visualization of data structures, their textual input language is about constraints on the diagrams. How would you define such constraints in diagrams themselves? It can certainly be done, but it's not obvious that it yields a clear advantage.

I strongly agree that diagrams would not be helpful for defining constraints, but, I think that's not the actual first order problem. The problem, IMO, is "visualization of data structures". Data structures should not be written as text in the first place. Economics forced us to use text in the 20th century but that barrier has evaporated. The paper seems to deep dive into the creation of complicated band-aids to paste onto a problem that shouldn't exist in the first place. The paper casually uses the phrase "... Illustrates a common pattern: export the structure to DOT [14] and render it as a diagram. ...". That, to me, is the real problem: the matter-of-fact acceptance of the existence of a much deeper problem - a poor syntactic choice. The textual form of that data structure might be a convenient representation to use for consistency analysis and theorem proving, but, it is not a convenient form for actually thinking about and writing data structures - that's a first order problem as I see it. Solving the diagram-->textualCode problem is fairly easy and doesn't need to involve all of the complication dealt with in the paper. They could have used their highly-trained brain cycles to solve better problems than just allowing us to continue with "we've always done it this way" (Grace Hopper).

Data structures should not be written as text in the first place.

They aren't! With the exception of literals, of course, but most data structures are the result of computations.

That's not what I got from the paper, but you make an interesting point. Looking at the example in the

dd

repo, referred to by the paper, the code looks to me to essentially be assembler, i.e. something that humans shouldn't be forced to write or read (of course, I'm in unfamiliar territory, so I might be missing something crucial). This looks like fodder for a diagrammatic syntax. In addition, I was originally thinking of textual class and textual struct declarations being superseded by diagrammatic syntax (diagram --> [graphml] x [T2T] --> Python)

I agree that the example code looks unpleasant to write. But I do not see the example code as expressing the main idea of the paper. In a real software development context, the ugly equivalent of the example code would be a very small part of the total code. And the inspectable data structures would be computed.