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.
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.