Nice to see another cracking the 'nodes and strings' style of programming. However, as is I don't see a strong future for this one. It looks like it has replicated the ideas of many which have gone before without significant evolution. The long history of 'nodes and strings' for general programming shows that it isn't going to catch on in the current form.<p>Some problems in no particular order:
* The presentation logic and execution logic of nodes are mixed together in the same python class.
* Information density. Nodes and strings just can't fit enough on the screen.
* Independent editor which doesn't integrate with other code editing tools. All the niceties of an established text editor or IDE have to be given up.
* In my opinion 'get var' and 'set var' leak too much of the text based code paradigm into the flow paradigm.
* It only outputs python, which already has a low barrier to entry. Outputting C or Rust or LLVM IR would make the product much more interesting.<p>However, after all the criticism, keep going. There is a future hidden somewhere inside this type of coding, it just hasn't been discovered yet.
Although low-code has been popular these years, I don't see the application of this.
The main problem is that low-code should be application-specific. For anyone who want to make use of this platform, he is probably proficient in Python enough to directly write the code - which is faster and more convenient. Python is already simple enough for you to write out without the need to worry for consequences.
To each their own, but I tried messing with this type of dev a couple years ago on a project using Unreal and Blender. To me it seemed to make easy things hard and hard things nearly impossible, while simultaneously being a nightmare to track changes and undo mistakes.<p>I assume I'm missing something given its popularity but I personally am in no rush to use this style of development again.<p>To me, the problem being solved by low code tools should be focused on formatting and syntax. That's what always trips up non devs. They just don't get why capitalization, spacing and special characters always need to be so perfectly placed, with so many arbitrary rules, like functions use commas to separate parameters, but for(), which looks exactly the same, uses semicolons. Why? Reasons. New coders hate it.<p>TouchDevelop by Microsoft Research really nailed this problem years ago. Turn the commands and variables text into clickable objects so new coders can focus on the logic and program flow - still using "text" like normal coding - but without worrying about the syntax. Too bad it died.
Without studying it too hard, I think this could work well in geospatial python. Often an output has several input datasets that flow into each other that leads to a final output. I guess model builder is similar solution but its in the qgis environment.<p>I could maybe see myself using this. Maybe drawing a low res plot of each dataset as it works through the flow for visual checks.<p>Its an interesting take. Good stuff.
Ryven came up a couple months ago in the comments about a similar tool, PyFlow<p><a href="https://news.ycombinator.com/item?id=29955623" rel="nofollow">https://news.ycombinator.com/item?id=29955623</a>
One problem here is that they show it off first with images, which basically makes it a very awkward and slow compositor. If you want to work with images there is already Nuke, Houdini and Touch Designer.<p>Using nodes to manipulate images hasn't been a problem for a few decades. They need to show more general cases, how to iterate, how to debug, how to manage state, how to manage errors, etc.