Flood: Geometric visual programming, driven by a Scheme interpreter
floodlang.com.s3-website-us-west-2.amazonaws.com
floodlang.com.s3-website-us-west-2.amazonaws.com
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.
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.
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.
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.
The lambda calculus is great at describing computation formally, but says nothing at all about programmer ergonomics. What we really care about is the abstraction capability of "node" or "word", the implementation is encapsulated.
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.
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.
[1] http://www.slideshare.net/slidarko/gremlin-a-graphbased-prog...
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.
Animated GIFs, perhaps. :)
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.
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.
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.
On a serious note, there are some domain-specific programming tools in which visual approach works well. For example functional protocol testers (with SDL) or data acquisition (LabView and such).
The project is largely inspired by this one, whose original engine used a similar approach of compiling a visual program to Scheme: https://github.com/DynamoDS/Dynamo
what am I expected to do here?