@Kartik Agaram It's hard to answer that without enumerating all the zillions of ways that previous systems have failed 🙂! But I think there are a few major categories of requirements, without which a system will fail at being a widely accessible, general purpose visual programming language. So put another way, the topic is "what does a system need in order to hit the mark of doing for programming what GUIs did for all other software in the 80's and 90's?" - Node and wire. - This is the current best way to visually represent general proceduralism. I'm convinced of this after spending over 11 years working with mature tools of this form, and seeing how successfully they're used by non-technical artists. There might be a better way to visually present proceduralism, but if there is, I'm fairly certain it hasn't been invented yet. Wizards and Scratch-clones are common approaches which are clearly, inescapably inferior. - Domain agnostic. - No one would use a programming language that only allows images as a data type (for example), or only 2D tables— they would be niche tools. We probably wouldn't even call them programming languages. But this is the state of affairs for almost all existing node-and-wire tools. It needs to be possible to operate on any kind and shape of data. - Extensible / complete. - It must be possible to process things in ways the language designers didn't anticipate or explicitly design for. In fact, there cannot be any kinds of processing that are impossible to express; the test for this is "Turing completeness". No one would use a programming language if it had a fixed set of functions, and you couldn't add any more. Also, the Turing completeness needs to be usable and purposefully designed— "accidental" Turing completeness doesn't count! - Closed. - The expressiveness, flexibility, and extensibility of the system needs to be fully expressible within the system. Imagine if, in Python, the moment you needed to iterate something, you had to leave Python and write a C++ plugin— No one would use it, and as a programming language, it would barely be useful. Sadly almost every node-and-wire tool, if it is extensible, is not closed. (Allowing extensibility into other systems is permitted, but it must not be necessary in order to express all possible kinds of processing). Many systems fail on this count by making a second, internal system which is not visual— i.e., exposing a textual DSL or even an entirely different (ubiquitously textual) programming language. Note that the external system being "nested" in the presentation of the main system does not constitute the main system being "closed"! For many/most users, crossing that barrier into the outer system is difficult enough that it is equivalent to the external system simply not existing, and the functionality sequestered within being unattainable. - Functional. - This arises from the necessity of node-and-wire. Node and wire systems which model something other than expression composition (like control flow, e.g.), or where nodes have effects on each others' operation that aren't represented by wires, are (fatally) too confusing to reason about. - Well-designed UX. - There is a lot of room for creativity inside the space of this requirement, but many systems fail to get there at all. Some of them fail very badly indeed (e.g. ). Many visual effects node-and-wire systems (like Nuke, for example) have mature and well-designed UI (though there is still much room for innovation or improvement), but fail on basically all of the remaining bullets.

I agree with every word of this. This is the page I'm on. I'd add some things to it, but they're closer to things I suspect are true, rather than things I believe to be true (as are all the things you said.)

For a VPL all of this makes a lot of sense, but I fear going from where we are now straight to a VPL (emphasis on the "language") would have us burn too many bridges. When I show Flowcode to devs, they usually watch in horror, until I utter the magic words "it's just a way to organize your code". And that "it just happens to be wrapped into something that to a large extent, behaves like VPL". I'm wholeheartedly on board with node & wire, domain agnosticism, extensibility, FP, and top-notch UX. But if we set out to build the first successful tool that makes a dent in how people code, we can't afford to make it closed.

I think node-and-wire is a horrible UI, but maybe I haven't played with any of the good ones. You say that LabView fails badly. "Many visual effects node-and-wire systems (like Nuke, for example) have mature and well-designed UI". Please give additional examples. Are any of the good ones open source?

@Dan Stocker: "Closed" doesn't mean that you must do everything inside the system, only that you can. More clarification given in the next thread down 👇 . I probably need a better word than "closed" (suggestions welcome). If you're arguing that developers won't jump over in droves to a purely visual system, you are right! They won't, at least not at the beginning. Developers already have high-power tools at their fingertips; a visual tool won't offer them much unless it is extremely mature. Probably the biggest fallacy a VPL could make is trying to make something that devs like— the entire problem is every existing tool is built for the kind of person who we are currently calling devs. If we want to open up coding to lots more people, the goal has to be to make a tool for people who aren't them. If we're seeking their approval, we are asking the wrong people! My project is explicitly targeting non-coders first, because those are the people who will be chomping at the bit for a tool that lets them do what programming does. Over time, the tool will mature and expand in capability until it starts to become appealing to old-world devs too.

@tbabb Thanks! With that clarification, there's nothing really to argue about. 😄 Some clarification on my part: I agree that professional developers are the least likely to become early adopters, I'm just not comfortable shutting them out completely. I don't know where the breakthrough will happen, and I'd go out on a limb and say none of us do. What I mean re. comparing low-level dataflow diagrams and textual code, is basically this. Will non-technical coders be comfortable implementing a loop with nodes & wires? I know I'm not. Finally about high-level nodes, what I mean is we'll end up giving them those regardless of whether addition is a node in its own right or a + b expressed with code. (Now, if a standalone addition node is something that's useful in a certain domain, it should of course be part of the library.)