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.
DRAKON – An algorithmic visual programming language
31–40 of 55 posts
Re: DRAKON – An algorithmic visual programming language
#32Earlier 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…
Re: DRAKON – An algorithmic visual programming language
#33Using SQLite for persistence is quite interesting! http://drakon-editor.sourceforge.net/instant_save.html
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
#34Interesting 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…
Re: DRAKON – An algorithmic visual programming language
#35Earlier 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.
Re: DRAKON – An algorithmic visual programming language
#36what 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…
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
#37Can't we make text-based programming visual with some IDE/plugins? It would be interesting to drag functions around (and so forth) in blocks.
Re: DRAKON – An algorithmic visual programming language
#38As 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.
Re: DRAKON – An algorithmic visual programming language
#39I 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!
Re: DRAKON – An algorithmic visual programming language
#40It'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.