Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

PyFlow – Visual scripting framework for Python – NodeRED alternative?

github.com

Post reply on HN
Print view View original

41–50 of 54 posts

Re: PyFlow – Visual scripting framework for Python – NodeRED alternative?

#41

Post by t0mas88 »

punnerud wrote: post #12
nyellin wrote: post #9

Very cool. We're designing an open source automations engine for Kubernetes ("Zapier/IFTTT for devops") and have thought about adding a UI for automating stuff visually. So far, simple YAML configurations have won out and we're still debating the benefits of a UI. Does anyone have experience using tools like this at scale or for technical domains? (E.g. devops.) Would love to hear a convincing case why a UI is better…

Look to HomeAssistant, where there is a lot of both YAML and NodeRED. I am hoping there could be a Python alternative to NodeRED build into HomeAssistant, to make it easier for beginners.

And Home Assistant itself is python so it may be a better fit than the often used NodeRed which is JS based.

Re: PyFlow – Visual scripting framework for Python – NodeRED alternative?

#42

Post by t0mas88 »

geek_at wrote: post #33
daenz wrote: post #29

Earlier quoted context omitted.

These kinds of visual programming systems always seem to degrade into spaghetti hell, don't they?

It depends. My nodeRed flow for grabbing various sensor data and sending them to influxdb: https://pictshare.net/mvarpf.png And my home alarm system flow: https://pictshare.net/82qfpa.png To be fair though you can create sub-flows to have it more compact but when I designed it, I didn't know about theseyet

I use node-red for the same kind of things, with subflows. At some point it makes a lot more sense to write a function node (javascript) than to use node-red as intended. Avoids a lot of the spaghetti.

Re: PyFlow – Visual scripting framework for Python – NodeRED alternative?

#43

Post by ethbr0 »

bmitc wrote: post #36
ethbr0 wrote: post #18

Earlier quoted context omitted.

I think the key here, as a responsible developer, is ensuring isomorphism between the GUI representation and the generated code. To the extent that the development method could be swapped without repercussion. Most GUI tools, presumably in speed to market, skip this. But as soon as you've created something that can only be viewed & modified in a visual editor... you've become part of the problem. So I'd approach this…

> But as soon as you've created something that can only be viewed & modified in a visual editor... you've become part of the problem. Why is that? You don't view the bytes your text editor generates do you?

ASCII and Unicode are standards. Presumably OP isn't building a tool with enough market share it's going to have an international standard encoding.

What you end up with, if you don't have a standard, and you don't maintain isomorphism... is user "code" that requires a vendor tool to view & modify.

Which sets up some really screwy incentives & business models.

A thing you built. That you paid for the tools to build. That you have to continue paying for, otherwise you'll be unable to guarantee maintainability.

Charge for execution if you want! But IMHO user developed code, in whatever format, deserves to be owned by users. Even if they decide to no longer be customers.

Re: PyFlow – Visual scripting framework for Python – NodeRED alternative?

#44

Post by nargella »

nyellin wrote: post #9

Very cool. We're designing an open source automations engine for Kubernetes ("Zapier/IFTTT for devops") and have thought about adding a UI for automating stuff visually. So far, simple YAML configurations have won out and we're still debating the benefits of a UI. Does anyone have experience using tools like this at scale or for technical domains? (E.g. devops.) Would love to hear a convincing case why a UI is better…

Having worked on a flow based UI for a few years, I would say it very much depends on your core use case and the “standard library”. Since you’ll probably be making a DSL of sorts, there is a balance of simplicity and flexibility.

It really shines in the ETL area. Configuration and generation would be alright.

