DRAKON – An algorithmic visual programming language

https://en.wikipedia.org/wiki/DRAKON

by state • 11 years ago

86 48 11 years ago

en.wikipedia.org

pcmonk• 11 years ago

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

altrego99• 11 years ago

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

dchest• 11 years ago

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

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• 11 years ago

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_owl2• 11 years ago

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.

osetinsky• 11 years ago

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

brudgers• 11 years ago

To the degree more eyes makes all bugs shallower, more eyes. That's a big deal when bugs mean people die. Bugs in space flight are likely to be fatal. Drakon takes a sound approach to software engineering as a serious discipline bound by professional ethics.

analog313• 11 years ago

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.

DonaldFisk2• 11 years ago

1. Not all visual languages are the same, just as not all text-based languages are the same. The main problem is there aren't many in widespread use, and they tend to be quite specialized, so you might not find one which you're completely happy with.

2. Programs, or rather functions/procedures/subroutines should, with very few exceptions, be displayable on a single screen. If they are larger, they should be split up. This applies whether the language is textual or graphical. Moving graphics around should make no difference to how a dataflow program executes.

3. Yes, it's easier to develop a new text-based language, because so much research has been done on them, and you don't need to develop an editor along with the language. But there are hundreds in active use, which are constantly evolving. If you want a new set of features, you can add it to an existing language or create your own dialect. Visual code must have either a text or binary representation of the source which can be shared. It may not be human-readable but that's not the intention.

darkmighty• 11 years ago

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.

DonaldFisk2• 11 years ago

If the algorithm is to be distributed over multiple processors capable of executing different instructions, it is best represented as dataflow. (Dataflow algorithms are directed graphs, with data flowing along edges between vertices, each of which contains a single processing step.) This is because dataflow captures all the parallelism inherent in the algorithm without the programmer having to assign tasks to processors explicitly. While text-based dataflow languages exist, the directed graphs which comprise dataflow programs are more naturally represented graphically.

Having started down the dataflow route, further advantages then manifest themselves: most program development can be done by drag and drop, rather than typing; strong type checking can be done while edges are being drawn; the directed graphs used to draw code can double as completely general data structures; and the graphics libraries used to develop the language can be made available to the programmer.

The visual dataflow programming language I am developing is described here: http://web.onetel.com/~hibou/fmj/FMJ.html

Some visual languages, such as DRAKON and GRAIL, are based on conventional flowcharts showing flow of control, rather than flow of data. Flow of control, however, can be adequately represented as text.

DonHopkins2• 11 years ago

You make an important point about the distinction between control flow and data flow. They can both co-exist in a visual programming languages, but many VPLs tend to focus on one or the other.

Grasshopper [1] is very data flow oriented and functional, so you can program loops implicitly by flowing arrays, arrays of arrays, and trees along the wires, and the nodes know how to implicitly iterate over their inputs.

