Node editor

From apm
Jump to: navigation, search
This article is a stub. It needs to be expanded.

Also called box-and-wire programming visual/graphical programming.

Usual advantages of node editors

Node editors usually enforce referential transparency, purity, statelessness.
just like in purely functional programming languages. With the same benefits.
Most notably is mathematical refactorability of code.
As is Substitutability. Easy factoring out of code duplication.

The "wire-kraken" problem

Lack of ability to hide complexity.
Some older node editors even lack the ability for user-defined functions as sub-node-graphs.
Beyond mere grouping of nodes. Many node editors support that now.
Though it's usually an all or nothing for hiding the immediate surrounding computational call context.

This problem is aggravated by an other usual problem of node editors of the past.
The limited expressiveness problem. As workarounds to this problem tend to significantly increase complexity.

Limited expressiveness (boosting wire-kraken)

Some problems are hard to model in most existing node editors. Why?

As node editors usually share the referential transparency property with
purely functional languages they face similar challenges.

Purely functional languages usually (with few exceptions) make up for the absence of recursive mutability
in part by supporting higher order functions.
I.e. functions that take functions as arguments and or give functions as return type.
(callbacks, continuation passing style, functional reactive programming, and simpler things)
Recursion packaged in names of what they do structurally replaces for loops (map, fpold, scan, zipWith, …)
Preferably tail call recursion.

Unfortunately node editors rarely support (their direly needed) higher order functions
as they often strictly adhere to the "wires are values and boxes are functions" metaphor.

This leads to some strange workaround blossoms.
Taking blender geometry nodes as example:
– a copy of all operations for list/array types (less or more consistent).
– dedicated "simulation nodes" rather than an iterate function

Bad support for code documentation

Node editors often feature bad support for documentation.
No way to attach documentation to individual noses in usage context.
No way to attach documentation for a node graph as a function without specified context.

Node/Box position meaning(lessness)

Sort of meaningless positional information:
Position of nodes/boxes carries no inherent meaning and is just metadata.
Usually arranged for easy readability
– minimizing number of wire crossings
– putting related parts close together
– mimicking the geometry of an actual physical geometry
Or using auto layouting approaches
– force field based (often makes thing less readable)
– auto routing approaches (some heuristics, nowin 2024 AI might help here)
Node/box positions are meaningful for readability and documentation.
Not for code compilation and execution.

Low information density

Compared to textual code node editors have a rather low
on screen areal information density.

There's no way around that other than mixing node-editors with other more information dense projectional editor.

Context visualization and connectivity visualization

Only showing the code universe not the code multiverse

Node editors usually do not give (progressive disclosue) access to:
– Alternate call contexts (inactive form other code, live with same code but other data)
– memoization of overlapping sub-problems

The glowing thread of execution through the stateless timeless code multiverse.
Related: Edit time immutability.

Linking outputs directly to inputs

Conflation of function abstraction and function application:
I.e. in node based editors outputs are directly connected to inputs.
This is kind of part of the definition of a bode editor.

This is not the case in annotated lambda diagrams
where flowing a node (with nodegraphinside) through a wire comes more natural.
(TODO: Find out of the consequences of this in more detail.)

Potential Improvements

Provide better support for documentation. Per node and per node-graph.

Make higher order functions first-class-citizens (i.e. treat functions identically to values).
In other words: Make boxes and the wires going out mean the exact same thing.

Beyond custom function definitions:
Support showing visual surrounding call context (super-context & sub context). Inverse tabs for call contexts.
Support showing alternate upstream call contexts too for mind-bicycle-walks through the codebase-graph-multiverse
Ideally both in inactive and live-coding context.

Support both in-place-preview and out-of-place previe of For dependency functions that are called in the node graph:
– support in-place-preview. Inverse tabs for call contexts.
– support out-of-place-preview with indicate visual funnels (show memorization sharing)

Use an projectional editing approach with a code AST as core representation.
Ideally per function hash addressed.

(wiki-TODO: Add existing sketches for these ideas. The ones for now merely linked below.)

Related

External links

Projects

enso (formerly luna):

Historic:

Crosscut – crossover between node editor and (computational) graphics canvas

PANE by Joshua Horowitz – https://joshuahhh.com/

Blender geometry nodes:

Nodezator by Kennedy Richard

Unit – Visual Programming System
This is atop an unusual programming language core:
"Multi Input Multi Output (MIMO) Finite State Machines (FSM)"

2023 – Multiple-Representation Visual Compositional Dataflow Programming
https://michael.homer.nz/Publications/PX2023
This bridges over to concatenative programming which
also has a more kind of tabular alternative code projection

Retrieved from "http://apm.bplaced.net/w/index.php?title=Node_editor&oldid=16779"