
DRAKON – An algorithmic visual programming language - state
https://en.wikipedia.org/wiki/DRAKON
======
pcmonk
DRAKON is one of my favorite old-time visual programming languages. There's a
lot more information on the Russian Wikipedia page, including an astounding
225 references:
[https://ru.wikipedia.org/wiki/%D0%94%D0%A0%D0%90%D0%9A%D0%9E...](https://ru.wikipedia.org/wiki/%D0%94%D0%A0%D0%90%D0%9A%D0%9E%D0%9D)

~~~
altrego99
If I knew Russian, I would translate that into the English Wikipedia page.

------
dchest
I tried it a few years ago (DRAKON-C):

[https://github.com/dchest/drakon-tea](https://github.com/dchest/drakon-tea)

It was fun, but drawing those graphs is so slower than just writing code in
text... Especially, if you made a mistake somewhere and have to rearrange
parts.

~~~
pen2l
> It was fun, but drawing those graphs is so slower than just writing code in
> text... Especially, if you made a mistake somewhere and have to rearrange
> parts.

No-one has yet made an effort to parse code and programmatically create these
graphs? I hope someone does, seems very doable!

~~~
digi_owl
I have not checked out Drakon-editor, but i find myself wondering if it comes
down to being able or unable to do the graph manipulations by keyboard.
Meaning that to manipulate linkages or move blocks one has to reach for the
mouse.

------
shadowmint
As a tangentaly related point...

Has any visual programming language ever been successful?

The guys at Epic are really pushing their blueprint system, and a lot of
people like it... but its inherantly tied to the engine.

~~~
smt88
> The guys at Epic

The _people_ at Epic. Sorry, I know it's annoying, but sexism in computing
isn't going to change if we don't pay attention to the language we use.

~~~
wildlogic
I don't think 'guys' just refers to males.

~~~
seanmcdirmid
Guy Fawkes was male, and there is a feminine equivalent gals, but I think guys
is slowing moving over into gender neutral territory (it wasn't when I was a
kid, but times change).

------
edent
I've used DRAKON for generating Javascript -
[https://shkspr.mobi/blog/2013/04/use-drakon-to-generate-
code...](https://shkspr.mobi/blog/2013/04/use-drakon-to-generate-code-from-
flowcharts/)

It's really quite efficient to draw out an algorithm and let the computer turn
it into code. Doesn't work for every problem - but it is _very_ good at what
it does.

------
rdtsc
The editor:

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

(it is at the bottom of Wiki page but added it here for quicker access).

Also Stepan Mitkin gave an Erlang Factory talk this year about the Erlang
backend for DRAKON:

[http://www.erlang-factory.com/euc2015/stepan-mitkin](http://www.erlang-
factory.com/euc2015/stepan-mitkin)

~~~
jweir
Watching the video one of the approaches that is interesting is only straight
lines are allowed. The visual languages I have come across (Max/MSP and VVVV)
allow diagonal lines.

I would reckon the strictness of the straight line has positive side effects –
or avoids a class of negative side effects.

------
nutate
Interesting how this could tie into the diagrams coming out of the dataflow
paradigm (flumejava, flink, millwheel, naiad, and Frank McSherry's rust
timely-dataflow). All of which can be succinctly diagrammed out, but I like
the rigor of this. People in this thread have mentioned Max/MSP (it's
precursor puredata/pd) are really interesting visually, but they often feel
write only. Some of the rules of drakon could be attempted in a max patch, but
the shortest path nature and lack of jump labels could foil the idea.

At any rate, some food for thought when it comes to trying to ideate programs
away from a computer or at least away from a repl or IDE.

~~~
DonHopkins
It looks to me like Drakon is more of a control flow paradigm than a data flow
paradigm. What flows along the wires, other than the "program counter"? How is
data represented?

~~~
nutate
Definitely control flow not data flow, but the data is defined at each step of
the graph in variables like normal. In Frank McSherry's Rust stuff and the
Naiad stuff they seem to have a basic data structure of progress and "data to
process". Where progress is handling the time step of the process. The
dataflow isn't anything more than a variable being passed around and inputs
and outputs. So the control structure is the important part.

This is sort of rambly, but in pd/max/msp you end up with at least 2 types of
data flow rates (common in musical stuff like supercollider as well) for
musical sample rates (aka 44.1khz or whatnot) and 'control flow' rates (like
an LFO wub at 120bpm half notes). Those are all still wired up with the same
"lines" in pd so it can end up being confusing if you put a control rate into
a sample rate or vice versa. I'm sure current MaxMSP has ways to separate and
handle those (along w/ "bangs" which are one off messages), but the beauty of
something like drakon is that it is just control flow. The data is explicitly
defined in the boxes. So even though dataflow is the phrase google and
microsoft are throwing around, the real art is in the control flow. Look at
the scopes and contexts from the naiad paper:
[http://www.frankmcsherry.org/dataflow/naiad/2014/12/29/TD_ti...](http://www.frankmcsherry.org/dataflow/naiad/2014/12/29/TD_time_summaries.html)
I think that drakon would be an interesting way to draw that diagram out. Not
one hundred percent sure, but it's a thought.

------
bokchoi
Using SQLite for persistence is quite interesting!

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

~~~
vog
I fully agree with their strategy of persistent saving incremental steps.

However, the article misses one vital point: Undo!

Persistent saving without undo is a no-go. If I try something and the program
(or OS) crashes, my previous state would be lost. It would be a state worse
than not having saved the changes at all.

In particular, I find it troubling that they describe their SQLite actions as
"insert", "update", "delete". I would have expected this to be insert-only, to
preserve undo functionality after a crash. Then, from time to time some
"delete" for garbage collection (maybe triggered by the user).

------
osetinsky
what are some advantages/disadvantages of visual programming languages
compared to text based ones?

~~~
analog31
I did a fair amount of work with LabVIEW long ago. I also played with another
visual language for the Mac that was floating around in the 90s. This isn't a
slam against LabVIEW, which would be unfair in any event since it's been that
long and their product has changed a lot.

Advantage: It seemed easy for beginners to learn how to do simple things, such
as sequencing the operations and measurement in a lab experiment or instrument
prototype. That's pretty cool.

Disadvantages: 1) For me, I happen to suffer from severe eyestrain and wrist /
neck fatigue when dealing with tiny graphics and fine mouse work. I would not
be able to program a graphical language all day.

2\. My impression that it's hard to modify / refactor code because of the
laborious manual effort needed to move graphics around. Programs tend to
become unwieldy when they expand beyond one screen.

3\. I think that text is the easiest and quickest way to prototype a new
programming language idea, and there is rapid evolution and proliferation of
both text based languages and programming tools like specialized editors and
environments. It's also easier to port a text based language to a new machine.
I think that evolution would be slower if people had to develop a graphical
framework to try out a new language. It's also very easy to share source code,
either full programs or snippets, on the Internet via text, even across
different languages with a bit of manual translation.

~~~
darkmighty
1) I think although LabView is quite useful, it's interaction design is
terrible (that users play along only attests to it's utility!)

3) It's essentially a way of displaying code, so perhaps any new languages
could reuse the same graph/flowchart environment. But inherently visual
languages are designed either towards people who don't want to learn a
language or who are performing specific tasks where the graphic flow improves
their reasoning. I'd say for the vast majority of 'coding' those are not the
case, since the "concept density" is very low (but visual UIs may help a lot
of get started programming people anyway).

Having a graphical environment also helps remove a lot of cruft from languages
that newcomers shouldn't really have to deal with.

For example, if I want to make a C program to computer the distance between
tow points on a plane, I have in my head something like
"d=sqrt((x1-x2)^2+(y1-y2)^2); output d", and actually programming I'm going to
have to import a couple of libraries to take care of both floating point
arithmetic and IO. The only way a novice can know that is looking at an online
reference basically; while a decent UI could easily provide a searchable list
of math/IO functions and include libraries automatically. Those are always
taken care of in visual programming languages. The syntax itself of languages
is arbitrary in many ways you have to learn on a case by case basis (in the
example, how exactly do you use printf to "output d"?), while in an UI you are
_forced_ to use the correct syntax, because it's the only option.

When you are programming an operating system or low level application none of
those really matter, but for a newbie making a simple Mobile app it's going to
involve googling a lot and copious amounts of copy-pasting templates for
getting trivial things done.

~~~
analog31
Those are valid points. My first language, BASIC, didn't require libraries.
You could just enter those two statements and it would figure out the
libraries and types required, from the context. It was my understanding that
the additional "overhead" of C is to direct the compiler to make more
efficient code, and to head off certain kinds of failures of larger programs.

But still, I think your point stands. The tools that beginners like to use,
whether the underlying "language" is represented by text or graphics, tend to
be fairly self contained with zero overhead and a built in lookup system for
library functions and user interface design, and those systems tend to be
implemented as graphical software.

------
nyc_cyn
Can't we make text-based programming visual with some IDE/plugins?

It would be interesting to drag functions around (and so forth) in blocks.

~~~
gansai
Some of the data flow representation software enables us to do this, I guess.
From UML diagrams, we could create classes etc

------
curiousjorge
is there a javascript library or framework that lets users build visual logic
like this and serialize it?

~~~
beemoe
Take a look at Blockly:
[https://developers.google.com/blockly/](https://developers.google.com/blockly/)

