After reading about this and the methodologies many years ago I implemented many of the precepts into my practice at the time (visual programming using a variety of workflow tools) and it really helped to prevent sprawl that is common with drag and drop workflow interfaces. It helps to enforce that discipline of not straying too far away from the desired path and handling exceptions. If it strays too far to the right then you know you need to look at things again and refactor. Worth reading.
How different is something like this to say, a Jira workflow?
I know there must be many like this but I think it might be particularly robust since it helped power the Buran launch and landing - which by all accounts was a bit of a miracle it all worked so well at first go.
Oh apologies, I thought submissions here were akin to Reddit where it flags you if the same link has been submitted before. I'd Googled Drakon too without finding much discussion on it, but it didn't occur to me to search HN.
These links are just to help people interested in reading additional material and HN commentary - reposts are fine after a year, give or take and it's been more than a year since DRAKON's last.
Some topics are evergreen in part because their core principles ideas are deeply interesting and unique. In part because over time nobody can keep up with everything on HN and because there is a steady influx of new users by design. HN’s “Endless September” is a feature not a bug.
Drakon can be new to you, still intellectually interesting to many people who have seen it before, and make people with a deep affinity for Drakon feel less alone.
Please don't apologize, you got it exactly right! Just to add to what pvg and brudgers have pointed out: reposts are welcome on HN (especially after a year or so - https://news.ycombinator.com/newsfaq.html) and the "Related" links are just to point curious readers in related directions.
I hope you'll definitely continue to post things you find interesting to HN.
I've used the (free) https://drakonhub.com service to create Drakon diagrams, and I've been able to express some pretty sophisticated workflows in a clear, intuitive way.
One of the things I love about it is that it is orderly by design. You've probably seen those scary flowcharts where arrows are pointing willy-nilly, criss-crossing each other, and there's very little cohesion. Drakon charts help avoid that by being relatively prescriptive about _where_ diagram components are placed. For instance, the happy path should form a skewer shape.
The "Diagramming is different with DrakonHub" section of https://drakonhub.com shows you the difference well.
I use DRAKON, or a loose form of it, when I draw diagrams. I like to use a square action icon saying "GOTO <title>", where title is a rounded title icon that names a process or procedure. It's not perfect.
Interesting point about the recursion, that’s an issue. I think the reason is that it has aerospace heritage, I think explicit iteration control is important there. Having no good way to represent recursion is limiting for general purpose though.
I feel like the degenerate case is the happy path for basically any sorting algorithm: the computer doesn't need to do work. That'd make the leftmost skewer in the Wikipedia version of DRAKON quicksort perfectly fine.
As far as recursion is concerned, consider that DRAKON has exactly the expressiveness of assembly language. For environments where modified condition/decision coverage[0] is important (where analysis of branches at the object code level is commonplace), recursion is very likely undesirable, so not having a good way to express it is probably more a feature than a bug.
The only seemingly verifiable claim I can find to DRAKON's lineage in aerospace has to do with the Fregat upper stage[1] (though, I don't read Russian beyond an elementary school level, so I don't know what is actually said here), but given what I know of DO-178B and applicable NASA standards for safety-critical systems, it'd make sense to have DRAKON as part of the tooling.
> The only seemingly verifiable claim I can find to DRAKON's lineage in aerospace
I've been extremely annoyed by DRAKON cultists since 2005 (no, I'm not joking). They were basically claiming: "We have a tooling so powerful that it's used to produce ultra-reliable software for spacecraft, including Buran". When asked to show it, they replied that it's all super-secret. "Buran" is a Russian "Space Shuttle", btw.
Back then, my parents were still working in a factory that produced some of the "Buran" components. So I asked them to try to get me in touch with software developers who might have worked on anything related to "Buran". They got me in touch with a couple of developers responsible for parts of software in the ground monitoring system, but nobody heard anything about DRAKON. So it might have been used somewhere, but it certainly was not super-important.
Since then, DRAKON cultists have not produced anything significant worth of value. The largest project is, probably, the editor. And if you look at it, it's just a bunch of scripts where Drakon doesn't add much clarity.
You can also see that their tooling has zero practicality, it makes any sort of collaboration impossible. Drakon files are binary and can't be diffed sanely.
Forgive me, but I'm left scratching my head. I can't find where I mentioned any of this.
Buran's cancellation predates (given my limited command of Russian, what I think is) the first evidence of DRAKON's production use in the engineering process for avionics systems by almost a decade. Nowhere did I bring up that particular orbiter.
I'm also unsure where I wrote that DRAKON by itself is machine consumable. I'm only familiar with it as a pattern language for drawing diagrams, and that's the extent of my experience with it.
> I'm also unsure where I wrote that DRAKON by itself is machine consumable. I'm only familiar with it as a pattern language for drawing diagrams, and that's the extent of my experience with it.
The cultists claim that it IS a machine language. I don't mind it as a documentation language for simple algorithms, but it's not what they claim.
"The cultists claim that it IS a machine language." Cultists? I'm still left scratching my head as to how this is relevant to my comment.
I wrote about the Fregat upper stage, DRAKON's expressiveness as it relates to recursion with an example of an environment where it might be undesirable, and how the implementation of quicksort shown on Wikipedia is "perfectly fine."
In general, that's an apt description for DRAKON proponents. I interacted with them more than once.
And at this point, it's not even clear if DRAKON charts make sense even for their intended purpose: visual illustrations of simple algorithms. They are better than classic flow charts, but that's mostly because flow charts themselves are hopelessly bad.
Sequence diagrams are better to show interactions between agents, and good old state diagrams are far better structured to visualize state transitions.
I have a tightly-defined universe of discourse here, and you are operating almost completely outside it. Why is your engagement with my comment relevant beyond the connection to DRAKON?
So far, I've seen you write about cultists and Buran and, now, how sequence diagrams and state diagrams are superior. That final bit could admittedly make for interesting conversation, but I've heretofore not seen significant substantiation from you or, hell, any interrogation from you why I even use DRAKON.
Dare I say it, but I feel like I've been the target of your trauma response here, and I don't exactly appreciate it.
> The only seemingly verifiable claim I can find to DRAKON's lineage in aerospace has to do with the Fregat upper stage
It's not verifiable. It's once again co-authored by Drakon's author, and there is no other independent confirmation that any of his claims are true.
On the contrary, the main Drakon discussion forum has multiple threads and discussions trying and failing to even produce the simplest algorithms in Drakon. Much less anything as complex as aerospace requirements.
Drakon's author himself repeatedly fails to answer any questions about how to implement stuff in Drakon, and only answers with pseudo philosophical demagoguery.
The only notable software produced for Drakon is Drakon Editor https://drakon-editor.sourceforge.net/ which is essentially a UML editor with code concatenation
"The only notable software produced ... is ... essentially a UML editor ..." Yes, correct. It's a CASE tool, at least when you have a computer to assist with using it. For harder-hitting software applications, I never took much stock in using it as much more than a better way to diagram out the basic blocks when analyzing the disassembly of something, and I'm usually doing that by hand, without computer assistance.
More broadly, I never expected much from my CASE tools actually generating code for me: the scaffolding was possible, but any sophistication beyond that just never materialized. That ship sailed right around the turn of the millennium, and none of what DRAKON does innovates on that.
"It's not verifiable." Thanks. I always figured that a lot of this chaff was just marketing.
I'm pretty sure 60% of the reason is that it has a cool name :-P. The rest 40% is that at least the part you can easily see, like the comparison between arbitrary spaghetti flowcharts and much more tidy looking DRAKON flowcharts, do look convincing enough. Since 2-3 years now there is even a web-based editor you can play around with, which adds to its shareability.
Of course its mystique association with the USSR space program also helps despite supposedly all being classified (which, if anything, adds to the mystique), but IMO even without those, the cool name would do enough to be shared :-P.
“Why is this on HN?” comments are often a mark of an intellectually interesting story…but not always of course.
As for quicksort in Drakon, if you need quicksort you might have an impedance mismatch between the application and language…might be knee deep in the Turing Tarpit. For example if you are building a real-time system, sorting to the degree quicksort seems like a good idea might suggest a design error.
It is not being shared as a practical tool for people to quicksort their datasets in, it's an experimental tool made by a collapsed empire's defunct space program that seems to attract the interest of hobbyists.
I've enjoyed your critique of Drakon and its proponents so far, but it's very typical for real-time safety-critical systems to have coding standards in place that prohibit recursion; one example is MISRA.
1. There's no evidence that Drakon was used in aerospace industry beyond claims made by a single person: Drakon's author
2. Drakon is pushed as a generic programming tool despite: lacking generic programming facilities, lacking any tooling to actually produce working programs on any platform (except a single hobbyist implementation which is a UML editor with code concatenation: https://drakon-editor.sourceforge.net/drakon-erlang/silh.htm...)
This is such a straw man argument. The original comment claims that if a modelling tool cannot model something as simple as quick-sort, then it's useless in practice. BTW, there's nothing inherently "unsafe" about recursion, but that is completely not the point here.
And for people who like such things, i raise a monster (dreamt on by an European telecommunications committee) that i fairly enjoyed working on 30+ years ago (you enjoy such things when you're young and new to the tech and it was the time when seemingly everybody was excited about diagramming/CASE/etc. :) - CCITT Z.100 SDL - diagramming language originally for the telecommunication systems, kind of an actor model with channels, messages, etc., all formally specified and diagrammed (less practical spiritual cousin of Erlang)
Once you start noticing this design language, you'll see it everywhere.
For instance, in software/hardware audio processing you may load processing blocks. Typically they are arranged left-to-right, but MaxMSP can be top-to-bottom.
DRAKON and Prograph are both visual languages, but otherwise quite different. DRAKON is a flowchart language, showing flow of control, so the order of execution of instructions is specified by the programmer, just like it is in imperative languages. Prograph is a dataflow language, in which instructions can execute as soon as they have all the data they need, so multiple instructions can execute simultaneously (or, on a single processor, in an arbitrary order).
It's pretty interesting that they failed to produce any project of a reasonable size, after literally _decades_ of pushing DRAKON as the best tool ever for "reliable code".
I really like two things about the Drakon docs I've perused:
1) They show how to draw a really clean flowchart, which is a bit of a lost art. I'm not a big fan of flowcharts - IME it seems like the biggest fans are, weirdly, mechanical engineers of a certain age - but hey
2) They show how to do a clean depiction of a state machine in flowchart format, which might come in handy for someone, somewhere
https://drakonhub.com/files/lift.html
Also, as a sort of meta-comment, I noticed that we have two comments from people doing workflow programming (presumably Sharepoint or similar, which I'm 100% sure gets no love or respect, but is super useful if you need it) who found these approaches useful. Workflow is a great use case for graphical programming; in a related vein, a hobby horse of an old friend is that a good graphical environment for devops would change the industry.
The Russian wikipedia page (in auto-translate for me) has a ton more detail and history. I'm not going to a deep dive but I'm also not so sure about the claim that there's no history of aerospace use.
> 2) They show how to do a clean depiction of a state machine in flowchart format, which might come in handy for someone, somewhere https://drakonhub.com/files/lift.html
This example triggers me in particular to no end, with statements like this:
> DRAKON makes automata-based programming practical
That's because I worked with the actual lift controllers. They have TONS of additional states, like "door jammed". Or "elevator takes too long to move between floors", or "failed to transition to high speed from low speed", etc. Literally dozens of states with their own conditions and state machines.
Attempting to display them all on a same diagram is useless. It's far better to represent them cleanly using a multi-level state diagram.
>That's because I worked with the actual lift controllers. They have TONS of additional states, like "door jammed". Or "elevator takes too long to move between floors", or "failed to transition to high speed from low speed", etc. Literally dozens of states with their own conditions and state machines.
I feel your pain, I really do - the next step from oversimplification is "how hard could it be", right? (see my comment here https://news.ycombinator.com/item?id=33263261 where the responses mostly misunderstand me completely) Just about every state machine example that models a simplified embedded application suffers from the same issue, though. It's not unique to Drakon.
I haven't used the full Harel statechart formalism or modeling tools in production, though I expect I eventually will, but I've worked on a project whose state table got about that big before it shipped. Yes, some hierarchy would help a lot. Next time.
No, I wouldn't reach for a flowchart representation of a state machine as a first step in anything I can see myself doing. But even though flowcharts for programming pretty much went out with goto, they're still used to represent things like business processes and manufacturing processes (see Six Sigma, ISO 9001, etc). You will find a surprising number of non-programmer stakeholders that are comfortable with them. So I could see it being handy having the approach shown in that link in my back pocket in a bunch of cross-functional ways.
We really do live in a dark age. Rather than use WYSIWYGs to take advantage of better formatting and layout, all docs are in the crappiest format, Markdown. Rather than design GUIs using a visual language to quickly mock up interfaces, we manually code out command-line tools. We hand-craft text to style an interface, and have to constantly type, ship, view, edit, ship, view, between people with 3 different skillsets, and reinvent the wheel of application design in an application platform designed for document viewing. Rather than develop and adopt open standards for common tasks, everything has a custom interface, and all interfaces require custom integrations, so that nothing ever works with anything unless someone spends 100 hours tying it together with glue code. And rather than compose code visually in a program that validates it in real time (like CAD), we type out line by line, and use a slew of cobbled together tools and basic tests to check if what we typed has any glaring errors.
With the most advanced technology in the history of the world, we've somehow made it more expensive, time-consuming, complicated and buggy to do things we did 20+ years ago.
Text-based workflow has one significant advantage over GUI-based design: diffability. This enables patch-based collaboration: you can easily share your diff with others, review changes line-by-line, resolve conflicts between concurrent modifications, etc.
Personally, I'm much more comfortable working on large documents in LaTeX compared to Word because I can see every change I make and easily revise/revert it. It's too easy to unintentionally hit some shortcut or button in a WYSIWYG editor that subtly changes the document and not realize it until much later, when the undo stack is useless.
I've written quite a bit of powershell to automate stuff in Word in our docs (pdf generation, hyperlink creation and verification, etc), and I second this. It is awful to work with. I'd much rather have latex, markdown or anything else than WYSIWYG.
Word can show you every change you made, as well as tools like Confluence (which is just a version-controlled WYSIWYG Wiki), and let you diff/revert individual changes.
GUI design diffing is pretty simple too: you collapse a flowchart into a DAG and then diff the changes between two copies of the DAG. It's how you troubleshoot DAG-based software bugs. We could also just make a better way to diff GUI changes, if we tried. It's not nuclear physics...
If people started using GUIs more, then they'd find new problems, sure, but then they'd just make solutions for them. There isn't a problem we can't solve. Except for the problem of changing a culture, like a culture of text. Culture is the hardest thing in the universe to change.
A lot of the issue is just that most visual systems don't work with version control.
The rest is that programmers seem to really like the keyboard only UI.
They seem to think of computers as tools that should do exactly what you say, and that the user should have the whole plan in their head, rather than thinking of computers as devices that help you interactively figure out what you want to do.
Dark times were when my manager forced me to use GUI to draw diagrams.
I need to convey my thoughts and design. If A related with B - in my head it's "A related to B", not some bubbles in air with different sizes, arrows pixel left, pixel right. Tools like mermaid.js is what makes it beatiful. I describe the design - an it draws it consistent way.
61 comments
[ 0.23 ms ] story [ 137 ms ] threadI know there must be many like this but I think it might be particularly robust since it helped power the Buran launch and landing - which by all accounts was a bit of a miracle it all worked so well at first go.
The DRAKON Language - https://news.ycombinator.com/item?id=36021495 - May 2023 (38 comments)
Why aren't there more visual programming languages? (An ode to DRAKON) - https://news.ycombinator.com/item?id=35712086 - April 2023 (2 comments)
Ask HN: Anyone knows a flowchart programming better/more modern than DRAKON? - https://news.ycombinator.com/item?id=26137769 - Feb 2021 (1 comment)
The Human Revolution in Understanding Programs [pdf] - https://news.ycombinator.com/item?id=19160248 - Feb 2019 (6 comments)
Drakon: a visual language for specifications from the Russian space program - https://news.ycombinator.com/item?id=12638032 - Oct 2016 (39 comments)
DRAKON – An algorithmic visual programming language - https://news.ycombinator.com/item?id=10100932 - Aug 2015 (48 comments)
Drakon – A visual language for specifications from the Russian space program - https://news.ycombinator.com/item?id=6429283 - Sept 2013 (28 comments)
Use DRAKON to Automatically Generate Code from Flowcharts - https://news.ycombinator.com/item?id=5497668 - April 2013 (1 comment)
Drakon can be new to you, still intellectually interesting to many people who have seen it before, and make people with a deep affinity for Drakon feel less alone.
I hope you'll definitely continue to post things you find interesting to HN.
One of the things I love about it is that it is orderly by design. You've probably seen those scary flowcharts where arrows are pointing willy-nilly, criss-crossing each other, and there's very little cohesion. Drakon charts help avoid that by being relatively prescriptive about _where_ diagram components are placed. For instance, the happy path should form a skewer shape.
The "Diagramming is different with DrakonHub" section of https://drakonhub.com shows you the difference well.
https://github.com/stepan-mitkin/drakonhub
The people pushing this couldn't come up with a way to represent a simple quicksort in it [1]. Why does this keep appearing?
https://forum.drakon.su/viewtopic.php?f=78&t=6124&hilit=quic...
https://upload.wikimedia.org/wikipedia/commons/2/26/Quicksor...
- the main execution path must be the leftmost top-to-bottom "skewer"
- there's no recurse (AFAIR) in Drakon, and there were heavy debates on how to express it properly
It's very doubtful that Drakon has airspace heritage. Any claims to this are made by one single person: the author of the language.
As far as recursion is concerned, consider that DRAKON has exactly the expressiveness of assembly language. For environments where modified condition/decision coverage[0] is important (where analysis of branches at the object code level is commonplace), recursion is very likely undesirable, so not having a good way to express it is probably more a feature than a bug.
The only seemingly verifiable claim I can find to DRAKON's lineage in aerospace has to do with the Fregat upper stage[1] (though, I don't read Russian beyond an elementary school level, so I don't know what is actually said here), but given what I know of DO-178B and applicable NASA standards for safety-critical systems, it'd make sense to have DRAKON as part of the tooling.
0: https://shemesh.larc.nasa.gov/fm/papers/Hayhurst-2001-tm2108...
1: https://www.laspace.ru/upload/iblock/db0/db01beb741f3e811d58...
I've been extremely annoyed by DRAKON cultists since 2005 (no, I'm not joking). They were basically claiming: "We have a tooling so powerful that it's used to produce ultra-reliable software for spacecraft, including Buran". When asked to show it, they replied that it's all super-secret. "Buran" is a Russian "Space Shuttle", btw.
Back then, my parents were still working in a factory that produced some of the "Buran" components. So I asked them to try to get me in touch with software developers who might have worked on anything related to "Buran". They got me in touch with a couple of developers responsible for parts of software in the ground monitoring system, but nobody heard anything about DRAKON. So it might have been used somewhere, but it certainly was not super-important.
Since then, DRAKON cultists have not produced anything significant worth of value. The largest project is, probably, the editor. And if you look at it, it's just a bunch of scripts where Drakon doesn't add much clarity.
You can also see that their tooling has zero practicality, it makes any sort of collaboration impossible. Drakon files are binary and can't be diffed sanely.
Buran's cancellation predates (given my limited command of Russian, what I think is) the first evidence of DRAKON's production use in the engineering process for avionics systems by almost a decade. Nowhere did I bring up that particular orbiter.
I'm also unsure where I wrote that DRAKON by itself is machine consumable. I'm only familiar with it as a pattern language for drawing diagrams, and that's the extent of my experience with it.
You can do machine translation for the article, it's not bad.
It also details claims that it's an actual programming language (what we call now "no code"): https://ru.wikipedia.org/wiki/%D0%94%D0%A0%D0%90%D0%9A%D0%9E....
> I'm also unsure where I wrote that DRAKON by itself is machine consumable. I'm only familiar with it as a pattern language for drawing diagrams, and that's the extent of my experience with it.
The cultists claim that it IS a machine language. I don't mind it as a documentation language for simple algorithms, but it's not what they claim.
I wrote about the Fregat upper stage, DRAKON's expressiveness as it relates to recursion with an example of an environment where it might be undesirable, and how the implementation of quicksort shown on Wikipedia is "perfectly fine."
Where are the cultists there?
And at this point, it's not even clear if DRAKON charts make sense even for their intended purpose: visual illustrations of simple algorithms. They are better than classic flow charts, but that's mostly because flow charts themselves are hopelessly bad.
Sequence diagrams are better to show interactions between agents, and good old state diagrams are far better structured to visualize state transitions.
I have a tightly-defined universe of discourse here, and you are operating almost completely outside it. Why is your engagement with my comment relevant beyond the connection to DRAKON?
So far, I've seen you write about cultists and Buran and, now, how sequence diagrams and state diagrams are superior. That final bit could admittedly make for interesting conversation, but I've heretofore not seen significant substantiation from you or, hell, any interrogation from you why I even use DRAKON.
Dare I say it, but I feel like I've been the target of your trauma response here, and I don't exactly appreciate it.
It's not verifiable. It's once again co-authored by Drakon's author, and there is no other independent confirmation that any of his claims are true.
On the contrary, the main Drakon discussion forum has multiple threads and discussions trying and failing to even produce the simplest algorithms in Drakon. Much less anything as complex as aerospace requirements.
Drakon's author himself repeatedly fails to answer any questions about how to implement stuff in Drakon, and only answers with pseudo philosophical demagoguery.
The only notable software produced for Drakon is Drakon Editor https://drakon-editor.sourceforge.net/ which is essentially a UML editor with code concatenation
More broadly, I never expected much from my CASE tools actually generating code for me: the scaffolding was possible, but any sophistication beyond that just never materialized. That ship sailed right around the turn of the millennium, and none of what DRAKON does innovates on that.
"It's not verifiable." Thanks. I always figured that a lot of this chaff was just marketing.
Of course its mystique association with the USSR space program also helps despite supposedly all being classified (which, if anything, adds to the mystique), but IMO even without those, the cool name would do enough to be shared :-P.
As for quicksort in Drakon, if you need quicksort you might have an impedance mismatch between the application and language…might be knee deep in the Turing Tarpit. For example if you are building a real-time system, sorting to the degree quicksort seems like a good idea might suggest a design error.
No, it was not.
2. Drakon is pushed as a generic programming tool despite: lacking generic programming facilities, lacking any tooling to actually produce working programs on any platform (except a single hobbyist implementation which is a UML editor with code concatenation: https://drakon-editor.sourceforge.net/drakon-erlang/silh.htm...)
https://guminski.net/pg/Z100.pdf
For instance, in software/hardware audio processing you may load processing blocks. Typically they are arranged left-to-right, but MaxMSP can be top-to-bottom.
If you like Prograph, you might be interested in a similar language I've been developing: https://www.fmjlang.co.uk/fmj/tutorials/TOC.html
It's pretty interesting that they failed to produce any project of a reasonable size, after literally _decades_ of pushing DRAKON as the best tool ever for "reliable code".
1) They show how to draw a really clean flowchart, which is a bit of a lost art. I'm not a big fan of flowcharts - IME it seems like the biggest fans are, weirdly, mechanical engineers of a certain age - but hey
2) They show how to do a clean depiction of a state machine in flowchart format, which might come in handy for someone, somewhere https://drakonhub.com/files/lift.html
Also, as a sort of meta-comment, I noticed that we have two comments from people doing workflow programming (presumably Sharepoint or similar, which I'm 100% sure gets no love or respect, but is super useful if you need it) who found these approaches useful. Workflow is a great use case for graphical programming; in a related vein, a hobby horse of an old friend is that a good graphical environment for devops would change the industry.
The Russian wikipedia page (in auto-translate for me) has a ton more detail and history. I'm not going to a deep dive but I'm also not so sure about the claim that there's no history of aerospace use.
This example triggers me in particular to no end, with statements like this:
> DRAKON makes automata-based programming practical
That's because I worked with the actual lift controllers. They have TONS of additional states, like "door jammed". Or "elevator takes too long to move between floors", or "failed to transition to high speed from low speed", etc. Literally dozens of states with their own conditions and state machines.
Attempting to display them all on a same diagram is useless. It's far better to represent them cleanly using a multi-level state diagram.
I feel your pain, I really do - the next step from oversimplification is "how hard could it be", right? (see my comment here https://news.ycombinator.com/item?id=33263261 where the responses mostly misunderstand me completely) Just about every state machine example that models a simplified embedded application suffers from the same issue, though. It's not unique to Drakon.
I haven't used the full Harel statechart formalism or modeling tools in production, though I expect I eventually will, but I've worked on a project whose state table got about that big before it shipped. Yes, some hierarchy would help a lot. Next time.
No, I wouldn't reach for a flowchart representation of a state machine as a first step in anything I can see myself doing. But even though flowcharts for programming pretty much went out with goto, they're still used to represent things like business processes and manufacturing processes (see Six Sigma, ISO 9001, etc). You will find a surprising number of non-programmer stakeholders that are comfortable with them. So I could see it being handy having the approach shown in that link in my back pocket in a bunch of cross-functional ways.
https://schematix.com/video/depmap/
With the most advanced technology in the history of the world, we've somehow made it more expensive, time-consuming, complicated and buggy to do things we did 20+ years ago.
Personally, I'm much more comfortable working on large documents in LaTeX compared to Word because I can see every change I make and easily revise/revert it. It's too easy to unintentionally hit some shortcut or button in a WYSIWYG editor that subtly changes the document and not realize it until much later, when the undo stack is useless.
GUI design diffing is pretty simple too: you collapse a flowchart into a DAG and then diff the changes between two copies of the DAG. It's how you troubleshoot DAG-based software bugs. We could also just make a better way to diff GUI changes, if we tried. It's not nuclear physics...
If people started using GUIs more, then they'd find new problems, sure, but then they'd just make solutions for them. There isn't a problem we can't solve. Except for the problem of changing a culture, like a culture of text. Culture is the hardest thing in the universe to change.
The rest is that programmers seem to really like the keyboard only UI.
They seem to think of computers as tools that should do exactly what you say, and that the user should have the whole plan in their head, rather than thinking of computers as devices that help you interactively figure out what you want to do.
Dark times were when my manager forced me to use GUI to draw diagrams.
I need to convey my thoughts and design. If A related with B - in my head it's "A related to B", not some bubbles in air with different sizes, arrows pixel left, pixel right. Tools like mermaid.js is what makes it beatiful. I describe the design - an it draws it consistent way.