I don't have time at present to develop a thesis around this idea, but my conjecture is that if a diagramming formalism is straightforward to express with 2D drawings and serially with declarative code (as JSON or XML or similar), and if it's possible to execute those diagrams with an interpreter, then you've got a winner.
UML is pretty dead, but statecharts and statechart interpreters can be amazing tools for developing reactive systems even if few developers today care that there's a UML specification for statecharts.
Harel, who invented statecharts in the 80s, tried to do something similar for sequence diagrams in the early 2000s, giving them an executable semantics named LSC, but it's little known and I wonder if one of the reasons it hasn't seen much success is that LSC diagrams are much messier to work with compared to statecharts.
quantified•3mo ago
Pictures vs words. Both break down at sufficient scale. The software developed with GraphQL is far more limited than that which was modeled by UML. But UML couldn't really do better than be a caricature of actual programming languages, either.
Sequence diagrams and state charts have stood the test of time, and I can give you a picture of the relationships between 10 different classes on a whiteboard far faster in UML than GraphQL.
michaelsbradley•3mo ago
UML is pretty dead, but statecharts and statechart interpreters can be amazing tools for developing reactive systems even if few developers today care that there's a UML specification for statecharts.
Harel, who invented statecharts in the 80s, tried to do something similar for sequence diagrams in the early 2000s, giving them an executable semantics named LSC, but it's little known and I wonder if one of the reasons it hasn't seen much success is that LSC diagrams are much messier to work with compared to statecharts.