[trothoun]

Demos like this are cool, but they make me think that we'll never see a non-toy visual programming tool. Even a fairly simple bit of logic quickly becomes an incomprehensible soup of interconnections.

edit: Thinking about it a bit more, whats lacking in all the examples of visual programming I've seen is a clean way to build abstractions. It would take a while to learn to efficently read and style visual code just like it does with text based code. That I think i could get used to. The thing that I find alarming is the prospect of manipulating an ever growing graph.

[pjackson5]

Hold on a sec, I stare at graphs like this all day! If you work in visual effects your whole world is nodes and connections - and that is not a complicated graph ;) For someone whos not used to programming a big wall of text is going to look messy and incomprehensible too.

Just like there are best practices with code there are best practices with how you organise this kind of graph. you can usually save a subnetwork into a single node that has a clear input and output. ie, double clicking on a node will take you to another network with a clearly defined purpose. Im obviously better at these graphs than I am a programmer, but it seems to me that doing it this way actually encourages encapsulation and abstraction.

Theres also some good stuff about these graphs that I think coders can miss out on. With a graph you can use the idea of space to organise things. Our brains have a natural ability to remember where things are in space. Its like organising things on your desk, I have a pencil here , my notepad here, books in the drawer, it feels very naturall to have things laid out in space, you remember where you put them. With a graph I know that all the stuff in the top right does one task, im outputting data out the bottom etc..

It works really well when you have clear input and output. Again Im not the best programmer but I think after using these graphs for years I instantly got what people are talking about when they are promoting functional programming. I think these networks have a place where you are creating operations to do on existing things.

[seanmcdirmid]

Can you communicate in graphs? Can they be used to express metaphors or abstractions? You've just written a wall of text in your post that someone who doesn't understand English will find messy and incomprehensible.

Visual formats are great at some things, especially in expressing concrete concepts that are perceptible. They are just not great at abstraction, which forms the basis for most of our non-trivial programming tasks.

Functional programming is quite interesting because it is not based on our linguistic capabilities, but rather a very different form of mathematical abstraction. Incidentally, many people find OO easier to grock because it leverages our intrinsic language skills.

[pjackson5]

I might be out of my depth and not truly understand what is meant by abstractions, but I think the answer is yes?

Lets look at the example on the website, theres a node called cube. Isnt that little node an abstraction of a whole lot of other things? A more advanced visual programming language would allow you to access and modify what a "cube" is. You would be able to double click on that and be taken to another graph. This graph would be about the construction of a cube and would take input of width and create triangles in space to represent a cube. you could double click on the triangle node and be taken deeper, this time a node that takes vectors and defines where the surface is between them and sends it to the renderer. We could have a seperate graph to define what a vector is and the data structures behind it.

All of this for a simple cube could be represented as a huge tangle of nodes and connections, but we can condense it down to a single node called cube that takes an input of width. Having networks and sub-networks allows you to choose what level of abstraction you work at. Each of these things at different levels can be represented by a graph.

[seanmcdirmid]

Abstraction != encapsulation. The point is about the node, not its contents. What does the node mean as a metaphor? What is it's idea?

Language is a very powerful technology that nature evolved for us. We could not have this conversation with graphs or paintings...we need words! Many programming problems are also best solved with words, though you could definitely wire something up the old fashioned way.

[tunesmith]

Can't this same criticism be made about (word-based) programming languages? Programming languages communicate the what or the how pretty well, but not the why.

[seanmcdirmid]

I never said anything about why. Even if you are just instructing, do you care to see a wordless video or read an instruction manual? Actually it's not even that...which one is easier to write? The descriptive power of language is great when issuing imperatives; it must have been very hard to organize before language was developed 50-100 kya.

You can still communicate spatial concepts better with pictures, and maybe a hybrid approach might work, structured edited languages are very popular as vpls, but think about code with interspersed diagrams.

[peetle]

Exactly. The node is just a lambda - no reason it can't be expressed in exactly the same way.

[seanmcdirmid]

Lambdas are formal, not linguistic constructs.

[sparkie]

I think you're making a distinction that doesn't exist: lambdas are a (written) language - the have symbols, morphemes, phrasing, syntax, semantics, pretty much all the elements to define a language. Just an incredibly small and concise one.

[shotwell]

Then so much for graph based programming?

[1] http://www.slideshare.net/slidarko/gremlin-a-graphbased-prog...

[peetle]

You should definitely check out the work going on in Dynamo right now: https://github.com/DynamoDS/Dynamo We've put a huge amount of work into this problem.

Dynamo has the notion of a "custom node." This is essentially a lambda. It is represented by a "nested" set of nodes, making up the function body.

There's a bunch more stuff going on there - including compiling nodes to a domain specific, associative language called DesignScript.

[seanmcdirmid]

VPLs are well known to be challenged by what Burnette et. al (the principle behind Forms/3) calls the scaling up problem.

The problem is that language is great at metaphor, which is the basis of abstraction. For better or worse, language is based on words, and we have specialized hardware (in our brain) optimized for it. Until we evolve communication in an abstraction-dense format that isn't based on words, I don't think we'll be able to scale VPLs.

[al2o3cr]

"communication in an abstraction-dense format that isn't based on words"

Animated GIFs, perhaps. :)

[ericHosick]

I think a lot of people try to take a "one mental model fits all" approach to visual programming: and coding in general.

Sheet music, source code, mathematical equations, graphs, etc. are examples of tools we use make it easier to form mental models.

> It would take a while to learn to efficiently read and style visual code just like it does with text based code.

This is why domain specific VPLs work so well: because they allow people work within a mental model they are already familiar with.

[columbo]

I think to really get visual coding to work it would need to start from circuit design; Vin, Vout, ICs, logic gates etc.

That doesn't really get you towards end-users writing code but I'd find it pretty useful when trying to look at a complicated process.

[nabla9]

Many circuit design tools have the ability to use either visual circuit diagrams or VHDL. Visual diagrams are useful in many cases, just like UML diagrams, but using only them would be pain in the ass.