[HN Gopher] Nodezator is a generalist Python node editor
___________________________________________________________________
Nodezator is a generalist Python node editor
Author : mariuz
Score : 173 points
Date : 2024-11-29 15:14 UTC (1 days ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| tecoholic wrote:
| Love the auto connection graphics choices :)
| tgv wrote:
| Yeah, that's a nice solution. I hope there's something as
| clever as that for long distance connections. One of the pain
| points of graphic programming is large panes with lots of
| nodes.
| jamilton wrote:
| The hand-holding and the ball toss are both super cute.
| samlinnfer wrote:
| Is this in anyway related or inspired by ComfyUI
| stavros wrote:
| Node editors aren't new, ad Comfy isn't a particularly
| innovative example, so this would be like asking if the Honda
| Civic was inspired by the Skoda Fabia because they're both
| cars.
| doctorhandshake wrote:
| To be fair, this looks extremely similar to the comfy node
| editor. Would be a little more like asking if the Ford Fusion
| and the Lincoln MKZ are related because they look a hell of a
| lot alike from the outside.
| throwaway314155 wrote:
| It doesn't look very similar to me. No more similar than
| Unreal Engine blueprints. ComfyUI has a better design I
| think but again, it's borrowing from other projects in that
| respect (and i don't think they would deny that)
| dufzh wrote:
| like node-red?
| Towaway69 wrote:
| Node red is different since it defines message passing between
| computational units. It describes the flow of data between
| computational units.
| magic_hamster wrote:
| That's pretty cool. Not something I'd use for serious work, but a
| fun little toy nonetheless.
| Micoloth wrote:
| I have a few questions - Is this inspired/based on the Blender
| node editor package?
|
| Some stylistic choices look very much taken from there, even if
| some other details (eg font) look much more primitive
|
| - If it's not based on that, why?
|
| Blander has an Excellent Python-based cross-platform ui which is
| completely open source. I've always thought it's a crying shame
| that's not available as a package to build desktop apps. And I
| think it would be very good to take things from there, like their
| very mature graph editor
| WillAdams wrote:
| That last point is _very_ interesting.
| catapart wrote:
| Blender was my first thought here, too.
|
| A while ago, I was asked to write a plugin for Blender since I
| really liked the program. I looked into it but realized that it
| was a python-only situation and I really just can't stand
| coding like that, so I passed on it. But if I could get the
| python ecosystem without having to code like that - that's a
| really interesting prospect!
|
| Never looked in to its package size, as far as UI goes, but
| that does sound like something that could be interesting! I do
| wonder how different it is from imgui, but there could be
| something there!
| echelon wrote:
| It looks like ComfyUI, which is blowing up in the creative
| space.
| cyanydeez wrote:
| Animation nodes plugin for blender did wonders for
| understanding blender bedfore it was basically consumed by the
| core team by Jacques Locke
| rcarmo wrote:
| This is pretty amazing. I have so many ideas in what to do with
| it.
| dennisy wrote:
| Really? I thought it was very cool too, but had no idea what to
| do with it.
|
| Would be interesting to hear what you feel this is well suited
| for?
| rcarmo wrote:
| Well, LLM workflows, to begin with.
| teaearlgraycold wrote:
| Also basic ML tasks
| hhthrowaway1230 wrote:
| Great work, I love node based uis! I'm still looking for an
| isolated minmal python package that soly does the backend part of
| these graph node frameworks like comfy, n8n, or node-red. I.e
| loading json & serialziing, executing nodes. Which also includes
| the various ways of processing nodes. Like topology sort, node
| executing queues. If you all know something lmk!
| halfcat wrote:
| Say more. Are you wanting "Node-RED but for Python"? Or the
| non-UI parts that are accessible programmatically?
|
| I've had similar interests and realized I essentially needed
| two things:
|
| 1. Something like "FastAPI without the HTTP parts". Basically a
| request/response cycle with middleware functionality, where we
| run a registered Python callable in response to a JSON request,
| but where that JSON request can be from any source, like
| "pulled from a queue" or read from the command line, instead of
| "pushed from a web browser". For that I essentially pieced
| together a basic task registration decorator class with
| pydantic's `validate_call` decorator and let pydantic handle
| the serialization/deserialization. There are libraries like
| FastAPI, typer, Celery and others that do this, but they're all
| tightly coupled with specific transports. I want to be able to
| delegate to a developer "build a function that takes this JSON
| and performs this task and returns JSON", but not with HTTP
| (FastAPI), and I don't want to be required to add Redis to run
| some small task (Celery), and I do want the task to be callable
| by CLI (typer), but not _only_ CLI. It seems like there are all
| of these tools but none of them are loosely coupled enough to
| do this in a straightforward way.
|
| 2. Some way to run a directed acyclic graph (DAG) of those
| registered tasks. There are lots of tools that do this in
| varying degrees of heaviness (Airflow, Luigi, Dagster, etc),
| but for a lightweight solution this is built into Python with
| graphlib's TopologicalSorter. But the point here would be,
| whichever one of these you pick, it helps to have #1 available
| in a way that allows for generic "running approved Python
| functions from JSON".
|
| So I sort of have those parts of it roughed out, but now I'd
| also like a better UI for it, for instance to allow for a more
| high level dashboard red/yellow/green status of things, or to
| enable a less technical user to adjust the schedule of a
| registered task, and so on. Django's admin portal is a first
| step her but ultimately we'd need something more interactive to
| make it a team effort where more employees can contribute
| without needing to know Python.
| Towaway69 wrote:
| NodeRED has a very simple json format to describe flows -
| basically an array of objects with each object describing a
| node and its connection.
|
| If there were to be a commonality of formats between various
| node-based programming environments then an interchange
| between backends and frontends would be possible.
|
| I was thinking of creating a python interpreter for node red
| flows but stopped at things such as jsonata support and
| mustache template engine.
|
| NodeRED does make much use of its underlying NodeJS roots.
| siva7 wrote:
| For whom is this? Is this some kind of editor for low-code folks?
| throwthrowuknow wrote:
| Node editors are also a good way to quickly compose fairly
| complex programs or modules even for experienced programmers.
| Working with them also forces you to design good interfaces for
| your code and eliminate tight coupling that often plagues many
| code bases. They do have downsides especially when using them
| to create complex workflows where they tend to evolve into ugly
| spaghetti monsters but you can prevent that by moving those
| workflows to code once you've settled on a design. This library
| seems like it would make that easy to do.
| almostgotcaught wrote:
| > Node editors are also a good way to quickly compose fairly
| complex programs or modules even for experienced programmers.
|
| Experienced programmers use composition methods for their
| _complex_ programs that are much more _complex_ than
| connecting functions based on input and output. Well at least
| I hope they do.
| throwthrowuknow wrote:
| Man, HN really is full of shitty redditors now. Enjoy your
| bucket.
| Towaway69 wrote:
| If you understand unix pipes then node based programming can
| make sense, for example in the guise of node red.
|
| Think of nodes representing computation and lines the flow of
| data between distinct computational units and you have unix
| pipelines. This is what node red does.
|
| This editor is more complex since it's connects output to
| individual inputs.
| antman wrote:
| Very nice! It might be able to run on the browser with pygame-
| wasm/pybag
| pshirshov wrote:
| Manual graph editors are extremely counter-productive for any
| program with more than a couple of dozens of nodes. All the code
| structuring issues still apply but now you also have a graph to
| maintain. And also you have an underlying framework which you
| have to understand (like in Node-RED). And you have versioning
| issues. And it's hard or impossible to write tests. And it might
| be difficult to share code across projects.
|
| A better metaphor is a regular code editor which also shows your
| program as a graph in a sidebar and allows you to run quick
| simulations in a sandbox.
| andybak wrote:
| My feeling is that people need to stop building graphical node
| editors until we've solved some basic issues and agreed on some
| common standards.
|
| 1. Playing nice with version control. Opening a graph and
| moving a node by one pixel should cause not merge conflicts.
| Stop mixing logic and layout together.
|
| 2. Lossless round-tripping to a human-readable text format.
| Text editing tools are _insanely_ powerful for many things. Not
| being able to use them is a huge drawback of node-based
| development
|
| 3. A common format that allows people to build tools that are
| agnostic to your specific environment. Node editors themselves
| should be like IDEs - not tied to a specific app. I don't use a
| different code editor when I switch from Godot to Unity - why
| is the node editor any different.
|
| 4. Just better everything. Batch/bulk changes, search/replace,
| auto-align. The quality of these essential features varies from
| "passable" to "what?"
|
| Everyone is reinventing the wheel all the time. Every platform,
| app, environment has it's own way of editing node graphs. And
| most of them suck. The amount of wasted effort for mediocre
| outcomes...
|
| Finally - are we _sure_ node graphs are the best metaphor?
| Modifier stacks (like 3DS Max) give you 80% of what you want
| for many use-cases and they are _a lot_ easier to learn and
| use.
|
| Event grids are great for many things - and again they are much
| simpler.
|
| Maybe node graphs should be the "expert mode" not the default
| (although the real "expert mode" is surely good old text coding
| - with all it's faults)
| VMG wrote:
| point 1 sentence 2: s/should cause/should not cause/
| andybak wrote:
| Thanks. Fixed.
| spookie wrote:
| What are the advantages of modifier stacks?
| andybak wrote:
| Simplicity. Compactness.
| threecheese wrote:
| Have you seen the Haystack editor? Addresses some of this:
| https://github.com/haystackeditor/haystack-editor
|
| I am interested in "node-based" design tools and libraries,
| given the convergence of editors and whiteboards within the
| knowledge management domain (Obsidian canvas, Heptabase), and
| they are encountering the kinds of issues you noted. The
| generative AI boom has been pushing this along very quickly,
| by improving and creating libraries to support tools like
| ComfyUI, DAG visualizers, and knowledge graphs; these
| solutions being so "close to the code", I am hopeful they'll
| be solved.
| WillAdams wrote:
| The Haystack Editor has been mentioned here previously, and
| seems quite promising.
|
| It makes an interesting contrast to:
|
| https://leo-editor.github.io/leo-editor/
|
| I wound up using TeXshop/TeXworks with a Literate
| Programming setup I hacked together with a bit of help from
| A.X. on tex.stackexchange:
|
| https://tex.stackexchange.com/questions/722886/how-to-
| write-...
| andybak wrote:
| My first thought was "I didn't mean browser-based GUIs" but
| then I paused.
|
| It still feels _wrong_ for the kind of apps I 'm usually
| thinking of when people talk about node editors - none of
| them are web apps.
|
| But I guess convergence and all that.
| WillAdams wrote:
| Excellent points.
|
| (much of the below has been posted in other discussions here,
| my apologies to folks who are seeing it for the _n_th time)
|
| This is a sort of tool I've believed in/wanted for a long
| while (and I've been funding the author and chatting with him
| on Discord and via e-mail), but there seem to be a few
| fundamental issues which good answers need to be found for:
|
| >What does an algorithm look like?
|
| Can such visual tools be expressive enough to justify the
| effort?
|
| They seem to work well for problems which can be expressed as
| one screen of diagram --- and while making modules would seem
| an easy way to increase the complexity, this goes against the
| initial mode of expression and if overdone, results in the
| wall-of-text one is trying to escape from, just dressed up in
| colored boxes and lines. Once one starts to scroll, or can't
| see the entire flow at a glance, things get complicated.
|
| And of course, there are collections such as:
|
| https://blueprintsfromhell.tumblr.com/
|
| https://scriptsofanotherdimension.tumblr.com/
|
| which might be used as arguments against.
|
| I've been using:
|
| https://www.blockscad3d.com/editor/
|
| but it doesn't support all of OpenSCAD (and has some annoying
| bugs in what it does try to implement) and also funded:
|
| https://github.com/derkork/openscad-graph-editor
|
| but it has problems with a stylus (I have to leave the
| Windows Settings app open to toggle stylus behaviour which is
| enough friction that I don't use it as much as I would
| otherwise).
|
| Hopefully the author will pop in and share a bit.
| derefr wrote:
| To me, it's always been strange that we speak of "node
| editors" as the concept here, when the defining abstraction
| is the data structure of a node graph representing a
| dataflow.
|
| Specifically:
|
| * with the graph having an associated schema that defines
| node types;
|
| * where each node type has fields, properties, and
| connectors;
|
| * where fields are (potentially runtime data-bound) inputs,
| with types that define their data type, bounds, quantization,
| etc. and thus equate to a single optimal choice of input
| control;
|
| * where properties are like fields, but always runtime data-
| bound, and read-only;
|
| * where connectors are the actual graph vertices; are owned
| by specific nodes; are directional (in/out/inout); pair with
| other connectors on other node types, with connections
| permitted through each connector specifying an interface type
| that matching connectors must implement;
|
| * where node-level connectors have a "purpose" (registered
| UUID) that may define how they are rendered at the UX level
| (e.g. "input" purpose = top or left sticky-outy knob; "plugin
| inout" = black internal rectangle; etc)
|
| * where all fields have implicit inout connectors to control
| and/or sample their value; and where all properties have
| implicit out connectors to sample their value.
|
| (Also, optionally: with sets of nodes able to be encapsulated
| into groups, with connectors of nodes exposed as connectors
| of the group, and connectors outside the group able to
| connect only to the group's exposed connectors.)
|
| A nodal dataflow graph _document_ , then, would consist of 1.
| a schema (embedded or referenced); 2. a set of nodes, with
| groups; 3. the initial values for all fields without schema-
| specified default values; and 4. the connection edges between
| connectors.
|
| Note how none of that defines what a program should actually
| _do_ with a given nodal dataflow graph document, even when it
| has a well-defined schema.
|
| This is on purpose; to me, a "nodal dataflow graph document"
| should be a thing like an XML document -- able to be
| processed by domain-specific tools, but also by general-
| purpose tools. A nodal-dataflow-graph editor, _could_
| potentially be such a general-purpose tool.
|
| (When using general-purpose tooling, you'd lose any rendering
| for domain-specific types in fields/properties, and you
| wouldn't be able to "run" the graph... _unless_ these
| documents could point to logic allowing a generic editor to
| understand domain types -- like HTML5 does with JavaScript-
| based Custom Element definitions.)
| threecheese wrote:
| Great comment! I also struggle with the terminology, but
| from a much less cogent perspective :). It's all over the
| place. As I dig into the existing libraries for tools like
| this in github, I keep finding new Topic terms that revolve
| around many of the same ideas: "dataflow", "node based",
| "graph", "canvas", "whiteboard", "diagrammer", "workflow",
| "drawing", and on. Systems being built with these
| components are blurring the lines between graph, diagram,
| and even text editor, and so maybe I am unfair to
| criticize; after all, it's almost as difficult as cache
| invalidation.
| nox101 wrote:
| > 3. A common format
|
| I'm not convinced this is possible. Text is simple which is
| why it is easy to make multiple editors. Most other things
| are not.
|
| For example imagine structured drawing programs. Some might
| support circles, others might support ovals. If the 2nd one
| writes an oval and the first one doesn't support ovals then
| it's no longer portable. You can't think of all the features
| you could possibly want therefore you can't have a portable
| format. Even for the same features, one app might store a
| circle as center+radius and another as left corner+right
| corner of it's bounding box, and yet another as
| center+widthRadius+heightRadius and another as
| center+angleOfRotation+2radiuses and another as
| radius+group(scale/rotation/position)
|
| You can see this issue throughout structured drawing
| programs. Illustrator,Affinity Design, Inkscape. They might
| all export/import to SVG but they lose all the data that
| makes them editable because every app supports different
| features and or similar features but defined in different
| ways.
|
| Even pixel image formats are not portable for all the same
| reasons. Yes you can load/save a PNG from any image editor.
| But, generally, trying to load the apps own format, the one
| where it's still in a more editable format, into another
| editor is at best a lossy feature and usually not supported.
| It's lossy, because the editor doing the loading doesn't
| support every feature of the other app. For example,
| Photoshop supports "smart layers" (layers where the data is
| not rasterized into the layer but rendered on demand). Those
| layers can contain PDFs. So your app needs a PDF renderer to
| load and render them and keep them editable.
|
| Node editors will arguably have all the same issues. The
| simplest example is that they might all support different
| widgets inside the nodes. A music node editor might show
| waves, or knobs. A graphics node editor might show a spinible
| cube/sphere preview. A node editor for tablets will also
| likely have a different UX.
| vacuity wrote:
| Then you need to have editors specify which features they
| support and create common standards to make sure that two
| editors that support the same feature can actually
| understand each others' encodings of it. It's unfortunately
| too true that we will never have a single, perfect standard
| in any domain. It falls upon us to create smaller standards
| and be explicit in which ones we each dabble in. Otherwise
| there are no standards at all.
| threecheese wrote:
| I agree that it would be tough to create a uniform
| standard; there's at least one library that tries to
| use/extend SVG features for defining node shapes, and even
| they admit it's a PITA and so provide programmatic
| wrappers: [GoJS Geometry](https://gojs.net/latest/api/symbo
| ls/Geometry.html)
|
| They leverage SVG Paths [1] to define node/object shapes,
| and so you can use Bezier curves and other entities defined
| in the SVG spec in your graphs [2]. Alternatively you can
| just reference .svg files. They have a lot of cool samples
| [3]. I don't remember where I came across it, but I've been
| digging through github to find the libraries that popular
| tools use; there are 3k forks, so _somebody_ likes it.
|
| 1. [SVG Paths](https://www.w3.org/TR/SVG/paths.html) 2.
| [GoJS Path
| Strings](https://gojs.net/latest/intro/geometry.html) 3.
| [GoJS Samples](https://gojs.net/latest/samples/)
| andybak wrote:
| Surely it's no different to how IDEs can support
| autocomplete and intellisense for multiple languages.
| Something like a LSP definition would tell the editor what
| nodes were supported and what the syntax rules were.
|
| Previews and feedback would be the toughest problem - a lot
| of node editors are very closely tied to rendering (or the
| equivalent) and real time feedback is common.
|
| But - these are challenges more than they are blockers.
| nox101 wrote:
| They aren't. For proof I give 50 years of this problem
| not being solved anywhere except text files effectively
| because text files have no structure except line feed.
|
| There is no universal format for formatted text. You
| could point to HTML but try exporting to HTML from Word
| and then importing back in and you'll see what's missing.
| There is no universal format for structured graphics. No
| universal format for raster graphics. No universal format
| for 3D. No universal format for spreadsheets. Etc.....
|
| They all have the same issue. There are infinite possible
| features and infinite possible ways to represent those
| features, each with their own tradeoffs.
| andybak wrote:
| And yet somehow every day people are importing files from
| one application into another application.
|
| A solution doesn't have to be 100% to be useful. 3D file
| formats are a complete mess and yet somehow movies get
| made.
| halfcat wrote:
| > _are we sure node graphs are the best metaphor? Modifier
| stacks (like 3DS Max) give you 80%_
|
| Worth noting that, generally speaking, a linear sequence of
| modifier steps is what we get as the _output_ of a
| topological sort on a DAG.
|
| Meaning, it is indeed simpler and easier to reason about if
| we just let the user define and manage that list, as opposed
| to building a graph which then produces that list.
|
| It seems like both concepts can happily coexist, if the task
| runner just needs a list of tasks. Then any structure that
| can be transformed into a list can work (list, tree, graph),
| and then a "modifier stack generator" can transform a tree
| using a tree search, or a graph using a topological sort (or
| whatever algorithm is appropriate based on the kind of
| graph).
| andybak wrote:
| Not all node graphs are DAGs - a lot of audio platforms
| allow cycles I believe.
|
| But I'm thinking more about how the user would want to
| interact with the system.
|
| The trouble with graphs is that they tend to nudge you
| towards spaghetti and they tend to force micromanagement of
| layout on you. Smart autolayouts alleviate this latter
| point somewhat but you also lose some of the semantic value
| that spatial organisation provides.
|
| Depending on the application you tend to most be doing "fan
| out" or "fan in" - most of the graph is a tree. "Fan in" is
| easy to handle in a stack. A modifier takes another stack
| as input. The other stack doesn't have to live somewhere
| different spatially - it can just be hidden and shown as
| needed.
|
| I just don't want to spend my time tidying up my graph and
| zooming in and out just to see things. Node graphs are
| probably responsible for a decent chunk of the sales of
| incredibly large monitors! I like to work on a small-ish
| laptop and I have the eyesight of a middle-aged man.
| navane wrote:
| Maybe I'm misunderstanding this tool, but I'm looking for a ui
| for (technical put non programmer) end users that offers a lot
| of flexibility. I (the programmer) would create a bunch of
| partial calculations (the nodes) that the end user then could
| strong together in advanced and creative ways. The competitive
| product for the end user is not programming, but Excel.
| nkrisc wrote:
| Graph editors are useful when the nodes represent meaningful
| abstractions over the underlying code for whatever the domain
| is.
|
| For example, I could use a bunch of arithmetic nodes to
| implement matrix multiplication, but a RotateAroundPoint node
| would be far more useful and desirable.
|
| For low-code users, this is often exactly what they need. You
| could write a RotateAroundPoint function for them to use, but
| then they're still managing a lot of the boilerplate around
| writing code. Graph editors solve many of these pain points
| when the correct nodes for the problem-space are offered.
| Towaway69 wrote:
| I spent a year working on visual versioning for NodeRED flows
| because that was the first thing I felt was missing with
| NodeRED.
|
| The result was FlowHub.org which differentiates between visual
| changes and textual changes. Which was my main focus.
|
| There is no visual concept for merge conflict or similar but at
| least versioning is far simpler since comparison between
| versions is much simpler.
| SpeakinTelnet wrote:
| See also:
|
| Ryven (https://ryven.org/)
|
| pyflow (https://wonderworks-software.github.io/PyFlow/)
| agumonkey wrote:
| the customizable node source code is neat
| 999900000999 wrote:
| >We recommend Nodezator for intermediate Python users. Or, in
| case you are not a programmer, have an intermediate Python user
| next to you so that person can help you set up a no-code/low-code
| workflow for you.
|
| Seems like they're missing a key market. As an actual programmer
| using this node editor is going to be slower then just writing
| code.
|
| I want something like this , but for Rust or another difficult
| language. Python is so easy this doesn't feel needed.
| bondarchuk wrote:
| Tying together calls to existing functions is also not the
| difficult part of Rust, I'd guess.
| spookie wrote:
| If you do anything visual, nodes provide significant iteration
| advantages (albeit with some other disadvantages).
|
| Given the examples, I believe this is targeted to such uses.
| fmbb wrote:
| What are the advantages this provides that specifically apply
| to working with visual end results?
|
| There is one kind of iterative work I can see nodes/graphical
| coding have a great advantage: when you don't know what you
| really want to do. You want to compose and reorder a bunch of
| operations or compositions thereof speculatively and just see
| what happens.
|
| Moving code around and reorganizing it by trial and error is
| definitely something I can see visual programming excel at.
| WillAdams wrote:
| No syntax errors is the big one for me.
|
| Such tools are also great for exposing functionality ---
| what you see on-screen is what you can do.
| Someone wrote:
| FTA: _"For instance, this is all you need to turn numpy.save()
| into a node: from numpy import save
| main_callable = save third_party_import_text = 'from
| numpy import save'
|
| "_
|
| So, if you want to turn multiple Numpy methods into nodes, you'll
| have to copy-paste-edit this?
|
| Looks unergonomic and slow (repeatedly parsing the Numpy file,
| once for each node to create) to me.
|
| I would think a single file from numpy import
| save,foo,bar,baz
|
| should be enough to more efficiently generate four versions of
| the above.
|
| What do I overlook?
| WillAdams wrote:
| At a guess, the implementation detail/difficulty of making
| multiple nodes from a single declaration.
| skeledrew wrote:
| You could use a script to automate creating the modules from
| import specs.
| mistercow wrote:
| I can see some advantages of this kind of editor for specific
| contexts, like if you're building a shader, this UI forces you to
| be purely functional without explicitly teaching purely
| functional concepts.
|
| But it seems like there's also a general feeling that this is
| easier than learning how to code, and I guess my question is...
| is it? Is this really a better idea than a simple to use API with
| a DSL (or just a simple language like Go or Lua). Is it just less
| intimidating to beginners?
|
| You still have to learn the concepts and rules of the system, in
| addition to figuring out cable management. It seems to make
| documenting your "code" a lot harder. And now with AI assistants,
| you're giving up even more by not working with text.
| MrLeap wrote:
| I've got 2 decades of professional programming experience under
| my belt and I still think node graph editors are grand. I
| regularly use VFXGraph / Shadergraph / Custom nodegraph editors
| for various gamedev things (e.g. dialog trees, checkpoint
| graphs, all sorts of things)
|
| I'm very defensive of my "repl latency". By that I mean, how
| much effort/time does it take for me to see the results of my
| change in action? Every node editor that's found its way into
| my workflow brings that latency down to real time.
|
| They provide much more information so much faster about every
| change you're making as you're making it. It's like a causality
| scope. If the widget you're tuning/iterating on benefits from
| that, they're a joy.
| mistercow wrote:
| Isn't that, again, specifically a benefit of being purely
| functional?
| MrLeap wrote:
| To me, the way inputs and outputs are presented in
| nodegraph editors adds value on top of the benefits
| functional programming provides. You see the cascade of
| every change in real time. Change parameters and see every
| stage's new inputs and outputs as they're transformed.
|
| If I added Logger.Log calls to show as much info, my
| console would be a blur. I wouldn't be able to click on a
| parameter in my log and change its value and see what the
| consequences were.
|
| You can change values at a breakpoint, but that's a single
| moment in time. If your code's running at 60hz, breakpoints
| can feel like trying to solve a where's waldo through an
| electron microscope.
|
| I have not came across any workflow in my IDEs that is as
| flexible and informative for the situations where nodegraph
| editors shine. If something comes to mind for you, I'd love
| to know about it.
|
| There's no theoretical reason a text editor couldn't be
| made to show the same cross section of key information
| though. TempleOS is kind of like that lol.
| baq wrote:
| It's somewhere between excel and traditional source trees. It
| isn't a bad idea, but the tooling isn't there for general
| purpose work.
| skeledrew wrote:
| A good way to not only eliminate syntax errors (given the minimal
| typing), but also greatly reduce type errors (although from a
| glance I don't see mention of type-hint checks to ensure
| incompatible sockets aren't connectable). It bothers me that I
| see nothing about async support, nor reusing a graph as a node in
| another graph (after all, it's all function compositions). Maybe
| I'll try it, but I don't like to think of the hoops I may have to
| jump through to work around limitations.
___________________________________________________________________
(page generated 2024-11-30 23:01 UTC)