6 ms·

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

126 points by throwaway344 13y ago

adamnemecek 13y ago
http://drakon-editor.sourceforge.net/inseption.png http://drakon-editor.sourceforge.net/inseption.png I like how it says "Your drawing looks good". Why doesn't gcc ever compliment my code?
- thejosh 13y ago
  It does, perhaps it doesn't think your code is good enough? /s
- kazagistar 13y ago
  The tragic consequencesvof the unix philosophy of silence on success.
- fspeech 13y ago
  Would it still be a compliment if it came from stderr?
  - felixgallo 13y ago
    clearly we need a stdaffirmation.
raintrees 13y ago
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.
dchest 13y ago
A year ago I wrote TEA cipher implementation with it for fun: https://github.com/dchest/drakon-tea https://github.com/dchest/drakon-tea (Pictures: https://github.com/dchest/drakon-tea/tree/master/pics https://github.com/dchest/drakon-tea/tree/master/pics) It was painful.
- jonahx 13y ago
  What was painful about it? Was the language itself cumbersome to use, or was it the problem with the graphical editor software?
  - dchest 13y ago
    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.
    - donquichotte 13y ago
      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.
      - angdis 13y ago
        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.
eonil 13y ago
Reminds me the Macromedia Authorware.
dedosk 13y ago
Out of curiosity -- are there any better open-source or commercial alternatives to this type of software?
- edtechdev 13y ago
  One recent one is NoFlo http://noflojs.org/ http://noflojs.org/ A well established one for kids & novices is Scratch: http://scratch.mit.edu/ 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-languages-that-compile-to-JS https://github.com/jashkenas/coffee-script/wiki/List-of-lang...
- burstmode 13y ago
  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.
techdragon 13y ago
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.
jonahx 13y ago
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?
- VladRussian2 13y ago
  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.
worldsayshi 13y ago
Upvoted because I'm a strong believer in visual programming languages. But also a bit underwhelmed. Flowcharts are useful I guess.
- mojuba 13y ago
  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.
cateye 13y ago
I hear already recruiters ask: "Do you know Drakon?". Just like when it was the default to insert UML in every job listing.
edent 13y ago
I've been using it for a while and documented my experiences at http://shkspr.mobi/blog/2013/04/use-drakon-to-generate-code-from-flowcharts/ http://shkspr.mobi/blog/2013/04/use-drakon-to-generate-code-...
- RamiK 13y ago
  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.
al2o3cr 13y ago
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.
telephonetemp 13y ago
Sounds like a great tool for programming numerical algorithms. You get the code and a flowchart for your paper all at once.
deleted 13y ago
[deleted]
bcoates 13y ago
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.
singold 13y ago
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
ternaryoperator 13y ago
Very interesting, although I am somewhat surprised that given its knowledge of the logic, it doesn't generate tests.

126 points by throwaway344 13y ago

http://drakon-editor.sourceforge.net/inseption.png http://drakon-editor.sourceforge.net/inseption.png I like how it says "Your drawing looks good". Why doesn't gcc ever compliment my code?

thejosh 13y ago
It does, perhaps it doesn't think your code is good enough? /s
kazagistar 13y ago
The tragic consequencesvof the unix philosophy of silence on success.
fspeech 13y ago
Would it still be a compliment if it came from stderr?
- felixgallo 13y ago
  clearly we need a stdaffirmation.

raintrees 13y ago

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.

dchest 13y ago

A year ago I wrote TEA cipher implementation with it for fun: https://github.com/dchest/drakon-tea https://github.com/dchest/drakon-tea (Pictures: https://github.com/dchest/drakon-tea/tree/master/pics https://github.com/dchest/drakon-tea/tree/master/pics) It was painful.

jonahx 13y ago
What was painful about it? Was the language itself cumbersome to use, or was it the problem with the graphical editor software?
- dchest 13y ago
  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.
  - donquichotte 13y ago
    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.
    - angdis 13y ago
      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.

eonil 13y ago

Reminds me the Macromedia Authorware.

dedosk 13y ago

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

edtechdev 13y ago
One recent one is NoFlo http://noflojs.org/ http://noflojs.org/ A well established one for kids & novices is Scratch: http://scratch.mit.edu/ 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-languages-that-compile-to-JS https://github.com/jashkenas/coffee-script/wiki/List-of-lang...
burstmode 13y ago
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.

techdragon 13y ago

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.

jonahx 13y ago

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?

VladRussian2 13y ago
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.

worldsayshi 13y ago

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

mojuba 13y ago
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.

cateye 13y ago

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

edent 13y ago

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

RamiK 13y ago
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.

al2o3cr 13y ago

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.

telephonetemp 13y ago

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

deleted 13y ago

[deleted]

bcoates 13y ago

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.

singold 13y ago

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

ternaryoperator 13y ago

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