5 ms·
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 i
by trothoun 13y ago
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 13y agoHold 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 13y agoCan 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 13y agoI 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.
- peetle 13y agoExactly. The node is just a lambda - no reason it can't be expressed in exactly the same way.
- seanmcdirmid 13y agoLambdas are formal, not linguistic constructs.
- sparkie 13y agoI 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.
- seanmcdirmid 13y ago
- seanmcdirmid 13y agoVPLs 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 13y ago"communication in an abstraction-dense format that isn't based on words" Animated GIFs, perhaps. :)
- peetle 13y agoYou should definitely check out the work going on in Dynamo right now: https://github.com/DynamoDS/Dynamo 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.
- columbo 13y agoI 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 13y agoMany 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.
- ericHosick 13y agoI 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.