Is anyone aware of other visual programming paradigms which are not based on (or reduce to) the blocks&arrows model?
I cannot say I was ever satisfied in in every context where I saw this model applied. My experience ranges from trivial languages such as this, to compositing software, DAWs or something more sophisticated such as programming-oriented signal generators (where blocks are often used as filters/generators and edges as I/O connectors), to workflow editors...
It "might" look intuitive at first[1], but the network just becomes unreadable as soon as you have more than 10 nodes or non-linear behavior (with edges eventually crossing). Auto-layout just becomes a major problem to be solved. Auto-layout also destroys the visual locality of your program, so it actually goes against the programmer for anything non-trivial. Manual layout is something I do not want to take care of either.
Is any experiment or research being done that goes in a _different_ direction?
[1] I would actually say "less scary". I'm not convinced a simple programming language in the spirit of "BASIC" is less difficult to comprehend in the technical sense.
It's a fair question whether the visual/blocks model is appropriate for expert programmers. However, there was some research presented at ICER 2015 showing that visual/blocks languages have benefits for students learning to program. Mark Guzdial had an interesting blog post[1] about it.
I use ArcGIS model builder sometimes which is a block and arrow model. It seems to encourage people to think in a more functional, and less procedural manner. With procedural code it is easy for inexperienced people to get bogged down in endless if statements and managing state. This is a bad idea when the underlying operations you want to perform are more like maths operations and better used directly.
> It "might" look intuitive at first[1], but the network just becomes unreadable as soon as you have more than 10 nodes or non-linear behavior
It works for DSLs in video-compositing apps , "learn to code apps" , yahoo pipes like apps or VST plugin coding apps ( and to a certain extend you could argue that working with DAWs is programming, I mean Logic has some kind of visual programming environment, so does Ableton Live)
It doesn't work for anything complex that would be normally be done via typing actual code.
I mean it has always been the case.IMHO Anyone that says he can invent something that can replace typing instructions in a text editor[1] and give a better experience to a professional programmer that way is lying.
But VISUAL PROGRAMMING is great for learning how to code, I learned coding, OOP and all that stuff in Flash 15 years ago, dragging and dropping some stuff and seeing the result visually in a matter of micro seconds was enjoyable, felt rewarding and motivated me to explore programming further. It was a shoehorn into the world of programming.
1: It doesn't mean one cannot improve text editors and IDEs, I think there is a whole LOT of room for improvement in order to make typing programs painless, and I'd like to see more research and experimentation done in that specific area, because it feels to me we're still stuck into BORLAND era when it comes to IDEs and nothing has evolved since that time.
As a software engineer who have spent a fair amount of time building and modifying ensembles in Reaktor, I don't honestly see how these structures would be easier to build in code. Their conplexity comes not from environment, but from the meaning they represent; I doubt that connecting 5 LFOs, 3 oscillators and a step sequencer in VIM would be a much better user experience then dragging cords with a mouse.
I have nothing against the blocks&arrow model. I just find it [sometimes horribly] inefficient.
For instance, in a video-compositing application (something like nuke - to put a name) it makes sense, especially so you can represent/preview the state of the filter in the block itself, but it's far from being an efficient method to input or manipulate. If you have experience by programming in any classical language with a grammar, it should be self-evident.
I find myself thinking I could represent the same graph in a much more compact and logically structural way using a written grammar, albeit doing that loses some given visual aspects like previewing.
I was explicitly asking if there is anything else available.
Although they use the standard block graph model, both Grasshopper and Max have ways of compartmentalizing groups of components into a reusable "cluster" component, which can really help in organizing and abstracting otherwise dense layouts. You can jump back and forth between the context of the larger script and the internal context of the cluster.
It's analogous to putting all your code in a single source file versus splitting it into logical components across multiple files.
There is something nice about being able to organize the flow of process and logic in a spatial way. It's easier for me to recover from a 1 year break on a grasshopper script than a 1 year break on a typical code base.
We're working on a fairly different model at https://rundexter.com - right now it's a bit light on the programming constructs (we only have a switch statement and a very primitive loop), but very strong on data flow and data binding. If you don't want to sign up, you can see the basics in use at 0:45 of the homepage video. We looked at things like Snap and Blockly early on and agreed that they weren't satisfactory.
A few months ago I started a project with a similar vision but never got on to taking it to fruition: http://github.com/theideasmith/automata. I'm definitely going to take a deeper look at Dexter. Good luck to you guys!
I've played with Scratch with my kid. Diagrams quickly get cluttered. I have never seen DRAKON before. I like that there are visual rules to decrease clutter and impose a logical ordering. Very interesting take on visual programming, I'm glad I took a look, and would urge others to do so too! Thanks for the post.
They can all pretty much be reduced to a skin on top of an abstract syntax tree, since that's all they really are.
Circuit-based skins work well in the right context. Do a Google Image search for "unreal blueprints" to see many examples of them in use. Blueprints visual scripting probably powers the high-level logic in a video game you or someone you know has enjoyed.
The other popular approach is fill-in-the-blanks, a visualization that looks more like a tree than a graph. The first good version of this I saw was the Warcraft 3 scripting system. It inspired the visual scripting system we built for Tribes, SWAT, and the first Bioshock back in the day.
That's a simplistic view. A grammar might not be a 1:1 mapping to an AST (where the AST is just a reduction of a higher-level construct set). Also, an AST is really a generic term, and can mean anything from a parsed representation of the grammar to the final stage of the output code.
The classical example I give when I ask this question, is how do I represent the concept of an abstract "record" (or structure) in any visual language. How do I convey the mapping from definition to instance of any given construct?
These are though problems to represent in a visually compelling and useful way.
I agree, they're very tough problems. My summary was reductionist, and though I offered some examples (since that's what was asked for) I didn't mean to claim visual programming is always compelling and/or generally useful for the masses. I've been down that road before and reached other conclusions, though I'm happy other people are still trying to push the idea further.
Drakon (which was used in the Soviet space shuttle program) has rules about reasonableness, such as "no crossing lines" which while they can make for larger diagrams, does prevent some of the issues you mention.
That looks real nice! Glad someone is working on making Scratch do functions and stuff, because it's being used for teaching in many schools here in UK.
Also, having just cloned it from https://github.com/jmoenig/Snap--Build-Your-Own-Blocks/ , it appears that you just put host it with normal web server; none of that Adobe Air needed, unlike the newer Scratch versions.
I picked up a chromebook for my daughter the other day and was looking for web based programming apps. I came across "Run Marco", built using Blockly, which is fairly basic at this point but seems to be under active development.
I think you are missing the more important aspects like the fact that you can run this live much easier since you are less likely to create something that has a syntax error.
blocks-based languages were designed mainly for education, especially targeting younger users such as children. as experienced programmers, we often take it for granted how demoralizing syntax errors can be; blocks languages eliminate that giant hurdle for novices to help get them hooked on programming before they move onto traditional text-based languages.
I have always had feeling, that this style of visual programming would be better suited to functional paradigm.
It would be nice to be able to visually plug a lambda into higher order function. Bonus points if it has some notion of reactive or data-flow programming built in :-)
I'm using Blockly to teach basic programming concepts to 6 and 7 years olds in my son's class. I'm using the maze at blockly-games.appspot.com/maze .
So far, my results are pretty promising. I do two groups of two kids at a time, so I can give them tons of help and advice, and for the hardest levels they tend to copy ideas from the other group, but so far both sessions they managed to solve it all the way up to the end (with my help). Coolest part is that their solution for left-hand-search is always slightly different (and more elegant) than what I'd originally come up with.
I haven't created my own material yet, but I suspect I might want to do that at some point.
Does anyone have a link to the history of this specific visual style? I know the MIT Scratch project uses the same visuals and I've seen a few other as well. I've very curious about the history here.
40 comments
[ 2.9 ms ] story [ 94.3 ms ] threadNotable project: https://www.codeforlife.education/rapidrouter/ (developed by Ocado) and here's the github https://github.com/ocadotechnology/rapid-router. I've developed a couple of features and I have to say it has been a fun experience!
I cannot say I was ever satisfied in in every context where I saw this model applied. My experience ranges from trivial languages such as this, to compositing software, DAWs or something more sophisticated such as programming-oriented signal generators (where blocks are often used as filters/generators and edges as I/O connectors), to workflow editors...
It "might" look intuitive at first[1], but the network just becomes unreadable as soon as you have more than 10 nodes or non-linear behavior (with edges eventually crossing). Auto-layout just becomes a major problem to be solved. Auto-layout also destroys the visual locality of your program, so it actually goes against the programmer for anything non-trivial. Manual layout is something I do not want to take care of either.
Is any experiment or research being done that goes in a _different_ direction?
[1] I would actually say "less scary". I'm not convinced a simple programming language in the spirit of "BASIC" is less difficult to comprehend in the technical sense.
[1] https://computinged.wordpress.com/2015/08/17/icer-2015-block...
It works for DSLs in video-compositing apps , "learn to code apps" , yahoo pipes like apps or VST plugin coding apps ( and to a certain extend you could argue that working with DAWs is programming, I mean Logic has some kind of visual programming environment, so does Ableton Live)
It doesn't work for anything complex that would be normally be done via typing actual code.
I mean it has always been the case.IMHO Anyone that says he can invent something that can replace typing instructions in a text editor[1] and give a better experience to a professional programmer that way is lying.
But VISUAL PROGRAMMING is great for learning how to code, I learned coding, OOP and all that stuff in Flash 15 years ago, dragging and dropping some stuff and seeing the result visually in a matter of micro seconds was enjoyable, felt rewarding and motivated me to explore programming further. It was a shoehorn into the world of programming.
1: It doesn't mean one cannot improve text editors and IDEs, I think there is a whole LOT of room for improvement in order to make typing programs painless, and I'd like to see more research and experimentation done in that specific area, because it feels to me we're still stuck into BORLAND era when it comes to IDEs and nothing has evolved since that time.
It might not be a completely professional grade platform, but I think it's a good proof of concept of how plain-text programming can build good sig
For instance, in a video-compositing application (something like nuke - to put a name) it makes sense, especially so you can represent/preview the state of the filter in the block itself, but it's far from being an efficient method to input or manipulate. If you have experience by programming in any classical language with a grammar, it should be self-evident.
I find myself thinking I could represent the same graph in a much more compact and logically structural way using a written grammar, albeit doing that loses some given visual aspects like previewing.
I was explicitly asking if there is anything else available.
It's analogous to putting all your code in a single source file versus splitting it into logical components across multiple files.
There is something nice about being able to organize the flow of process and logic in a spatial way. It's easier for me to recover from a 1 year break on a grasshopper script than a 1 year break on a typical code base.
https://en.m.wikipedia.org/wiki/Alice_(software)
[1] http://drakon-editor.sourceforge.net/language.html
[2] https://news.ycombinator.com/item?id=10100932
Circuit-based skins work well in the right context. Do a Google Image search for "unreal blueprints" to see many examples of them in use. Blueprints visual scripting probably powers the high-level logic in a video game you or someone you know has enjoyed.
The other popular approach is fill-in-the-blanks, a visualization that looks more like a tree than a graph. The first good version of this I saw was the Warcraft 3 scripting system. It inspired the visual scripting system we built for Tribes, SWAT, and the first Bioshock back in the day.
You can also follow Eve for some modern experiments along these lines: https://github.com/witheve/Eve
The classical example I give when I ask this question, is how do I represent the concept of an abstract "record" (or structure) in any visual language. How do I convey the mapping from definition to instance of any given construct?
These are though problems to represent in a visually compelling and useful way.
Or for iPads there is the Tickle app: https://tickleapp.com/
and of course the code.org site which I believe uses Blockly: https://code.org/
Source: I worked on the original "Hour of Code".
Source Code: https://github.com/code-dot-org/code-dot-org
https://www.allcancode.com/runmarco
(in the CWS https://chrome.google.com/webstore/detail/run-marco/objdeaib... )
Worth checking out if you have a child and you're looking for a lightweight web based programming intro.
So why not just use python combined with a normal editor instead?
Let's you switch back and forth seamlessly as you learn. Among other features.
https://i.imgur.com/B6qFqww.gif
The blocks nest four deep. It's a good illustration of how hard hard it is to make graphical programming easier than regular programming.
[1] https://blockly-demo.appspot.com/static/demos/plane/index.ht...
https://blockly-demo.appspot.com/static/demos/code/index.htm...
It would be nice to be able to visually plug a lambda into higher order function. Bonus points if it has some notion of reactive or data-flow programming built in :-)
Is there something like that?
So far, my results are pretty promising. I do two groups of two kids at a time, so I can give them tons of help and advice, and for the hardest levels they tend to copy ideas from the other group, but so far both sessions they managed to solve it all the way up to the end (with my help). Coolest part is that their solution for left-hand-search is always slightly different (and more elegant) than what I'd originally come up with.
I haven't created my own material yet, but I suspect I might want to do that at some point.