What's the general consensus on node based scripti...
# thinking-together
n
What's the general consensus on node based scripting? I'm intrigued by Unreal's Blueprint node based scripting tools - they seem easy to use, but if you want to do anything complex then (for me) it becomes very messy very quickly. However with the general move in the past 10 years or so to more functional programming and serverless etc then perhaps it makes sense. Small components that can be wired together visually feels easy, or right? Darklang is another example with extrapolates the complexities of the underlying system allowing you to just write some pseudo node based (at least when I last looked at it) components that are easily wired up together. I'm an iOS engineer by trade, and it feels that something like Darklang / node based coding could end up matching nicely with SwiftUI's declarative syntax for UI.
m
The main benefit of node based programming, or "node and wire", in my observation, is that is saves users from parsing. Mentally parsing code into an AST is difficult. It requires literacy. Node-and-wire makes the parsing explicit. The downside is that reading and writing the graph is much less efficient for a literate author.
w
If it's just parsing, then block-based or structured editors should have the same advantages. A potential advantage of a node system (though maybe not realized in practice) is using layout so that some conceptual aspect of the system is well modelled: often nodes below depend on nodes above. Compare with the text of say imperative programs text in which conditional branching gets squished and functional programs are often worse with the conceptual reduction tree split up across lots of definitions. More than anything, I think node based systems have extra space to interweave intermediate results with the authored scaffolding.
n
I wonder if it also makes you code in a different more modularised way. Smaller chunks of code rather than sprawling classes. It’s a mindset shift of course, but it may make your code “better”
v
We have been building a live programming environment with a node based visual model for the last 6 years now. There are a few advantages which text based systems dont have, IMHO: 1. Reuse by bringing in visual blocks that are prebuilt. 2. Unified interface for multiple aspects such as for performance, debugging, inspection of state and live values along with programming. 3. Zoomability (we are not yet doing this) : Different tiles can have different levels of zoom, and that can make for a very interesting interface. We have built a good number of production apps using our own platform, so the pros and cons of the approach are quite well understood by us. For things that are assembly oriented (composition by reusing work done by others, I think visual programming is quite elegant). For algorithmic thinking it would need to be augmented with other modes (in our system you can write new functions in any language that compiles to wasm, plus also write web components and bring them in).
i
+1 to what Vijay said about modularity and reuse. Generally a smaller command set means more distinction between elements (different colors and shapes for values, functions, math). Dragging out a node highlights where it could go and “type errors” if connected wrong. That’s more difficult as an environment becomes more open (less predictable ). Unreal’s primary target has been large game studios, where there are often developers writing algorimic code but outputting nodes to be tuned by other teams. Bolt is an interesting example where both happen at the same time. None of this is unique to nodes; though they might give a better spatial view
j
I think the main benefits of node based programming is in control and data flow readability, debugging and live programming. It's natural to fit in rich node visualizations like enso.org does. However, I feel that you'd always want the node based language to be domains specific. Just projecting a general purpose language to nodes leads to too large graphs, low productivity and bad maintainability. And you should always be able to type in arithmetic expression. Much easier to read and type " 1 + 2 * 3" than have 5! nodes on the graph. Actually I think that it would be best for text to be the primary editing tool, but then have a generated graph for visualization and debugging.
i
I should mention, there were also a lot of interesting thoughts from a similar question I had a few days ago https://futureofcoding.slack.com/archives/C5T9GPWFL/p1676896876997549. @Niall McCormack
u
Hey, I'm making an node-based editor that incorporates a lot of ideas from FP. Check it out at https://nodysseus.io/
I also spent some time in the VFX industry, and worked with Unity's mess of node editors. For the three.js integration it draws a lot on Houdini / TouchDesigner.
One of the biggest design decisions I made was to force a tree layout, so multiple inputs, single output (like a FP function). This lets the tool auto-layout the graph. It also makes it easier to collapse a bunch of nodes into a subgraph. So far I'm working with programs that would be a huge text file but feel better to me in nodysseus because I remember visually where everything is.
While I'm focusing on three.js at the moment, I do think there's power there as a general programming language. On the desktop, code will still be more efficient, but on phones and tablets, text editors are really clunky. Nodes let the programmer abstract and autocomplete a lot of programming concepts away from the keyboard.