SimAntics (the visual programming language in The Sims) [2] (and I presume Dracon, but I haven't programmed in it) is very control flow oriented and imperative, almost like visual assembly language, and there is an implicit state (like a set of registers or local variables) that travels along with the program counter that flows along the lines between nodes.

A data flow switching "if" statement can be embodied in a data flow programming language as a node that takes three inputs: Condition, A and B, and outputs A if Condition is true, or B if Condition is false. Like "Condition ? A : B".

Or a control flow branching "if" statement can be embodied in a control flow programming language as a node that takes one input: a Condition (or it is activated by a flow of control input and the node contains a condition to evaluate against the VM state, like a flow chart branch node), and outputs the flow of control to A if the condition is true, or B if the condition is false (the road not taken). Like "if Condition goto A else goto B".

Some languages have a mix of both. Body Electric (aka Bounce) [3] is a real time data flow oriented visual programming language used for VR simulations, that primarily uses data flow switching "if" statements. The order of execution of the nodes is implicitly determined by a partial ordering of their dependency graph, and each node has an optional explicit "enable" input and output that you can use to turn on and off the execution of any node (behaving like an on-off switch type of "if" statement), and explicitly wire up the dependencies to control the order of execution (if the order of side effects is important, like for drawing commands).

Grasshopper is a good example of a successful data flow oriented visual programming language, with an excellent user interface, and a vast library of powerful features that elegantly dovetail together. I'm working on a project that uses Grasshopper for 3d printing houses. [4]

I'd caution against casually projecting anything you know about one visual programming language (like "it sucks" or "it rocks") onto any other visual programming language (and especially all other visual programming languages), because they can be EXTREMELY different! (Just like text programming languages.) And a lot of it boils down to ergonomics and user interface design, as well as the vocabulary of built-in primitives and libraries and abstraction mechanisms.

[1] http://vimeopro.com/rhino/grasshopper-getting-started-by-dav...

[2] http://donhopkins.com/home/movies/TheSimsPieMenus.mov and http://simswiki.info/wiki.php?title=SimAntics

[3] http://www.art.net/~hopkins/Don/lang/bounce/bounce.html and http://c2.com/cgi/wiki?BounceLanguage and http://www.jaronlanier.com/vpl.html and http://www.jaronlanier.com/instruments.html

[4] http://3dprintcanalhouse.com/ and this screenshot http://imgur.com/avYXU6Y from this video https://www.youtube.com/watch?v=TAoW1iA385w

beemoe2• 11 years ago

I have some professional experience using a visual programming language on the same files with many coworkers. Here are the biggest pain points I experienced:

Diff, merge, search/replace, copying code directly from chat or websites into a REPL or file to try it out.

I have used a handful of other visual languages and when I see a new one I am on the lookout for use cases that involve more than one programmer, sometimes not even knowing each other; features that make it compatible with existing file and line oriented version control systems or provide an alternative(which is a project in itself, hard, and might not be as modular)

Learning about visual programming languages gave me a new appreciation for the simple elegance of text and IMHO the future of them will be those that easily map back and forth between text and graphics so you can have the best of both worlds and continue to stand on the shoulders of giants.

Does anyone konw of languages that translate to/from text well?

nyc_cyn• 11 years ago

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• 11 years ago

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

sklogic• 11 years ago

This should be easy with the AST-based editors (such as JetBrains MPS).

shadowmint• 11 years ago

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.

ics• 11 years ago

LabVIEW's graphical language G has been around for a while and is widely used for certain kinds of things. Enough people hate it to consider it successful.

maaku• 11 years ago

Enough people hate it to consider it successful.

That is a very insightful quote.

panic• 11 years ago

Max/MSP is pretty widely used for music and audio: https://cycling74.com/products/max/

jweir2• 11 years ago

And VVVV http://vvvv.org

vvvv is a hybrid visual/textual live-programming environment for easy prototyping and development. It is designed to facilitate the handling of large media environments with physical interfaces, real-time motion graphics, audio and video that can interact with many users simultaneously.

foofoo55• 11 years ago

Depends what you mean by successful. Most industrial Programmable Logic Controllers (PLCs) can be programmed with a visual language, typically function block diagrams. The blocks are then functions and the lines represent a data value and not necessarily the direction of program flow. Once you want to get beyond basic flow control and into things like loops or state machines, then one would typically make a custom block or entire program using structure text, or some variant of C, etc.

blup• 11 years ago

Grasshopper (Rhino) is quite successful for architecture and 3D modeling, but its also tied to the engine. Also see https://news.ycombinator.com/item?id=7274674 for an exhaustive list.

smt882• 11 years ago

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• 11 years ago

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

delish• 11 years ago

I agree, both generally and specifically. Supporting your argument is Bell Labs' `sexist`[0], a commmandline tool, part of the Writer's Workbench.

http://man.cat-v.org/unix_WWB/1/sexist

A relevant section from its man page:

    [When given a file as input, sexist prints alternatives] 
    using neutral terms instead of sex-related terms.
    For example "business executive" could easily replace
    the stereotypic "businessman."

To me, "businessman" can be gender neutral just as "guys" can be gender neutral. Today we[1] don't use "businessman" for the same reason that in some years we won't use "guys"; it still gives a biased-towards-men picture of people.

[0] I'm citing Bell Labs because they're prestigious and respected by HN.

[1] Because I'm trying to influence the vox populi, I'm using "we" imprecisely. I hope that those who disagree with me follow my argument even though I'm not speaking for them.

digi_owl2• 11 years ago

Lego still use a graphical language for their Mindstorm kits, iirc.

TeMPOraL• 11 years ago

Which AFAIK is LabVIEW, btw.

edent3• 11 years ago

Scratch from MIT.

Ok, you're not going to write an OS in it - but for building games it's amazing. I use it to teach kids coding - some of the work they produce is astounding.

analog313• 11 years ago

I have to laugh because my son wrote an "OS" in Scratch. It consisted of a splash screen, log-in dialog, a menu to choose one or two little apps to run, and a BSOD.

Procedural• 11 years ago

Everyone in VFX industry successfully uses visual programming in production: see programs like Nuke, SideFX Houdini, RealFlow, Fabric Engine, etc.

but its inherantly tied to the engine

There's no successful (like C in text-based programming) visual programming environment for general-purpose programming at the moment.

rdtsc• 11 years ago

The editor:

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

jweir2• 11 years ago

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.

bokchoi• 11 years ago

Using SQLite for persistence is quite interesting!

http://drakon-editor.sourceforge.net/instant_save.html

vog• 11 years ago

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

nutate2• 11 years ago

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.

DonHopkins2• 11 years ago

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?

nutate2• 11 years ago

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... I think that drakon would be an interesting way to draw that diagram out. Not one hundred percent sure, but it's a thought.

Zuider• 11 years ago

Drakon can describe data too. From the Drakon website:

What is ERIL? ERIL is a graphics language for representing data model. It is based on entity-relationship and class diagrams. Thus the name, Entity-Relationship and Inheritance Language.

ERIL is a counterpart for DRAKON. The DRAKON language describes algorithms and behaviour. It is an improved version of flowcharts. DRAKON introduces some rules that make flowcharts more human-eye-friendly.

http://drakon-editor.sourceforge.net/eril.html

edent3• 11 years ago

I've used DRAKON for generating Javascript - https://shkspr.mobi/blog/2013/04/use-drakon-to-generate-code...

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.

curiousjorge• 11 years ago

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

beemoe2• 11 years ago

Take a look at Blockly: https://developers.google.com/blockly/

DRAKON – An algorithmic visual programming language

Related Stories