|
|
|
|
|
by stcredzero
696 days ago
|
|
Bret Victor might argue visualizing a program is still "drawing dead fish". The power of visual programming is diminished if the programmer aims to produce source-code as the final medium and only use visualization on top of language. I disagree. We frequently break up large systems into chunks like modules, or micro-services, or subsystems. Often, these chunks' relationships are described using diagrams, like flowcharts or state transition diagrams, etc. Furthermore, quite often there are zero direct code references between these chunks. Effectively, we are already organizing large systems in exactly the fashion the op is proposing. Inside each chunk, we just have code. But at a higher level viewpoint, we often have the abstraction described by a diagram. (Which is often maintained manually, separate from the repo.) What exactly are the disadvantages here? |
|
We frequently break up large systems into chunks like modules, or micro-services, or subsystems. Often, these chunks' relationships are documented using diagrams on a high level (like flowcharts or state transition diagrams etc.), but are not executable.
Fixed it for you.