[tenfingers]

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.

[aikah]

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

[tenfingers]

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.

[golergka]

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.

[moron4hire]

Check out CHucK some time. http://chuck.cs.princeton.edu/

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

[aikah]

How do you think Reaktor itself is coded ? that's the point I made in my comment.

[golergka]

What does this point prove? The point of visual programming is in user experience of completing appropriate tasks.

[cloudmike]

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.

You can also follow Eve for some modern experiments along these lines: https://github.com/witheve/Eve

[tenfingers]

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.

[cloudmike]

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.

[fiatpandas]

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.

[7952]

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.

[rzzzt]

I think DRAKON solves the layout problem quite well (the specification also tries to cut down on excessive use of arrows).

[1] http://drakon-editor.sourceforge.net/language.html

[2] https://news.ycombinator.com/item?id=10100932

[igravious]

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.

[mediumdave]

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.

[1] https://computinged.wordpress.com/2015/08/17/icer-2015-block...

[ss_justin]

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.

[theideasmith]

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!

[steve19]

Have you looked at Alice?

https://en.m.wikipedia.org/wiki/Alice_(software)

[techdragon]

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.

[CyberDildonics]

Microsoft Excel (stolen from Chris something that is making a visual programming environment).