The DRAKON Language(drakonhub.com)
drakonhub.com
The DRAKON Language
https://drakonhub.com/en/drakon
39 comments
Oh this is one of my favourite topics.
This site is like many of the other DRAKON tools written by Stepan Mitkin and is released to the public domain on GitHub [0].
The tool I am most familiar with is the DRAKON editor [1] also created by Mitkin and released to the public domain [2]. I feel in love with DRAKON about 10 years ago and have used it on and off for just writing out flows or some algorithms, I even wrote a optimistic database in Erlang with it some years ago which I found pretty interesting. More recently I have been looking at adding Rust support to the tool, but many of the things I want to do is blocked by various technical debt that have accumulated over the years, and the fact that I have never used TCL before.
[0]: https://github.com/stepan-mitkin/drakonhub
[1]: https://drakon-editor.sourceforge.net/
[2]: https://github.com/stepan-mitkin/drakon_editor
This site is like many of the other DRAKON tools written by Stepan Mitkin and is released to the public domain on GitHub [0].
The tool I am most familiar with is the DRAKON editor [1] also created by Mitkin and released to the public domain [2]. I feel in love with DRAKON about 10 years ago and have used it on and off for just writing out flows or some algorithms, I even wrote a optimistic database in Erlang with it some years ago which I found pretty interesting. More recently I have been looking at adding Rust support to the tool, but many of the things I want to do is blocked by various technical debt that have accumulated over the years, and the fact that I have never used TCL before.
[0]: https://github.com/stepan-mitkin/drakonhub
[1]: https://drakon-editor.sourceforge.net/
[2]: https://github.com/stepan-mitkin/drakon_editor
I've always thought the layouts and conventions of Drakon are simple and clean, and a legitimate improvement on most other systems. But I would prefer to use them as Graphviz renderer, or via another textual interface, than via a custom GUI. I don't think a text UI exists, though.
Yes, ideally a markdown extension for Drakon, like we have one for (a subset of) Graphviz.
I guess it would look very much like
A
#if B
#if D
#if F
G
#else
H
#else
E
#else
C
#endLooking at the github project [1], it seems that the diagrams are serialized in a binary format (drn file), which according to the file command is a sqlite database. They generate Lua?
I suspect a text-based serialization format that works well with diff would go over better.
[1] https://github.com/stepan-mitkin/drakonhub
I suspect a text-based serialization format that works well with diff would go over better.
[1] https://github.com/stepan-mitkin/drakonhub
The drn file format is described here https://drakon-editor.sourceforge.net/file_format.html
The drakon widget by the same author uses a json based serialzation scheme as you can see here https://github.com/stepan-mitkin/drakonwidget/blob/main/js/e...
The drakon widget by the same author uses a json based serialzation scheme as you can see here https://github.com/stepan-mitkin/drakonwidget/blob/main/js/e...
At least from what I can tell, this isn't so much as a language as it is a drag-and-drop tool. I like how it looks but can't seem to find the language spec (as it claims it's a language) or any such examples through some cursory digging of the site.
Does it mean more of a communicative "language" of shapes? I was hoping more for a Graphviz .dot format that would be used to generate such graphs. Mermaid seems to have become the defacto standard in OSS and I really dislike it (even though I've also contributed to it). A modern, sleek alternative like this would be great.
Does it mean more of a communicative "language" of shapes? I was hoping more for a Graphviz .dot format that would be used to generate such graphs. Mermaid seems to have become the defacto standard in OSS and I really dislike it (even though I've also contributed to it). A modern, sleek alternative like this would be great.
DRAKON is an actual language;
https://en.wikipedia.org/wiki/DRAKON?wprov=sfti1
https://en.wikipedia.org/wiki/DRAKON?wprov=sfti1
I didn't know wikipedia had link tracking
https://wikitech.wikimedia.org/wiki/Provenance
https://wikitech.wikimedia.org/wiki/Provenance
A better source for the actual language would be this PDF file [0] or the Wikipedia page [1].
It is a kind of strict flowchart language that only allows you to do it in one way, which may be bad for some, but it helps how fast you can grok it when you understand the simple rules.
The same author have also recently made a JS widget that allows you to embed these diagrams on websites [2].
[0]: https://drakon-editor.sourceforge.net/DRAKON.pdf
[1]: https://en.wikipedia.org/wiki/DRAKON
[2]: https://github.com/stepan-mitkin/drakonwidget
It is a kind of strict flowchart language that only allows you to do it in one way, which may be bad for some, but it helps how fast you can grok it when you understand the simple rules.
The same author have also recently made a JS widget that allows you to embed these diagrams on websites [2].
[0]: https://drakon-editor.sourceforge.net/DRAKON.pdf
[1]: https://en.wikipedia.org/wiki/DRAKON
[2]: https://github.com/stepan-mitkin/drakonwidget
For anyone else who would prefer a local editor, my understanding (after a brief search) is that this is a browser version of https://drakon-editor.sourceforge.net/.
I found it in the AUR on arch. Elsewhere on windows/mac/linux.
I'm not sure if I'll ever use this as an alternative to writing code, but I like the pretty diagrams.
I found it in the AUR on arch. Elsewhere on windows/mac/linux.
I'm not sure if I'll ever use this as an alternative to writing code, but I like the pretty diagrams.
I have a subjective opinion that it is not really a programming language. Rather, it is a language for modeling business logic. I know about its existence more than 10 years, I did not understand many things at once, but over time I began to apply it in my practice of modeling systems. The fact that V. Paronjanov was not able to develop Dragon language to the final language with all the necessary attributes, does not say at all about the unsuccessful...
V. Paronjanov is a genius, but not every genius has a genius team...
That said, the books he has written over the years will leave a fundamental mark on system logic design! I also consider G. Altshuler with his Theory of Invention Problem Solving a worthy genius, after his death he received recognition in the face of experts all over the world.
Can anyone share any practical experience using Drakon for a non-trivial project?
I used it to describe the behavior of an embedded device (like the boot sequence or the failure modes), it worked great since team mates would simply update the diagrams without wondering about the format. Also people non familiar with Drakon could make sense of it. My impression was: it is easy to model well designed systems and hard to draw convoluted interactions. It felt like a feature, a bit like LaTeX, where it is easy to produce a beautiful doc and possible (with some effort) to make an ugly one. That was just my impression: if the diagram is too complex, you probably should simplify the design.
There are no real applications written in Drakon. That's because its authors spend most of the time pontificating about how it's superior to all other programming languages.
Drakon editor is probably the most complicated piece of software written in it: https://github.com/stepan-mitkin/drakon.tech
Drakon editor is probably the most complicated piece of software written in it: https://github.com/stepan-mitkin/drakon.tech
No public applications. Drakon and the CASE software based on it have been used in certain Russian and Ukrainian aerospace and energy industry projects. NPTsAP continued to use it in all their projects after Buran (mostly control systems for upper stages).
I first encountered Drakon around 2008 or so, it was being pushed by complete ignoramuses, and they were trying to force it on school students. With grandiose claims that it's the most transformative approach to designing safe programs, blahblahblah.
I got mad at them, so I started digging.
I spoke with several people who worked on Buran (at that time, my parents were working at a factory that had designed Buran's instrument panel). Nobody there knew about Drakon. They apparently used a mix of Prolog (its Russian dialect, ПРОЛ), low-level assembly, some Modula-2, Fortran, etc.
It's questionable that the Soviet engieers would have been comfortable working with a graphical language, back when many of them still used punch cards to enter programs.
It could have been used in documentation or in specs, because Drakon indeed is a better graphical notation than the regular flow charts.
I got mad at them, so I started digging.
I spoke with several people who worked on Buran (at that time, my parents were working at a factory that had designed Buran's instrument panel). Nobody there knew about Drakon. They apparently used a mix of Prolog (its Russian dialect, ПРОЛ), low-level assembly, some Modula-2, Fortran, etc.
It's questionable that the Soviet engieers would have been comfortable working with a graphical language, back when many of them still used punch cards to enter programs.
It could have been used in documentation or in specs, because Drakon indeed is a better graphical notation than the regular flow charts.
Indeed you're right, I know what you're talking about, and actually briefly worked in contact with the people you're talking about in early 2000s as an intern, until leaving that circus for good. However I also know for a fact that it's been used in at least one organization for a couple live projects as a visual language in a CASE tool (no idea to what extent though). That org had some of the best bullshitters and practitioners of siburda - imitation of intense work - I've ever encountered in a post-soviet world (which had no shortage of those), and the same kind of ignoramuses you allude to.
i found a detailed article on Drakon in Russian [1], they say that development of the Drakon language started in 1986 (that would have been two years before the launch) and that work on the ГРАФИТ-ФЛОКС dev environment was completed in... 1996.
it was used with the Sea Launch program, Fregat - that's a space tug for Soyuz/Zenit, the modernized Proton-M, ДМ-SL-Б - that's a space tug used with the Zenit launcher.
However the article is a bit old, from 2009. It could have been used for later systems.
https://old.computerra.ru/readitorial/418507/
Wikipedia mentions hybrid variants of Drakon - like Drakon-C, here the they would put C code into each of the boxes of the flowchart (each square box would stand for a basic block, and each diamond box a boolean expression?). I think that would make more sense, this way you could actually write some more complex programs and the flowchart would not blow up in complexity.
https://ru.wikipedia.org/wiki/%D0%94%D0%A0%D0%90%D0%9A%D0%9E...
i guess that with Drakon-C a function call would be just a line in the basic block, would make more sense.
it was used with the Sea Launch program, Fregat - that's a space tug for Soyuz/Zenit, the modernized Proton-M, ДМ-SL-Б - that's a space tug used with the Zenit launcher.
However the article is a bit old, from 2009. It could have been used for later systems.
https://old.computerra.ru/readitorial/418507/
Wikipedia mentions hybrid variants of Drakon - like Drakon-C, here the they would put C code into each of the boxes of the flowchart (each square box would stand for a basic block, and each diamond box a boolean expression?). I think that would make more sense, this way you could actually write some more complex programs and the flowchart would not blow up in complexity.
https://ru.wikipedia.org/wiki/%D0%94%D0%A0%D0%90%D0%9A%D0%9E...
i guess that with Drakon-C a function call would be just a line in the basic block, would make more sense.
> However the article is a bit old, from 2009. It could have been used for later systems.
That article is written by the main DRAKON pusher: Владимир Паронджанов (Vladimir Paronjanov), so I'd take it with a grain of sand the size of the Great Salt Lake.
Somehow, all applications of DRAKON happened to be in areas like space and defense, that are heavily protected by the state secrecy laws. So nobody could really confirm it. And that was also an excuse for not having any public tools released.
> Wikipedia mentions hybrid variants of Drakon
The only real programs in DRAKON are written like this. The compiler simply generates the code from the graphical description by joining the sections together.
That article is written by the main DRAKON pusher: Владимир Паронджанов (Vladimir Paronjanov), so I'd take it with a grain of sand the size of the Great Salt Lake.
Somehow, all applications of DRAKON happened to be in areas like space and defense, that are heavily protected by the state secrecy laws. So nobody could really confirm it. And that was also an excuse for not having any public tools released.
> Wikipedia mentions hybrid variants of Drakon
The only real programs in DRAKON are written like this. The compiler simply generates the code from the graphical description by joining the sections together.
Keep in mind that the spaceflight is systems-first; most development effort usually goes into the hardware and systems/mission design, the code has less priority and nearly zero decision freedom, so most of the complexity is baked into specs and requirements. In that sense, it's the appropriate area for a thing like this. It's also true for certain niches in industrial automation.
That said, in my experience, the Soviet tech industry workforce was separated into three very distinct categories since the ~70s: enthusiasts (people who came into it to actually build the tech; they delivered most of the result, and were the first to leave after the crash), opportunists (people who used it as a social elevator/welfare program and couldn't care less about the result), and crackpots (underperforming idealists who couldn't be fired, but still won't shut up about their wonderful idea, so they've been filtered into containment projects which were only meant to exist on paper). Drakon is giving off the strong vibes of something created by the last category.
That said, in my experience, the Soviet tech industry workforce was separated into three very distinct categories since the ~70s: enthusiasts (people who came into it to actually build the tech; they delivered most of the result, and were the first to leave after the crash), opportunists (people who used it as a social elevator/welfare program and couldn't care less about the result), and crackpots (underperforming idealists who couldn't be fired, but still won't shut up about their wonderful idea, so they've been filtered into containment projects which were only meant to exist on paper). Drakon is giving off the strong vibes of something created by the last category.
I have used it to produce diagrams that represent various stages in the workflows of a content management system for video and mobile assets. Just because the underlying systems were complicated doesn't mean the diagrams needed to be, and I find its design decisions to be helpful. It hits the sweet spot between comprehensible to non-technical users and useful for technical users.
Drakon could be a really useful decompilation target, or at least an alternative to control flow graphs produced by tools like Ghidra and IDA. Seems like its relative lack of hierarchical structure would match the nature of assembly branching.
> Line intersections are forbidden
Not all graphs are planar. Not even all DAGs. Which I assume can throw a wrench into things
Not all graphs are planar. Not even all DAGs. Which I assume can throw a wrench into things
Flowchart normal form. Neat really. Makes me want to play around with a Smalltalk dialect.
My least favorite thing about all the common programming languages is that programs are represented as one dimensional byte arrays. You can talk about ASTs and whatever else to your heart’s content, but at the end of the day you’re editing a one dimensional character/rune array. It’s especially sad since existential graphs[1] are well over a century old.
Maybe one day I’ll manage to invent a properly two dimensional m-expression that works with any s-expressions.
[1] https://en.m.wikipedia.org/wiki/Existential_graph
My least favorite thing about all the common programming languages is that programs are represented as one dimensional byte arrays. You can talk about ASTs and whatever else to your heart’s content, but at the end of the day you’re editing a one dimensional character/rune array. It’s especially sad since existential graphs[1] are well over a century old.
Maybe one day I’ll manage to invent a properly two dimensional m-expression that works with any s-expressions.
[1] https://en.m.wikipedia.org/wiki/Existential_graph
Programs are represented as one-dimensional byte arrays while they are being executed, too, as are all other data structures stored in an address space. I don't see why complex data structures flattened into a linear space via syntax structures should be any less legitimate than complex data structures flattened into a linear address space via pointers.
Good for flowcharts, less so for programming.
> My least favorite thing about all the common programming languages is that programs are represented as one dimensional byte arrays
The reason why graphical notations never took off in programming (and never will), is simple: It's all neat and shiny when we represent small algorithms or small example programs as flowcharts.
And then, as soon as the program grows to a sizeable project, that has to deal with state, external state, user defined state, represent a GUI, talk to another system, or does anything even slightly more complex than the examples or single algorithms, the whole thing goes to hell. Try to represent a webserver with 50 different endpoints as a graph. Try representing a single page application for a webshop, including error handling and different ways of discovery. You'll need ALOT of screenspace, and those are not even complex examples.
And then there is the problem of editing, storing, versioning, compiling and transmitting the programs. All these are solved problems with code, none of them are universally solved for graphs. Sure, we could just define a textual representation of the graphs, but then we're right back to the "byte arrays", just with one added layer of complexity.
> My least favorite thing about all the common programming languages is that programs are represented as one dimensional byte arrays
The reason why graphical notations never took off in programming (and never will), is simple: It's all neat and shiny when we represent small algorithms or small example programs as flowcharts.
And then, as soon as the program grows to a sizeable project, that has to deal with state, external state, user defined state, represent a GUI, talk to another system, or does anything even slightly more complex than the examples or single algorithms, the whole thing goes to hell. Try to represent a webserver with 50 different endpoints as a graph. Try representing a single page application for a webshop, including error handling and different ways of discovery. You'll need ALOT of screenspace, and those are not even complex examples.
And then there is the problem of editing, storing, versioning, compiling and transmitting the programs. All these are solved problems with code, none of them are universally solved for graphs. Sure, we could just define a textual representation of the graphs, but then we're right back to the "byte arrays", just with one added layer of complexity.
Seeing this gave me the idea that we should add flowchart-style visualization of executable specifications written in our system-level specification & query language, SpeQTr (https://docs.auxon.io/speqtr/).
We already do some things to extract flowchart/state-diagram like topology information from collected system traces, but given how much of our customer workflows center around requirements & specifications, I think going the direction of communicating the underlying detailed specification more abstractly would be a big win.
We already do some things to extract flowchart/state-diagram like topology information from collected system traces, but given how much of our customer workflows center around requirements & specifications, I think going the direction of communicating the underlying detailed specification more abstractly would be a big win.
Related:
Drakon: a visual language for specifications from the Russian space program - https://news.ycombinator.com/item?id=12638032 - Oct 2016 (39 comments)
Drakon – A visual language for specifications from the Russian space program - https://news.ycombinator.com/item?id=6429283 - Sept 2013 (28 comments)
Drakon: a visual language for specifications from the Russian space program - https://news.ycombinator.com/item?id=12638032 - Oct 2016 (39 comments)
Drakon – A visual language for specifications from the Russian space program - https://news.ycombinator.com/item?id=6429283 - Sept 2013 (28 comments)
https://youtu.be/yZLedcnFA94
Here is a video of Stepan Mitkin demoing Drakon at an Erlang conference from 2015.
Here is a video of Stepan Mitkin demoing Drakon at an Erlang conference from 2015.
Where is the language spec? I can only see a visual editor.
DRAKON seems like almost the perfect embeddable visual scripting language aside from one detail.
I looked into some of their visual aspects when I was doing if this then that rules embedding, but I ended up deciding left to right was more appropriate for something likely to have many short separate flows that fit on a screen.
Other than that, it's just so many light hears beyond regular flowcharts in terms of aesthetics and readability.
I looked into some of their visual aspects when I was doing if this then that rules embedding, but I ended up deciding left to right was more appropriate for something likely to have many short separate flows that fit on a screen.
Other than that, it's just so many light hears beyond regular flowcharts in terms of aesthetics and readability.
Neat. This looks a bit like the gofmt for flow charts.
I've had to design flow charts in the past and this looks like a rock solid way of designing some complex flows. It can easily turn into a spaghetti fest.
I've had to design flow charts in the past and this looks like a rock solid way of designing some complex flows. It can easily turn into a spaghetti fest.
No loops? What about a process with this kind of structure?
https://en.wikipedia.org/wiki/OODA_loop
https://en.wikipedia.org/wiki/OODA_loop
> No loops?
It has loops. Check out the examples here: https://drakonhub.com/drakon-examples
It has loops. Check out the examples here: https://drakonhub.com/drakon-examples
Ah, ok, so the part that says time always flows downwards in Drakon diagrams just means under normal circumstances, not _always_. TBH it wouldn't be all that useful if was limited to only layouting DAGs, so I'm glad that's the case.
Neat!
From the start (ie: 1946-48) they conceptualized programming through the notional of 'logical schemas' or 'logical operators' which were a pseudo-textual notation for flow charts. They went so far as to develop entire theories for the analysis, and optimization of these logical schemas.
Another fascinating language was Analitik which was a language for CAS (like Matlab) developped by V. Glushkov in Ukraine.
There exists a fantastic website about programming languages in the ussr: http://www.compiler.su/ekskurs-v-istoriyu-razrabotok-yazykov...
There are also entire journals worth of these papers on PL design from the '50s which have been translated to english and sit rotting in university shelves.
edit: there's actually another post on the front page on my project to recreate the first of those languages: https://github.com/xldenis/besm, though unfortunately I have let it fall aside in recent years.