How do you visualize code?

Re:How do you visualize code? by zby on Tuesday January 18, 2022 @12:48PM (#29982831)

In 'Why we talk' (https://www.amazon.com/Why-We-Talk-Evolutionary-Evolution/dp...) Dessalles arguments that we have two modes of talking - the first one is visual and probabilistic, the second one is topological - that is concerned about zero one questions - like if something is inside or outside of something. The first one is about imagining situations and judging their salience (or improbability). The second is about argumenting - simplifying the information so that you can 'proove' stuff. The point is that visuals are too rich and there can be too many ways to imagine things - so it is hard to convince someone that a particular scene is wrong or right. When you simplify things to the topological level of question if something is inside something or outside - then you can use inference to arrive at some logical conclusions, with steps so obvious that it is hard to argument against them.

Programming is mostly about logic - that is why it is hard to visualise. I think this is the problem with 'visual programming languages' (like https://enso.org/ - which, disclosure, is in my investmet porfolio) - and also here. This is kind of surprising - because we naturally expect the visuals to be as rich as the logic. But we need to carefully think about what is complementary here.

[ Parent | on HN ]

Re:How do you visualize code? by hutzlibu on Tuesday January 18, 2022 @03:22PM (#29985170)

"Programming is mostly about logic - that is why it is hard to visualise"

Maybe I understood it wrong, but I do not see that logic ...

Rather the opposite, since programming is about very strict defined logic - it is possible to visualize it very clearly. The various UML diagramms for example can do a good job with that.

The hard part, is to make tools, that generate the diagrams for you in a meaningful way automatically. Because generating them by hand, by dragging and clicking around somewhat works, but is apparently way less efficient than just writing the code. (and doing both is just double work)

[ Parent | on HN ]

Re:How do you visualize code? by zby on Tuesday January 18, 2022 @04:30PM (#29986168)

The UML diagrams are a good example of the problem I am talking about: they carry too much (unessential) information - you can draw the boxes in too many ways.

[ Parent | on HN ]

Re:How do you visualize code? by hutzlibu on Tuesday January 18, 2022 @04:53PM (#29986518)

Hm, I am still not sure I understand your point:

I mean the UML spec as its whole is quite a mess, sure, which is why it is not so relevant anymore. But very specific defined UML diagramms, like UML class diagramms - carry just the essential information for me. Like class name, member names with types and connections showing me where this class interfaces or inherits from. I really liked that and preferred it much over the same information in code representation.

But doing it by hand was just not worth it for me.

[ Parent | on HN ]

Re:How do you visualize code? by zby on Tuesday January 18, 2022 @05:08PM (#29986720)

Diagrams are visual and need many more bites than the code they are created from. Just compare a gif of a diagram and its description. The additional information is how the boxes look - are they big or small, colors, what font is used, what margins are there, and many more. Describing it I use text and divide the differences into categories - but maybe I should just write that for the visuals you need information for each pixel.

When you interpret the diagrams you map them into a much smaller space of meanings. In that process you throw out a lot of that visual information.

[ Parent | on HN ]

Re:How do you visualize code? by hutzlibu on Tuesday January 18, 2022 @05:27PM (#29986977)

Ah, now I understand what you mean. It is certainly true, that there is additional information in a diagram.

But - most of that information is just visual help to transport the raw information - to enable you to decode the information (which is what this is all about, as decoding code is mental work).

The x y position of a uml class diagram for example, is irrelevant in terms of raw data, but it makes a difference to the brain, of whether one diagram is centered or in some corner. Likewise all the other information, like color etc.

They are simply there to help you understand the main information. So I do not think they carry unessential information. If the color of a diagram helps get the information across - meaning it makes it easier for the reader to understand the main information - than that information might be not essential, but still important. Whether that works, depends of course on the diagrams and tools and how they get used. Again, this is the hard part.

[ Parent | on HN ]

Re:How do you visualize code? by dragonwriter on Tuesday January 18, 2022 @05:14PM (#29986793)

> Diagrams are visual and need many more bites than the code they are created from.

Only if you store them inefficiently.

> Just compare a gif of a diagram and its description.

A bitmap image (GIF or otherwise) is an inefficient way to store a diagram. For a purely semantic diagram, the source it represents minus anything not actually represented in the diagram is sufficient; if you have additional presentational information you need that, too. For a diagram-specific format, something like graphviz or mermaid source is a possible representation.

[ Parent | on HN ]

Re:How do you visualize code? by zby on Wednesday January 19, 2022 @01:35AM (#29990667)

What you are saying is that UML is not really visual but rather a kind of text. This got me thinking. The text I am writing here is also on one level just text - but I see it as a visual representation of black dots on a white background. But I think the point of diagrams is to be really visual and of text to be text.

[ Parent | on HN ]

Re:How do you visualize code? by zppln on Wednesday January 19, 2022 @03:45AM (#29991312)

In my experience, generating documentation from code is a fools errand (unless it's API documentation). The key (and hard part) to documenting existing code is to understand which details emphasize and which ones can be left out. I read documentation in order to more quickly understand a software component than I would by just reading it's code.

[ Parent | on HN ]