Live data from Hacker News

DRAKON – An algorithmic visual programming language

en.wikipedia.org

31–40 of 55 posts

Re: DRAKON – An algorithmic visual programming language

#31
post #26

Earlier quoted context omitted.

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

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

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

Re: DRAKON – An algorithmic visual programming language

#32

Earlier quoted context omitted.

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…

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 flo…

Code completion evolved from a graphically structured language, AlicePascal, for this reason. We've been adding visual features into our text based lnaguages via tooling for quite some time.

Re: DRAKON – An algorithmic visual programming language

#33
post #16

Using SQLite for persistence is quite interesting! http://drakon-editor.sourceforge.net/instant_save.html

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

Re: DRAKON – An algorithmic visual programming language

#34
post #28

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 a…

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?

Re: DRAKON – An algorithmic visual programming language

#35
post #26

Earlier quoted context omitted.

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

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

It's a cultural thing and varies hugely depending on which country you're in. In my bit of Britain it's quite common for groups of women to refer to themselves as 'guys'.

Re: DRAKON – An algorithmic visual programming language

#36

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

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 process…

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

Re: DRAKON – An algorithmic visual programming language

#38

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.

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

Re: DRAKON – An algorithmic visual programming language

#39
post #5
post #3

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.

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

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.

Re: DRAKON – An algorithmic visual programming language

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

Post reply on HN