
Drakon: a visual language for specifications from the Russian space program - GuiA
http://drakon-editor.sourceforge.net
======
hbt
This is great work. FYI spacex uses LabView
[http://www.ni.com/labview/](http://www.ni.com/labview/) (amongst other stuff)

I wonder if you could use annotations to manage the visuals e.g
[http://drakon-editor.sourceforge.net/folder-night.png](http://drakon-
editor.sourceforge.net/folder-night.png) You'd have an inline annotation to
separate the code blocks and generate the visuals so you don't have to
maintain/update two places. Any tool that does that?

Also, integrating different level of complexity using system 1,2,3 (from
[https://www.amazon.ca/Software-Requirements-3rd-Karl-
Wiegers...](https://www.amazon.ca/Software-Requirements-3rd-Karl-
Wiegers/dp/0735679665)) to represent user flow diagram in addition to flow
charts.

Flow charts get confusing after some complexity. Useless if you want to
represent multiple actors + messages. Systems/sub-systems view.

There is a tendency to think of visual programming as an all or nothing.
Either we have all text or all visual. As long as it is "Write once, update
everywhere", visual tools can be useful in navigating new code bases,
obtaining insights and quickly understanding a piece of code.

The problem though is they often require maitenance and get out of date with
reality (even if it is comments/annotations)

------
memracom
Couldn't get it to work on OSX (El Capitan) even after installing ActiveState
Tcl/Tk. After removing that package following these instructions
[http://superuser.com/questions/36567/how-do-i-uninstall-
any-...](http://superuser.com/questions/36567/how-do-i-uninstall-any-apple-
pkg-package-file)

I installed MacPorts from
[https://www.macports.org/](https://www.macports.org/)

sudo port install tk cd ~/Downloads/drakon_editor1.27 tclsh8.6
drakon_editor.tcl

And it works!!! Interesting idea for making the structure visible and
presumably, helping find corner cases that are not handled. You could
presumably build a library using Drakon, and then build an app using the
library so that the detail of the code in the library is hidden behind simple
function calls.

This reminds me of the proliferation of graphical workflow systems such as
BPMN and this nifty Data Mining app called Orange3
[http://orange.biolab.si/orange3/](http://orange.biolab.si/orange3/)

I think we may finally be figuring out how to apply a visual paradigm to
coding in a way that works for real production apps.

------
aaawow
The whole Buran spacecraft
[https://en.wikipedia.org/wiki/Buran_(spacecraft)](https://en.wikipedia.org/wiki/Buran_\(spacecraft\))
was designed using Drakon

------
ivan_ah
This is very cool. I like this example which uses diagram for general logic
flow, but mixes raw code for details: [http://drakon-
editor.sourceforge.net/folder-night.png](http://drakon-
editor.sourceforge.net/folder-night.png)

------
denfromufa
Blockly developed by Google is adopted by many educational projects:

[https://developers.google.com/blockly/](https://developers.google.com/blockly/)

Go to "Built with Blockly" which includes BBC MicroBit, MIT App Inventor,
code.org, LEGO (3rd party), PBS, Minecraft (3rd party), etc.

~~~
erichocean
Blocky…sucks. Way worse than just learning something like Python.

(And this is someone who's spent most of his professional life working on
visual programming systems.)

~~~
Buetol
I've found the Khan academy way to be very efficient for 9-years olds. The
main problem with textual languages is that kids mess up with the syntax
easily but once they "get it", it's a bliss.

------
achr2
Can the tool generate a diagram from existing source code? Obviously it would
likely require additional input for internal 'headings'. And can the diagrams
be automatically 'collapsed' into simpler flow charts?

I have two thoughts around this:

1) A lot of 'simple' source code would generate large, complex diagrams -
which are likely not very readable, and brings up the same old decries against
visual programming.

2) maybe striving for code that works well when converted to a visual language
is a good check for code quality.

------
javajosh
Pretty cool, but one nitpick: when you save as SVG it embeds the font as a
base64 encoded url(). Neat trick, but it bloats the file a lot. A simple chart
with a few elements ends up being 250kB. Hand-written SVG would be two orders-
of-magnitude less than that.

------
smaili
This is the first time in a while I've seen an active project on SourceForge.

~~~
hyperion2010
[https://github.com/stepan-mitkin/drakon_editor](https://github.com/stepan-
mitkin/drakon_editor) seems to be where development is though.

------
kelvin0
Humm, this looks and awful like flow charts? What am I missing (apart from the
'Insertion' of macro charts)? All the rules about not 'breaking' visual
cohesiveness seem like a plus, although not groundbreaking either. Don't want
to sound negative, maybe someone can correct me?

~~~
GuiA
It is a formal specification for a specific kind of flow charts, yes. The
specifics of the implementation, the history, and the tooling around it are
what's interesting.

Your comment is a bit analogous to someone commenting "Humm, this looks an
awful lot like programming?" on a link documenting a forgotten programming
language. Well yes, it's true, but it's a tautological statement.

~~~
kelvin0
Ah, so this is interesting from a historic perspective. I thought this was
being released as a formal method that brought some innovation, as mentionned
earlier I had no idea or context other than the slide I went through posted in
the link.

------
ilaksh
Is there some overlap between these types of tools and
[http://martinfowler.com/bliki/ProjectionalEditing.html](http://martinfowler.com/bliki/ProjectionalEditing.html)

~~~
eiffel31
Drakon does not seem to be model-based, so I would say no. If you are
interested in Projectional Editing, you should look at MPS or Eclipse's
Sirius.

------
snerbles
Visual languages are also often used in industrial applications, usually in
the form of ladder logic instead of flow diagrams.

------
qwertyuiop924
I'm really confused as to what exactly this is, but it looks cool. It seems to
be some kind of visual programming environment, which I'm usually against on
principle (BOO non-standard binary formats! ASCII text is the closest we can
get to future-proof, and thus what we should be storing our source code! Down
with journald! you should know the drill by now...) But interesting ideas are
always interesting, so I'm willing to look into it, even if I don't like the
look of it.

~~~
GuiA
I don't understand your ideological point. The editable representation has no
bearing whatsoever on the storage representation of a program. There is
nothing preventing you from having a visual programming environment where
everything is just ASCII text under the hood.

~~~
lmm
In theory it would be possible to have a visual programming language that had
a readable stored representation with meaningful diff/merge/blame. But in
practice I've never seen one.

~~~
DonaldFisk
DRAKON represents programs as flowcharts, and there's no reason why the
underlying representation couldn't just be C, Python, or some other imperative
language, and there's no reason why C or Python originally written in vi
couldn't be represented in DRAKON.

I'm not a fan of flowcharts but DRAKON is of historical significance. The same
would apply to GRAIL.

Other imperative visual programming languages such as Scratch could also be
stored in a form resembling a textual imperative language. In other words, the
visual element is largely "syntactic sugar".

Dataflow programs can also be _stored_ as text rather than binary, but due to
the nature of dataflow, this would be inconvenient to program directly in.
This is because dataflow programs are _graphs_ with only a partial order
rather than ordered lists like programs in C or Lisp. This means that visual
dataflow languages, such as LabVIEW and my own Full Metal Jacket
([http://web.onetel.com/~hibou/fmj/FMJ.html](http://web.onetel.com/~hibou/fmj/FMJ.html))
aren't simply syntactic sugar.

There are textual dataflow languages such as SISAL, but these require a
compilation step before code is actually dataflow.

You should not be surprised to find that version control systems designed for
text in which lines of code are executed sequentially by default is less
useful for stored visual dataflow programs. You could still use diff/merge on
the stored representation at the function level, but not easily at the line
level, because the visual representation doesn't have lines of text and the
order might change arbitrarily from version to version.

This is why visual dataflow programs need a visual equivalent of diff/merge,
e.g. clicking on arrows to show the order in which changes were made to the
graph instead of diff. Work is being done on this, e.g. Austin Henley's
Yestercode (for LabVIEW), reviewed here:
[http://www.felienne.com/archives/5210](http://www.felienne.com/archives/5210)

------
hulahoof
Can anyone explain the advantage of a specification like this over something
like UML?

~~~
dragonwriter
Compared to UML Activity Diagrams, DRAKON- _Foo_ (where _Foo_ can be Python,
C, C++, Erlang, or any of a bunch of others):

(1) Is constrained in a way designed to enhance understanding of the visual
flow, and

(2) Directly includes code (in language _Foo_ ) in the boxes, rather than
text; that is, its a programming environment, not a diagramming language with
text that gets converted to program code somewhere else that is maintained
separately.

The first item is also a feature of DRAKON by itself.

~~~
eiffel31
About (2): there is a standard action language for UML which can be used to
fully describe your algorithm, independently of any language. In that sense,
the DRAKON approach seems more practical for software engineers / programmers
while the UML approach seems better for the domain experts.

------
asciihacker
Also see PlantUML, which also has experimental code generation tech.

------
buskila
Is there something similar to mermaid or graphviz, a DSL of sorts, to generate
similar diagrams?

------
asciihacker
I fought like hell to install all the deps before throwing in the towel.

~~~
Alupis
> I fought like hell to install all the deps before throwing in the towel.

What? The deps are pretty tame for such a large program.

tcl8.6, tk8.6, tcllib, libsqlite3-tcl, libtk-img

So, for a debian/ubuntu machine:

    
    
        sudo apt-get install tcl8.6 tk8.6 tcllib libsqlite3-tcl libtk-img
    

RHEL/Fedora and friends will be similar, except with yum/dnf.

All of this info is at the top of the downloads section:

[http://drakon-editor.sourceforge.net/editor.html#downloads](http://drakon-
editor.sourceforge.net/editor.html#downloads)

------
jlebrech
there should be a common interface to languages that have the same design
patterns, why can't a class just be a visual representation of something that
contains code, and do the same thing with methods and functions. then inside
of visual blocks of code you can then keep the programming languages as simple
as possible.

