Comment by Towaway69

Comment by Towaway69 2 days ago

10 replies

View on Hacker News

I know of Py-Red[1] which is an attempt to do the same but with Python. Using Node-RED as a frontend and something else as a backend, no I haven't heard of anything similar.

Main problems with visual flow based programming is the tooling: there aren't any good tools for doing visual comparison nor visual version control. Things like GitHub aren't able to render flow code as seen in the editor.

For Node-RED that means that the Json that defines a flow can be compared but that soon becomes meaningless because semantic changes get mixed with visual changes, i.e., that the x,y coordinates of a node have changed - is meaningless for the logic of the code.

This means that code sharing and collaborative development is difficult purely visually but only because tooling is missing. Compared to textual programming before things like SourceForge or Git and we had the same issues as we do with visual coding now.

Node-RED has a bunch of features to make large programs maintainable. Things like link nodes that allow jumping between flows also allow code reuse. There also subflows which encapsulate repeated code and can be referenced from anywhere.

That's also why I chose Node-RED for this because it seems to be the most mature and best maintained low-code visual flow-based programming tool. There are others such as n8n (which seems to be the other biggie) but they lack the generalness of Node-RED. I can create web sites with Node-RED while and the same time controlling my LEDs via Raspberry installation. Node-RED is extremely flexible.

[1]: https://github.com/mdkrieg/py-red

applied_heat 2 days ago

For function block programming used in control systems in PLCs there are tools like copia.io that are basically GitHub for version control and can do visual diff of the diagrams

Reply View 0 replies
regularfry 2 days ago

Speaking of controlling LEDs, there's also https://www.atomvm.net/doc/main/index.html. From a very quick scan it looks like it would need some fiddling (especially around the filesystem) to get it to work, but being able to scale down to smaller devices than a full pi would be very, very interesting.

Reply View 2 replies
  • Towaway69 2 days ago

    Wow! That does look interesting:

    > With AtomVM, you can write your IoT applications in a functional programming language, using a modern actor-based concurrency model, making them vastly easier to write and understand!

    > It also supports WiFi networking on devices that support it, such as the Espressif ESP32. All of this on a device that can cost as little as $2!

    If ErlangRED made it to a $2 chip, I'd be very happy!

    Reply View 1 reply
paddy_m 2 days ago

re:version control

How stable are node and edge IDs and their ordering? Could you sort the JSON before saving so the output is more stable and diff-able?

Another thought is, how would you code up a flow like this in your preferred language if you were just writing code in that language (you didn't care about the visual editting). Call most of the same functions, but do it directly. Ok, think about that, then write a transformation from the NODE language to output source in your preferred language.

I have some sense that coding this type of control flow logic doesn't work well with text line based diffs because of the complexity of the problem, less the syntax.

Reply View 3 replies
  • Towaway69 2 days ago

    > Could you sort the JSON before saving so the output is more stable and diff-able?

    Jsons are definitely diff-able but it's the difference between a change that changes the logic of the flow or a change that is purely visual and has no affect on the logic of the flow that is hard to distinguish by just diffing the JSONs.

    Remember the Json contains location of nodes and labels of nodes as well as logic of nodes - if a label of a node changes it doesn't affect the flow logic or how it works.

    So if the value of an 'x' changed, that means the node moved along the x-axis. Did the value of 'func' (function value for a function node) change, then that is a logically change. Now what change is important if you only looking at the JSON. So you need to remember that 'x' and 'y' are visual, 'func', 'tmpl', 'rules' are logical. And what is important for each node isn't the same across all possible nodes ...

    > this type of control flow logic doesn't work well with text line

    Exactly that's why places like GitHub would need a lot work to support visual coding in proper way. Diffs would have to become like image comparisons that line-by-line diffs.

    And that is partly why visual coding has taken off - the tooling isn't available.

    Reply View 2 replies
    • HappMacDonald 2 days ago

      I wonder what would happen if they structured the JSON so that control-relevant information was just saved in a different place than visual/label-relevant information? EG, seperate form from function and thus more easily determine which has any changes in a diff?

      Reply View 1 reply
      • Towaway69 2 days ago

        There really isn't a good way to compare visual code textually. It similar to attempting to compare 3D scenes in 2D - textual code and visual code are a dimension apart in their representation.

        I created a visual comparison that combines both visual and semantic textual changes for NodeRED[1]. For me that is the only solution: visually comparing visual code.

        [1] https://flows.nodered.org/node/@gregoriusrippenstein/node-re...

        Reply View 0 replies
punnerud 2 days ago

One star on Gighub, could still be good though. Any alternatives on Python that is equally used.

HomeAssistant build on Python have an Node-Red extension, would be nice to see a Python version with more seamless integration

Reply View 1 reply
  • Towaway69 2 days ago

    One star and it gave me the inspiration to create this ;)

    The people who use Node-RED aren't the same that can develop those kinds of solutions. Those that can port Node-RED to Python don't need to use a low-code visual environment.

    It isn't like Emacs users: Emacs user can also extend Emacs and probably even fix a bug in the lisp code of Emacs. Node-RED users use Node-RED becausae they don't want to program nor learn to program nor understand how Node-RED works.

    Hence my attempt to take the whole concept and bring to a collection of developers who might appreciate visual FBP but who could also code extensions to the editor.

    My goal is to bring visual FBP to a broader audience, be that developers or non-developers, be that Erlang coders or NodeJS coders, no matter - the ideas of FBP are important to understand, especially in our data-driven digital world.

    Reply View 0 replies