I don't see graphics as a silver bullet, but I do think they're underused or misused. Graphics provide a wider variety of feedback; they let you see graph struc

I don't see graphics as a silver bullet, but I do think they're underused or misused. Graphics provide a wider variety of feedback; they let you see graph structures and summaries of data, and allow connections to be spatially represented. All of which means that they excel at connecting the big chunks of the system that build on top of some model of service provision and protocol definition, but poor at engaging in the "direct dialogue" of imperative or applicative computation. The part that makes people say "it never works" is that we're almost always thinking from an inverted model, where we know how things scale up and down with text, and apply that learned experience to graphical systems. Subsequently, our engineering instinct leads us to put a similar degree of granular agency into graphical coding and allow the standard constructs (looping, branching, subroutines) to appear in it, which massively increases the complexity of the system and brings us away from problem domain thinking. My recommendation now is - figure out a data structure that could be interesting to visually edit. Make a good editor for that. Allow imperative code a runtime model for accessing it. Allow imperative code to be called from it. Then it stands at least some chance of not being a bad wheel reinvention.