You can get an idea of where I got with js at [fluxion.app](https://fluxion.app).

Re: PyFlow – Visual scripting framework for Python – NodeRED alternative?

#45

Post by dv_dt »

bmitc wrote: post #36
ethbr0 wrote: post #18

Earlier quoted context omitted.

I think the key here, as a responsible developer, is ensuring isomorphism between the GUI representation and the generated code. To the extent that the development method could be swapped without repercussion. Most GUI tools, presumably in speed to market, skip this. But as soon as you've created something that can only be viewed & modified in a visual editor... you've become part of the problem. So I'd approach this…

> But as soon as you've created something that can only be viewed & modified in a visual editor... you've become part of the problem. Why is that? You don't view the bytes your text editor generates do you?

Ah yes? and diff, track, and version the bytes with tools like git. Or perhaps I’m misunderstanding the question here?

Re: PyFlow – Visual scripting framework for Python – NodeRED alternative?

#46

Post by bmitc »

ethbr0 wrote: post #43
bmitc wrote: post #36

Earlier quoted context omitted.

> But as soon as you've created something that can only be viewed & modified in a visual editor... you've become part of the problem. Why is that? You don't view the bytes your text editor generates do you?

ASCII and Unicode are standards. Presumably OP isn't building a tool with enough market share it's going to have an international standard encoding. What you end up with, if you don't have a standard, and you don't maintain isomorphism... is user "code" that requires a vendor tool to view & modify. Which sets up some really screwy incentives & business models. A thing you built. That you paid for the tools to build.…

> ASCII and Unicode are standards.

Right, and those didn't just materialize out of thin air. They took time and effort to develop. My point is that we shouldn't keep shooting down visual based tools and languages on the notion that there aren't standards, because there isn't anything (besides preconceived biases) that prevent them. There are many things that text is just not good at describing, such as dataflow, and by claiming everything must be text and isomorphic to text, we're holding things back.

Re: PyFlow – Visual scripting framework for Python – NodeRED alternative?

#48

Post by analog31 »

Rygian wrote: post #23
punnerud wrote: post #11

Earlier quoted context omitted.

Like comparing Word to Latex. Latex is faster when you know it.

Scientific literature seems to disagree with this statement: "An Efficiency Comparison of Document Preparation Systems Used in Academic Research and Development" [1] For example, amount of written text was higher among Word novices than among LaTeX experts, with overall less mistakes. The only category where LaTeX users produced more content than Word users was equation text, and even in that case, authors suggest th…

Granted it was 3 decades ago, but when I was in grad school, choosing to use LaTeX seemed to add a few months of effort to the "writing" stage of a thesis. However, it was hard to assign root cause because LaTeX and Word were producing different things. The best technology allowed you to create more, but at a price. Typeset dissertations were beautiful, mine was not.

What LaTeX allowed you to do, in principle, was to "build" your document, i.e., type a single command and have camera ready output roll out of the laser printer. Using Word (or even more primitive tools -- I was on a MS-DOS machine), always required some manual intervention. My workflow involved scissors, glue, scotch tape, and a copy machine. But I got done very quickly once I was ready to start writing.

Re: PyFlow – Visual scripting framework for Python – NodeRED alternative?

#49

Post by ethbr0 »

bmitc wrote: post #46
ethbr0 wrote: post #43

Earlier quoted context omitted.

ASCII and Unicode are standards. Presumably OP isn't building a tool with enough market share it's going to have an international standard encoding. What you end up with, if you don't have a standard, and you don't maintain isomorphism... is user "code" that requires a vendor tool to view & modify. Which sets up some really screwy incentives & business models. A thing you built. That you paid for the tools to build.…

> ASCII and Unicode are standards. Right, and those didn't just materialize out of thin air. They took time and effort to develop. My point is that we shouldn't keep shooting down visual based tools and languages on the notion that there aren't standards, because there isn't anything (besides preconceived biases) that prevent them. There are many things that text is just not good at describing, such as dataflow, and…

I'd be more sympathetic to this idea if I hadn't seen the tactic executed repeatedly over the last 10 years to ensure vendor lock-in, which ultimately burns the end user. And/or requires them to insecurely freeze a portion of their IT infrastructure in time.

And honestly, if your GUI/designer is standardized, then it's trivial to define a stable serialization to and from text anyway.

Re: PyFlow – Visual scripting framework for Python – NodeRED alternative?

#50

Post by stewit »

Shameless Plug: We are working on a similar tool: https://github.com/hetida/hetida-designer

We have no GUI programming in the broader sense, in our case nodes are simply run one after another (DAG).

Our tool is a web application and workflows can be triggered / executed via API, which allows for automatisation. Workflows can be nested and are tagged with a version tag making production runs reproducible. It is very much taylored to (simple) Data Science use cases with the goal to make the Python data science stack accessible for Business Experts (or power users), maybe collaborating with Data Scientists.

It is actively developed, and our industrial customers happily use it, however it is still in early development state.

Post reply on HN