I'm going to reply to myself to share some history.
I came up when things like 'structured analysis' and 'Yourdon diagrams' were a thing. I was repeatedly told that if I wasn't doing this I was "hacking" in the pejorative sense.
These diagrams were the worst hack that I've ever seen. There is no language, there is no verification, you can literally draw anything. There were case tools that attempted to balance all your arrow so that all ins had an out, and so on, but it was just a disaster. Hack, hack, hack.
In contrast, in code I could quickly express up an API design. It was concrete, it was testable, it was understandable, and it was a 1-to-1 match to what the eventual code would be. It was wonderfully, powerfully expressive. It wasn't limited to 2D, I could express complicated relationships without someone arguing "these lines cross, move this over there to improve the layout", and other nonsense that had nothing to do with solving the problem.
It was not a language, it didn't have a grammar, and it was untestable. It was extraordinarily limited. You couldn't show that this module is used by 10 different modules in different situations. You could express impossible things. You had no way to analyze it for correctness. Sure, there were case tools that put in things like state diagrams and simulation and such, but it was all just terrible. It was either impossibly constrained, or impossibly free-form.
In contrast, my stubbed API's were an exact representation of my ideas. If I want to test a hypothesis, I'd just implement part of the API, stub out parts that weren't important, and have running proof of my ideas. I was doing a lot of concurrent stuff then, and this was important. Visual depictions were incredibly cumbersome, untestable, and were just terrible, terrible hacks.
I went through more than one project where we spent a tremendous amount of time generating these things, they collapsed under their own weight (you just can't reason well about these things once relationships go past 2D), they'd all get discarded, and then the real design work would begin, in code.
I argue, without proof, that without a language visual types of design will always have these problems. I also argue that it is not incumbent on me to provide that proof. The power of Turing complete languages and math has been proven. A viable alternative needs to prove not only that it is equal to the existing approach, but is better in some important way.
I came up when things like 'structured analysis' and 'Yourdon diagrams' were a thing. I was repeatedly told that if I wasn't doing this I was "hacking" in the pejorative sense.
These diagrams were the worst hack that I've ever seen. There is no language, there is no verification, you can literally draw anything. There were case tools that attempted to balance all your arrow so that all ins had an out, and so on, but it was just a disaster. Hack, hack, hack.
In contrast, in code I could quickly express up an API design. It was concrete, it was testable, it was understandable, and it was a 1-to-1 match to what the eventual code would be. It was wonderfully, powerfully expressive. It wasn't limited to 2D, I could express complicated relationships without someone arguing "these lines cross, move this over there to improve the layout", and other nonsense that had nothing to do with solving the problem.
It was not a language, it didn't have a grammar, and it was untestable. It was extraordinarily limited. You couldn't show that this module is used by 10 different modules in different situations. You could express impossible things. You had no way to analyze it for correctness. Sure, there were case tools that put in things like state diagrams and simulation and such, but it was all just terrible. It was either impossibly constrained, or impossibly free-form.
In contrast, my stubbed API's were an exact representation of my ideas. If I want to test a hypothesis, I'd just implement part of the API, stub out parts that weren't important, and have running proof of my ideas. I was doing a lot of concurrent stuff then, and this was important. Visual depictions were incredibly cumbersome, untestable, and were just terrible, terrible hacks.
I went through more than one project where we spent a tremendous amount of time generating these things, they collapsed under their own weight (you just can't reason well about these things once relationships go past 2D), they'd all get discarded, and then the real design work would begin, in code.
I argue, without proof, that without a language visual types of design will always have these problems. I also argue that it is not incumbent on me to provide that proof. The power of Turing complete languages and math has been proven. A viable alternative needs to prove not only that it is equal to the existing approach, but is better in some important way.