Difference between revisions of "Node editor"
(→External links: added link to enso landing page) |
m (→Related) |
||
(6 intermediate revisions by the same user not shown) | |||
Line 117: | Line 117: | ||
= Related = | = Related = | ||
− | * [[Projectional editing]] | + | * [[Projectional editing]]. A [[node editor]] can be a form of a projectional editor. |
* [[Purely functional programming]] | * [[Purely functional programming]] | ||
− | * [[Annotated lambda diagrams]] and [[Annotated lambda diagram mockups]] and [[Lambda diagrams ]] | + | * [[Annotated lambda diagrams]] and [[Annotated lambda diagram mockups]] and [[Lambda diagrams]] |
= External links = | = External links = | ||
+ | |||
+ | * Wikipedia: [https://en.wikipedia.org/wiki/Node_graph_architecture Node graph architecture] | ||
+ | |||
+ | == Projects == | ||
'''enso (formerly luna):''' | '''enso (formerly luna):''' | ||
Line 143: | Line 147: | ||
* Docs: https://docs.blender.org/manual/en/latest/modeling/geometry_nodes/index.html | * Docs: https://docs.blender.org/manual/en/latest/modeling/geometry_nodes/index.html | ||
---- | ---- | ||
+ | '''Nodezator''' by Kennedy Richard | ||
+ | * landing page: https://nodezator.com/ | ||
+ | * github: https://github.com/IndiePython/nodezator | ||
+ | ---- | ||
+ | '''Unit – Visual Programming System''' <br> | ||
+ | This is atop an unusual programming language core: <br> | ||
+ | "Multi Input Multi Output (MIMO) Finite State Machines (FSM)" | ||
+ | * github: https://github.com/samuelmtimbo/unit/ | ||
+ | * https://unit.software/ | ||
+ | ---- | ||
+ | 2023 – '''Multiple-Representation Visual Compositional Dataflow Programming''' <br> | ||
+ | https://michael.homer.nz/Publications/PX2023 <br> | ||
+ | This bridges over to concatenative programming which <br> | ||
+ | also has a more kind of tabular alternative [[projectional editor|code projection]] <br> |
Latest revision as of 11:11, 8 September 2024
Also called box-and-wire programming visual/graphical programming.
Contents
- 1 Usual advantages of node editors
- 2 Related
- 3 External links
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.)
- https://twitter.com/mechadense/status/1235650692297064448
- https://twitter.com/mechadense/status/1235645491255414789
Related
- Projectional editing. A node editor can be a form of a projectional editor.
- Purely functional programming
- Annotated lambda diagrams and Annotated lambda diagram mockups and Lambda diagrams
External links
- Wikipedia: Node graph architecture
Projects
enso (formerly luna):
- landing page: https://ensoanalytics.com/
- X-platform: https://x.com/enso_org
Historic:
- http://staging.luna-lang.org/
- https://x.com/luna_language
- https://x.com/FlowboxIO
- https://www.youtube.com/user/flowboxIO
Crosscut – crossover between node editor and (computational) graphics canvas
- landing page: https://www.inkandswitch.com/crosscut/
- video: https://www.youtube.com/watch?v=ifYuvgXZ108&t=1814s
PANE by Joshua Horowitz – https://joshuahhh.com/
- landing page: http://joshuahhh.com/projects/pane/
- video: https://www.youtube.com/watch?v=Kp6YqmMxqKA&t=2169s
Blender geometry nodes:
Nodezator by Kennedy Richard
- landing page: https://nodezator.com/
- github: https://github.com/IndiePython/nodezator
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