News for hackers. Stuff that matters.
Re:Maybe visual programming is the answer, maybe not by vlovich123 on Saturday April 25, 2020 @06:05PM (#22981986)
I found the reverse. I had to do a tech debt cleanup of the code and found that doing an abstract diagram made it much easier to map out the interrelation between all the classes which was hard to keep in my head all at once. Also made it easier to communicate to others visually why it was spaghetti & easy to create a diagram about how I'd like to clean it up. I used PlantUML because what a lot of text -> visual things miss is that they don't provide the necessary knobs to tune the level of detail so doing the diagram by hand was a necessity.

There may be multiple ways to look at something - sequence graphs, data flows - and additionally you don't want to capture all the details in the visualization, you want to be able to cut-off the diagrams at choke points where they're not helpful (e.g. I don't care about package X in the code) which is what all visualization packages try to do. This is directly analogous to geographic maps.

Imagine if you viewed the map for a state/province whatever & had the local road network detailed. That map would be unusable & discarded quickly. Diagramming tools need to be able to take text & generate a visualization that you can zoom into/out of & lose/gain the appropriate level of detail necessary, be able to switch between different aspects (like you can with street view vs regular vs satellite, vs topography). I think the reason we don't have equivalent tools for programming is three-fold:

1. There's a lot of popular languages. Maintaining support for parsing & mapping that to the visualization abstraction is going to be a lot of work. Probably manageable though.

2. As engineers we tend to think in either solving the problem or not. No visualization is going to be good as a hand-drawn diagram in the moment nor is it probably good enough (at least the first version) as a vehicle for making the modification.

3. There's lot of type erasure/dynamism that's impossible to capture in code analysis (e.g. type-erased callbacks like `std::function`, `std::any`). That makes the visualization incorrect or cause it to fail prematurely.

Re:Maybe visual programming is the answer, maybe not by DylanDmitri on Saturday April 25, 2020 @08:06PM (#22982844)
Agree with you here. When working on more complex problems, I keep a hand-drawn diagram of the relevant code next to my keyboard. Often I'll spend a day sketching out 5 or 6 rough drafts before I arrive at an accurate understand of both the existing code how and how to portray it visually.