Show HN: Flowcode – Turing-complete visual programming platform

I love your premise here. I think visual programming has such untapped potential even though it has been tried and tried and tried so I hope you crack the code a bit (lol).

I think you're exactly right on the idea of "I just diagrammed all the control flow why can't I just push run". It's kind of crazy to introduce a point of failure (and a menial translation step) by writing code to match the diagram.

Another huge benefit that I learned when reading about drakon (obvious in retrospect) is that good visual programming makes the software development process more accessible to other smart people involved instead of locking it away behind computer jargon and tools (the drakon example was rocket scientists able to now work on, review, and validate the logic and control flow instead of having to just hope it ended up right).

I hate that I'm saying this but this would actually make me feel a lot better about the vibe coding going on right now. If the control flow was right, hand crafted, and easy to review I'd feel a lot better about throwing the implementation details of many individual nodes over the wall to the ai without worrying about the house falling down.

History shows that visual programming can work very well in particular domains (data wrangling, signal processing, 3d image rendering etc) but has never really been successful for general purpose programming.

A lot of the issues related to visual vs text based programming have been debated here many times. As someone with a foot in both camps, I tried to summarise the various arguments here:

https://successfulsoftware.net/2024/01/16/visual-vs-text-bas...

What is the error handling story? I'm shocked that Control Flow doesn't contain Try-Except

Anyway, I ask because Write File returns nothing <https://docs.getflowcode.io/docs/reference/file-system/write...> but there's also no discussion on that page of what happens when one cannot Write File (and the ways that can fall over are almost unlimited)

Also, please fix the inputs bullet list, that's a pretty glaring "no one reads these docs" bug. While you're there, never, ever, ever, ever, ever just have the documentation for anything be a repetition of the input variable's name. I can read, what I can't do is know what the domain of possible encodings are available (base64? base85? uuencoding? gzip+base64 <https://docs.cloud-init.io/en/24.3/reference/modules.html#wr...>?)

We use an internal 'no code' tool to do complicated data transformation logic. Our flow has become so large and convoluted, it is extremely difficult to put feature and debugging is absolute nightmare.

You have no idea how many times we had wished all this data transformation was in vanilla Java/Python. Our life would have been so much easier. But at this time, it is too large to ignore.

Visual workflow tools, particularly those that are able to support a human-in-the-loop, MUST exist for the world to adapt and effectively use LLMs.

Literate Programming - coined by Donald Knuth and at the heart of Jupyter Notebooks - is powerful means of making software development a tool in the pockets a lot of people. I agree that just pressing "run" is critical to making a tool like this accessible.

I'm one of the core contributors to SpiffWorkflow. We are also visual programming platform and echo your belief of the power of combining visuals with programming. I shared this article here a few months ago that delves into our methodology. - https://medium.com/@danfunk/5-ways-bpmn-python-will-simplify...

conartist6 mentioned elsewhere in the comments of a need for a common standard for editors - I think BPMN could be that standard, or new revolutions of it, such as POWL.

collingree mentioned "good visual programming makes the software development process more accessible to other smart people" -- I think this maybe the MOST important long term benefit of these tools. More people in organizations need to understand what the hell is going on - and stop shrugging their shoulders when it turns out all the business logic is buried in 100k lines of code. Important shit should be easy to find and change.

As many others have mentioned here, visual tools are not likely to see wide adoption by software engineers for all of their work. But as middle groud in which to plant business rules, so those rules can be cultivated - it could change the world and the way we collaborate on software efforts.

Would love to talk to you both sometime, share war stories, dreams, and go to market strategies.

So far there are zero data points on the success side of the fence when it comes to visual programming. The exceedingly rare times I come across it professionally it's a toy project or something that's basically in the state of "We wish it was just code but we don't dare touch it".

IMO, Complexity is still best tackled with text. Low-code for lunch, spaghetti for dinner.

I just want to make an observation based from previous experiences.

These styles of programming environments are not new. We have seen many such tools in the past. I think they are useful (to an extent) when dealing with high-level compositions such as orchestrating a video pipeline, shaders, simple logic.

They start to fail very quick when you need to implement more advanced algorithms and processes that are not yet abstracted in reusable blocks. Needless to say, it is easier to write code at this point. Just less cognitive load and frankly the visual model does not help when you have a solid mental model - you can keep more information in your head in abstract forms than the eyes can scan and process.

I am lurking in the n8n community and I have noticed similar patterns. The more elaborate workflows are just not as robust as they could be if you write code - and they happen to be very difficult to maintain too and full of bugs.

Other than that... these types of framework have their place and as I said, overall I think they are useful as long as they are used in the right way.

Re: HTTP Flows.

As we know networks never fail, read timeouts aren't a thing and error handling is not necessary as networks never fail and read timeouts aren't a thing and error handling is not necessary as networks never fail and read timeouts aren't a thing...

I'm starting to see line-of-business folks start jumping into Python using LLM. It's going to be hard to compete with that with your custom flow diagrams.

Looks very good, I believe this type of product is the future (instead of vibe-coding that produces heaps of junk new code). A few thoughts:

* Flowcode is a clever name but since you are positioning yourself as an alternative to code ("Code is messy and complex") the name is contradictory, just call it "Flow" (or "flows" or "Flower" something)

* You are replacing the legacy of code with something new, embrace new ideas that get out of the "one running process" paradigm, e.g: durable functions. There are a bunch of companies in the space (inngest, DBOS, trigger.dev) who are doing very interesting things, copy/steal/leverage all the great things they're doing -- your product's value is the visual programming

* Most developers today are already writing code so getting out of their code flow to do something visual might not fit well, whereas there are lots of non-developers who would love a product like this (see: the success of Make.com, Zapier etc.) because you're offering the AI integration for creating workflows which gives them confidence to go beyond what Make, Zapier etc. offer

If I were marketing this product, my pitch would be reframing programming as something anyone can do when it doesn't involve code, i.e:: your users can become a developer without writing code, AI-assisted visual programming builds production-ready systems without a single line of code. Code is archaic, (visual) programming is the future. Vibe coding is faster horses, AI-assisted visual programming is flying cars.

That reminds me of a very beautiful flow based language years ago, Luna-Lang[1] but it seems that the website died and it is no longer maintained.

[1] https://github.com/binary132/luna