Visual programming has the potential to be really useful ... but I haven't seen anyone get the UX quite right just yet (although a few have come close). I spen

Visual programming has the potential to be really useful ... but I haven't seen anyone get the UX quite right just yet (although a few have come close). I spent a few years programming mainly with Simulink, and more recently have experimented a little with some graph-based game engine UIs. (Unity shader graph etc..) Now, as far as Simulink is concerned, I feel that it was (and possibly still is) an ergonomic disaster zone. There's just too much mousing around and adjusting routing between nodes. Also, merging is really difficult because of the save file format. This is a significant problem for many engineering organisations. For any visual programming tool, the value of a visual graph diminishes as the graph becomes more complex. It is most valuable when it is kept simple and illustrates e.g. high level components only. Now ... none of these problems is insurmountable, and having a relatively simple high-level graph to show the relationship between the major components of a system is an incredibly valuable communications tool -- but users do need to resist the temptation to use the graph for everything down to every if statement and for loop. These things are best used to explain the high level relationship between major system components and the overall flow of data through the system. Fine grained algorithms are better represented textually. So, over the years I've developed a configuration-driven framework that's designed to (eventually) be driven from a visual UI. Computationally, the framework implements a Kahn process network. I.e. it's a dataflow model, where the nodes represent sequential processes, and the edges have queue semantics. (The queue implementation can be replaced with implicitly synchronised shared memory in some situations, so it can be quite efficient). This enables me to e.g. implement intelligent cacheing of data flows, support record-and-replay style debugging, co-simulation, and automatic component-test generation. The nodes can be arbitrary unix-philosophy binaries, Python functions, or native shared libraries. (Eventually I plan to support deploying nodes to FPGA as well), and because of the Kahn process network semantics, behave in the same way irrespective of how the nodes are distributed across computers on the network. This makes it an ideal rapid-prototyping tool for quickly integrating existing software components together. E.g. throwing machine learning components together that have been written in different languages or using different frameworks. It's a bit like ROS in this regard. The dataflow graph itself is represented by a set of YAML files (or data structures that can be generated/modified at runtime), with different aspects (connectivity, node definitions, layout) separated to make textual diffs and merges easy to understand, and enabling teams to work more effectively together. Also, because the graph is explicitly represented as a design-time data structure rather than being a runtime construct, it's easy to use GraphViz to generate diagrams, allowing you to have documentation that's correct by definition without spending ages adjusting untidy connections and layouts. (Although I do want to spend some time improving the layout algorithms and providing some mechanism for layout hinting). Right now, you can only generate the visual graph from the textual description. In future I want to make it possible to edit the graph visually, so you can (for example), drag and drop compute nodes onto different computers really easily; stop, rewind and replay history, and simulate the effects of e.g. network contention and experiment with moving nodes around the available hardware to optimise performance. I'm also experimenting with hybrid symbolic/statistical AI techniques that use the data flow graph to help with fault finding, automatic safety-case generation etc.. etc..