wow putting the summary first is cool. now i can just copy it here! but wait… that’s not thinking.
Summary
Most visual programming environments fail to get any usage. Why? They try to replace code syntax and business logic but developers never try to visualize that. Instead, developers visualize state transitions, memory layouts, or network requests.
In my opinion, those working on visual programming would be more likely to succeed if they started with aspects of software that developers already visualize.note this is not visual programming for artistic/creative purposes, so not cellpond/screenpond/…todepond. this is talking about visual programming for developers.
firstly the classic reason given is “so its less scary for inexperienced folk” but like, excel spreadsheets formulae are craaazzzy scary and also the most popular programming language in the world! (that’s a good factoid)
developers don’t try to visualise ‘if else for’ stuff, they try to visualise things that are important, implicit, and hard to understand. stuff like memory access!
some examples: - visualising an overall codebase - visualising memory layout - network shapes - asyncio stuff - transition diagrams for state machines
some viz techniques are already well integrated: - dom element inspector view - flamegraphs in profilers - sql tables diagrams(?? idk what this is)
visualising the overall codebase you can do in some interesting ways: - a good visual dependency navigator - one of those wintreedisk programs but for the project - a ‘burndown graph’ which shows how long contributed code lasts before being replaced. used to see what the ‘core’ of the project is and what was added when and so on.
network topology diagrams are really important and really good. when i present my work, i should use some diagrams.
memory layout diagrams, very useful. yes. for pointers and such. learnrustlearnrust.
this post likes to ask if we can generate such diagrams from sourcecode. that’d be cool! i bet you can.
for some really complex algorithms, the diagram is the source of truth for how it works, more than example code can ever be. because the diagram clearly and unambiguously expresses the idea of the algorithm?
what do i think: - i really like this blogpost. - lots of perceptive examples - i personally use diagrams to understand the layout of numpy arrays a lot. or image stacks. i guess that’s an example of doing memory layout kinda. and of course flowcharts. when i was implementing the 10gsar averaging i exclusively used the flowchart, and then referred to the text to check for precise details. but the flowchart was the algorithm. - diagrams are cool!! - it would have been nice for them to explore more creative/alt ways of programming. but at the same time it was interesting seeing how ‘visual programming’ could be applied to things developers actually do!