I have been intrigued by the idea of visual coding tools for many years, but these kind of tools have always disappointed me. They remind me of the system used

I have been intrigued by the idea of visual coding tools for many years, but these kind of tools have always disappointed me. They remind me of the system used to teach small children to program in the programming language Scratch, see [Scratch]. I prefer to "visualize" my code as manipulating a set of logical assertions that characterize the state of the computation, ultimately reaching the point where the state of the computation's properties satisfy the requirements. Somewhat like that explained in [Gries1987] and [Dijkstra1976]. Visual tools are just too coarse to capture the details necessary to ensure correctness or real-life requirements. While UML diagrams sometimes help to make sense of a complex set of OO Class relationships, this is far from how I normally work with the meaning of code in my head while programming. [Scratch] https://en.wikipedia.org/wiki/Scratch_(programming_language) https://en.wikipedia.org/wiki/Scratch_(programming_language) [Gries1987] https://www.amazon.com/Science-Programming-Monographs-Computer/dp/0387964800 https://www.amazon.com/Science-Programming-Monographs-Comput... [Dijkstra1976] https://www.amazon.com/Discipline-Programming-Edsger-W-Dijkstra/dp/013215871X/ref=sr_1_4?keywords=Edsger+Dijkstra&qid=1642528263&s=books&sr=1-4 https://www.amazon.com/Discipline-Programming-Edsger-W-Dijks...