5 ms·

The DRAKON Language

223 points by brudgers 3y ago

junon 3y ago
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.
- anonzzzies 3y ago
  DRAKON is an actual language; https://en.wikipedia.org/wiki/DRAKON?wprov=sfti1 https://en.wikipedia.org/wiki/DRAKON?wprov=sfti1
  - beefman 3y ago
    I didn't know wikipedia had link tracking https://wikitech.wikimedia.org/wiki/Provenance https://wikitech.wikimedia.org/wiki/Provenance
- erk__ 3y ago
  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 https://drakon-editor.sourceforge.net/DRAKON.pdf [1]: https://en.wikipedia.org/wiki/DRAKON https://en.wikipedia.org/wiki/DRAKON [2]: https://github.com/stepan-mitkin/drakonwidget https://github.com/stepan-mitkin/drakonwidget
erk__ 3y ago
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 https://github.com/stepan-mitkin/drakonhub [1]: https://drakon-editor.sourceforge.net/ https://drakon-editor.sourceforge.net/ [2]: https://github.com/stepan-mitkin/drakon_editor https://github.com/stepan-mitkin/drakon_editor
kqr2 3y ago
Can anyone share any practical experience using Drakon for a non-trivial project?
- Onavo 3y ago
  [flagged]
- lugu 3y ago
  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.
- cyberax 3y ago
  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 https://github.com/stepan-mitkin/drakon.tech
  - orbital-decay 3y ago
    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).
    - cyberax 3y ago
      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.
jonahx 3y ago
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.
- two_handfuls 3y ago
  Yes, ideally a markdown extension for Drakon, like we have one for (a subset of) Graphviz.
  - tgv 3y ago
    I guess it would look very much like A #if B #if D #if F G #else H #else E #else C #end
PaulHoule 3y ago
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
- Jtsummers 3y ago
  > No loops? It has loops. Check out the examples here: https://drakonhub.com/drakon-examples https://drakonhub.com/drakon-examples
  - m12k 3y ago
    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.
xavxav 3y ago
Oh I love this project, its very interesting to think about its relation to the family tree of soviet programming languages. 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-programmirovaniya-i-kompilyatorov-v-sssr.php 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 https://github.com/xldenis/besm, though unfortunately I have let it fall aside in recent years.
User23 3y ago
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 https://en.m.wikipedia.org/wiki/Existential_graph
- usrbinbash 3y ago
  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.
- marssaxman 3y ago
  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.
im_down_w_otp 3y ago
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/ 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.
sterlind 3y ago
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.
eternityforest 3y ago
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.
keyle 3y ago
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.
gregjw 3y ago
Neat!
jweir 3y ago
https://youtu.be/yZLedcnFA94 https://youtu.be/yZLedcnFA94 Here is a video of Stepan Mitkin demoing Drakon at an Erlang conference from 2015.
skybrian 3y ago
Looking 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 https://github.com/stepan-mitkin/drakonhub
- erk__ 3y ago
  The drn file format is described here https://drakon-editor.sourceforge.net/file_format.html 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/examples.js https://github.com/stepan-mitkin/drakonwidget/blob/main/js/e...
tvb12 3y ago
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/ 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.
IAmLiterallyAB 3y ago
> Line intersections are forbidden Not all graphs are planar. Not even all DAGs. Which I assume can throw a wrench into things
dang 3y ago
Related: Drakon: a visual language for specifications from the Russian space program - https://news.ycombinator.com/item?id=12638032 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 https://news.ycombinator.com/item?id=6429283 - Sept 2013 (28 comments)
Alex_Bell 3y ago
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.
anilakar 3y ago
Where is the language spec? I can only see a visual editor.

223 points by brudgers 3y ago

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.

anonzzzies 3y ago
DRAKON is an actual language; https://en.wikipedia.org/wiki/DRAKON?wprov=sfti1 https://en.wikipedia.org/wiki/DRAKON?wprov=sfti1
- beefman 3y ago
  I didn't know wikipedia had link tracking https://wikitech.wikimedia.org/wiki/Provenance https://wikitech.wikimedia.org/wiki/Provenance
erk__ 3y ago
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 https://drakon-editor.sourceforge.net/DRAKON.pdf [1]: https://en.wikipedia.org/wiki/DRAKON https://en.wikipedia.org/wiki/DRAKON [2]: https://github.com/stepan-mitkin/drakonwidget https://github.com/stepan-mitkin/drakonwidget

erk__ 3y ago

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 https://github.com/stepan-mitkin/drakonhub [1]: https://drakon-editor.sourceforge.net/ https://drakon-editor.sourceforge.net/ [2]: https://github.com/stepan-mitkin/drakon_editor https://github.com/stepan-mitkin/drakon_editor

kqr2 3y ago

Can anyone share any practical experience using Drakon for a non-trivial project?

Onavo 3y ago
[flagged]
lugu 3y ago
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.
cyberax 3y ago
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 https://github.com/stepan-mitkin/drakon.tech
- orbital-decay 3y ago
  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).
  - cyberax 3y ago
    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.

jonahx 3y ago

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.

two_handfuls 3y ago
Yes, ideally a markdown extension for Drakon, like we have one for (a subset of) Graphviz.
- tgv 3y ago
  I guess it would look very much like A #if B #if D #if F G #else H #else E #else C #end

PaulHoule 3y ago

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

Jtsummers 3y ago
> No loops? It has loops. Check out the examples here: https://drakonhub.com/drakon-examples https://drakonhub.com/drakon-examples
- m12k 3y ago
  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.

xavxav 3y ago

Oh I love this project, its very interesting to think about its relation to the family tree of soviet programming languages. 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-programmirovaniya-i-kompilyatorov-v-sssr.php 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 https://github.com/xldenis/besm, though unfortunately I have let it fall aside in recent years.

User23 3y ago

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 https://en.m.wikipedia.org/wiki/Existential_graph

usrbinbash 3y ago
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.
marssaxman 3y ago
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.

im_down_w_otp 3y ago

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/ 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.

sterlind 3y ago

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.

eternityforest 3y ago

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.

keyle 3y ago

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.

gregjw 3y ago

Neat!

jweir 3y ago

https://youtu.be/yZLedcnFA94 https://youtu.be/yZLedcnFA94 Here is a video of Stepan Mitkin demoing Drakon at an Erlang conference from 2015.

skybrian 3y ago

Looking 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 https://github.com/stepan-mitkin/drakonhub

erk__ 3y ago
The drn file format is described here https://drakon-editor.sourceforge.net/file_format.html 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/examples.js https://github.com/stepan-mitkin/drakonwidget/blob/main/js/e...

tvb12 3y ago

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/ 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.

IAmLiterallyAB 3y ago

> Line intersections are forbidden Not all graphs are planar. Not even all DAGs. Which I assume can throw a wrench into things

dang 3y ago

Related: Drakon: a visual language for specifications from the Russian space program - https://news.ycombinator.com/item?id=12638032 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 https://news.ycombinator.com/item?id=6429283 - Sept 2013 (28 comments)

Alex_Bell 3y ago

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.

anilakar 3y ago

Where is the language spec? I can only see a visual editor.