People are (rightly) skeptical of this, but I think the first paragraph has the right idea:
> diagrammatic reasoning in particular, is a formidable tool-set if used the right way. That is, it only seems to work well if based on a solid foundation rooted in mathematics and computer science
Code is formal: the symbols have a nearly-unambiguous interpretation as a running program. If there are to be diagrams they must be formal and systematic in their use of notation.
In particular, the author is right that some control systems and interactions are best thought of as state machines, and statecharts are the traditional tool for reasoning about these.
However, the bitcoin ATM example gif in the middle also shows what the weakness is: that's not a complete diagram! It lacks all the error and early return states, timeouts etc that would be needed in a real system. Admittedly this plagues traditional programming as well - qv. exceptions vs. Go style mandatory error checking.
Trying to do a whole program this way also seems like a bad idea; that's the hell of UML that was briefly a fad (qv Rational Rose). Maybe we can just sprinkle a bit in the right places?
Having the diagram represent "control flow" seems to be an anti-pattern, since it gets bogged down in detail. Either dataflow, event flow or state transition seems to work better.
I sometimes wonder if the right way forward would be something a bit like the old "pic" language: https://www.oreilly.com/library/view/unix-text-processing/97... ; SVG is too complex and too XML to cleanly interleave in a program, but pic might work well.
> diagrammatic reasoning in particular, is a formidable tool-set if used the right way. That is, it only seems to work well if based on a solid foundation rooted in mathematics and computer science
Code is formal: the symbols have a nearly-unambiguous interpretation as a running program. If there are to be diagrams they must be formal and systematic in their use of notation.
In particular, the author is right that some control systems and interactions are best thought of as state machines, and statecharts are the traditional tool for reasoning about these.
However, the bitcoin ATM example gif in the middle also shows what the weakness is: that's not a complete diagram! It lacks all the error and early return states, timeouts etc that would be needed in a real system. Admittedly this plagues traditional programming as well - qv. exceptions vs. Go style mandatory error checking.
Trying to do a whole program this way also seems like a bad idea; that's the hell of UML that was briefly a fad (qv Rational Rose). Maybe we can just sprinkle a bit in the right places?
Having the diagram represent "control flow" seems to be an anti-pattern, since it gets bogged down in detail. Either dataflow, event flow or state transition seems to work better.
I sometimes wonder if the right way forward would be something a bit like the old "pic" language: https://www.oreilly.com/library/view/unix-text-processing/97... ; SVG is too complex and too XML to cleanly interleave in a program, but pic might work well.