[tonnydourado]

Sigh.

Firstly, and to be fair, this is more for the comments than OP, can we please stop kidding ourselves? People have been trying to make tools to allow "non-developers" to code without coding since COBOL, and they all either failed, or end up requiring that users learned how to code anyway. Except maybe Excel.

Secondly, this has some good ideas, but makes the same cardinal sin of, seemly, all visual programming tools: try to encode control flow visually. No one wants to write ifs, fors, and whiles as connected nodes. It sucks. Text is MUCH better for that. You probably are very, very rarely writing flowchart diagrams in real life. I know I don't. I write state machine, architecture, data flows, etc., unless I'm being forced by some braindead tool to write control flow logic with little boxes and arrows.

The thing that is actually interesting here is the boxes that provide higher level abstractions, like HTTP requests, LLM calls, etc. Give me one or two different nodes in which I can just write some code to process input and return output, and maybe some dispatch and map nodes, and focus on providing higher level abstractions out of the box, and allowing me to build my own abstractions too (i.e., parametrised graphs). Think more functional, less imperative.

As is, that doesn't look like a tool I'd be excited to use, but I won't deny it has some potential to be interesting.

[seanc]

"No one wants to write ifs, fors and whiles as connected nodes"

For what it's worth LabVIEW presents those structures as container boxes, which IMO works well enough. To put it another way, visual coding has many problems, but when programming LabVIEW I didn't find the representation of control flow to be one of them.

https://labviewwiki.org/wiki/For_loop

[gabigrin]

OP here.

I'm obviously as biased as one can get here, and have a general sense of agreement with your sentiment, but I think it boils down to 2 aspects: 1. The nature of your code. For a linear, synchronous algorithm, no doubt text is the way to go. For async, concurrency-heavy workflows, debugging it in a linear fashion becomes a nightmare. Take an LLM-heavy backend workflow for example, with calls chained and running in parallel. Horrible to debug using textual code.

2. The experience and features set of the editor itself. Making it reactive and not imperative was exactly our goal. Flyde, the visual-programming language powering Flowcode is a functional-reactive visual-programming language. Control-flow is determined by data, unlike existing tools in that space where arrows represent control-flow and all of the dynamic variables are hidden inside implicit "${{node1.input2}}", making it as far from Unix philosophy as it gets.

Also, Flowcode supports custom code in 3 ways: inline code expressions, custom code nodes (you can even fork any of the "stock" nodes with complete access to the underlying API), and codebase SDK integration, so you could supply it with inputs from your code in a typed way.

[enbugger]

I'd love Excel where such visual language is used instead of their crap formula syntax. Image how powerful it could be