Drakon – A visual language for specifications from the Russian space program | Hacker News Reader

Drakon – A visual language for specifications from the Russian space program

drakon-editor.sourceforge.net

126 pointsthrowaway34428 comments

I've been using it for a while and documented my experiences at http://shkspr.mobi/blog/2013/04/use-drakon-to-generate-code-...

I thought this is just a toy until I read your blog. Now I'm actually looking into playing around with it a little... Thanks.

http://drakon-editor.sourceforge.net/inseption.png

I like how it says "Your drawing looks good". Why doesn't gcc ever compliment my code?

It does, perhaps it doesn't think your code is good enough?

The tragic consequencesvof the unix philosophy of silence on success.

Would it still be a compliment if it came from stderr?

clearly we need a stdaffirmation.

A year ago I wrote TEA cipher implementation with it for fun:

https://github.com/dchest/drakon-tea

(Pictures: https://github.com/dchest/drakon-tea/tree/master/pics)

It was painful.

What was painful about it? Was the language itself cumbersome to use, or was it the problem with the graphical editor software?

The language is actually C (you can also use Python, etc. I think the original underlying language was a variant of Oberon). The painful part was the graphical editor, or, I'd say, the idea of using graphics for programming instead of text. Imagine aligning all these rectangles and then realizing that you got a part of algorithm wrong: now you'll have to realign everything!

I think it would be much easier to edit some textual representation, and then use a program to convert it to the graphical one, if you want to read it this way.

This reminds me of a coworker who uses National Instruments' LabView's graphical programming capabilities to parse text files. Graphical programming is just not suitable for some tasks.

I see this a lot in LabVIEW projects (using it for things in which it is cumbersome). I think it is a symptom of the "golden hammer syndrome". LabVIEW is really, really efficient for some things and people become highly proficient at it. Unfortunately, those same folks are apt to use it for things in which it is ill-advised like text-parsing.

I like to think of graphical programming languages as DSL's: when they're aimed at the right problem, they're like a hot knife through butter compared to a general purpose tool. But when you start using DSL's for things in which they are not intended you end up with nightmarishly obscure codebases.

In Soviet Russia, charts flow YOU!

But seriously, these look just like the flowcharts that were all over CS in the seventies. And the code that's generated (based on the examples from edent and dchest) is basically unmaintainable GOTO-hell that looks like what you get from decompiling code without symbols...

I'd be curious to see what gets generated for the parallelism stuff, tho.

This has sat in my bookmarks far too long. Visual programming techniques are very different and vastly under developed compared to the plethora of other 'toy languages' that get more development.

Gotta love software docs that show getting drunk on various amounts of vodka as an explanation of their select statement!

This actually looks useful -- the simple set of rules they suggest make a lot of sense for general flowchart readability, and these could be easily shared with business partners of only a half-technical mindset.

I was curious how you would handle event driven architectures with it, however -- or is that outside the intended scope?

if you like events driven and distributed - that evokes old memories of SDL-88/92 - a product of sober European sleep of reason,a graphical Erlang.

Upvoted because I'm a strong believer in visual programming languages. But also a bit underwhelmed. Flowcharts are useful I guess.

Strictly speaking all programming languages are visual. Except ones are much easier to write because typing on a computer today is way faster than drawing.

Once drawing becomes more productive (which I don't see exactly how, to be honest) then diagram-based languages will raise their heads. Until then, no, thank you.

I hear already recruiters ask: "Do you know Drakon?". Just like when it was the default to insert UML in every job listing.

Out of curiosity -- are there any better open-source or commercial alternatives to this type of software?

One recent one is NoFlo http://noflojs.org/

A well established one for kids & novices is Scratch: http://scratch.mit.edu/

And you can see some other javascript-based visual programming tools here: https://github.com/jashkenas/coffee-script/wiki/List-of-lang...

20 years ago, during the peak of the CASE hype, there used to be several others.Borland ObjectVision, IBM VisualAge, Siemens EasyCase were some of them. Problem of all this tools is: It's proven that they don't scale. The sample programms that come with them all look nice and tidy, but god beware if you have to solve some real problem with real error handling. Right now Matlab Simulink&Stateflow (+some kind of code generator) is the only system usable for fingerpainting programms of significant size.

Is there a textual input representation to go along with the visual analysis one? I love using flowcharts to explain and comprehend complicated things, but the UIs for actually drafting them haven't quite made it into the 1960s yet and are painful as hell. Going from the video, this tool is better than most but still lots of modal button-hunting and handle-dragging and manual alignment.

The .drn file format is a SQLite database but it looks like it encodes the coordinates of the elements directly rather than storing symbolic relationships and doing a layout. If you could use a Graphviz-like language to describe the diagrams but add the Drakon rules for structure and layout (and presentation) I'd be a lot more enthusiastic.

Hey, maybe we will get to ObjectVision all over again, only this time it can work! Or continue to be developed, at least.

I remember putting in around 30 hours on a consulting project trying to use ObjectVision 2.1 (I think that was the version - been a while) before finally giving up and going to FoxPro in disgust... Had to keep project deadlines.

I think this is great for getting non-technical stakeholders into the development process.

Nearly anyone should be able to understand a flowchart and also make improvements and understand why that feature is more or less difficult to implement.

I know this isnt new, but really liked it

Sounds like a great tool for programming numerical algorithms. You get the code and a flowchart for your paper all at once.

Very interesting, although I am somewhat surprised that given its knowledge of the logic, it doesn't generate tests.

Reminds me the Macromedia Authorware.

Reply on news.ycombinator.com