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

Show HN: Flowcode – Turing-complete visual programming platform

app.getflowcode.io

Post reply on HN
Print view View original

61–70 of 82 posts

Re: Show HN: Flowcode – Turing-complete visual programming platform

#61

Post by pancsta »

hermitcrab wrote: post #52

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://successfulsoftwar…

I totally agree but Id also like to point out that visual debugging on itself is impractical (although cool and easy to pick up). It has its place in education though.

Re: Show HN: Flowcode – Turing-complete visual programming platform

#62

Post by pancsta »

mattfrommars wrote: post #44

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.

If your nocode tool was a graph, a TUI debugger [0] like this could have helped. The problem is that people usually try to use the graph UI for debugging as well.

[0] http://assets.asyncmachine.dev/video.gif

Re: Show HN: Flowcode – Turing-complete visual programming platform

#63

Post by muaz »

remon wrote: post #46

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".

In the era of vibe coders, visual programming seems like an interesting way to build consensus with an LLM when making a decision. LLM shows you a visual for its execution and the vibe coders feel like its approachable enough to tinker with the visual to improve execution.

Re: Show HN: Flowcode – Turing-complete visual programming platform

#64

Post by muaz »

orlevco wrote: post #30
abxyz wrote: post #7

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 ide…

Hey, author's co-founder here. You're right that getting developers to switch to visual programming will be tough. But we believe that: 1. In the right use case (standalone API/workflow, multiple LLM calls, concurrency etc.) working visually is going to be 10x better than code 2. There's a growing segment of non-developer-but-technical people: Self-taught builders, Product Managers, IT/Automation specialists. We thin…

Devs may take time to adopt visual programming, but SME will more readily try this to improve execution. Visual programming will be the way SME and LLM build consensus on execution.

Re: Show HN: Flowcode – Turing-complete visual programming platform

#65

Post by hermitcrab »

pancsta wrote: post #61
hermitcrab wrote: post #52

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://successfulsoftwar…

I totally agree but Id also like to point out that visual debugging on itself is impractical (although cool and easy to pick up). It has its place in education though.

>I totally agree but Id also like to point out that visual debugging on itself is impractical

I'm not entirely sure what you mean. But I think a visual data wrangling tool (like my Easy Data Transform) is easier to debug than it's code based equivalent (like Python + Pandas) because you can click on each node in turn and see exactly what is happening, step by step.

Re: Show HN: Flowcode – Turing-complete visual programming platform

#66

Post by crq-yml »

I was imagining this kind of product the other day, in the context of building content creation pipelines(I was looking into extending Blender to call out to ffmpeg and similar tools), and now here's a full example of where it could go - I'm on my phone but I'll dig in later.

My thought is that flow graphs are a great fit for the AI wave since the weakness in the graphs is mostly around "random access" problems that need to model a broad technical vocabulary, while the weakness in using the AI is in it not knowing the boundaries of the problem space and just generating endless text slop instead of using it to generate a configuration or remake a common algorithm with a small tweak. Tying the two together into a system that looks like "human oversight over automated coding details" should be a major step in the right direction.

Re: Show HN: Flowcode – Turing-complete visual programming platform

#68

Post by Vegenoid »

abxyz wrote: post #32
orlevco wrote: post #30

Earlier quoted context omitted.

Hey, author's co-founder here. You're right that getting developers to switch to visual programming will be tough. But we believe that: 1. In the right use case (standalone API/workflow, multiple LLM calls, concurrency etc.) working visually is going to be 10x better than code 2. There's a growing segment of non-developer-but-technical people: Self-taught builders, Product Managers, IT/Automation specialists. We thin…

> In the right use case (standalone API/workflow, multiple LLM calls, concurrency etc.) working visually is going to be 10x better than code I completely agree but I think that's a very hard sell. People who write code are often years deep in their preferred workflows and asking them to reconsider how they build things is a very big ask. > Even if developers prefer textual code when on their own, when they're working…

Agree that these tools are enormously useful for non-programmers to automate things. I think the biggest area where all visual programming languages is in scalability, flexibility, and speed compared to a skilled (text) programmer. There is absolutely space for these tools, but I think that the wide majority of people who spend enough time programming will prefer text.

The tradeoff between visual and text programming feels like a classic learning curve vs. skill ceiling tradeoff.

Re: Show HN: Flowcode – Turing-complete visual programming platform

#69

Post by Bjartr »

remon wrote: post #46

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".

Visual coding as domain stuff DSL has seen success in a variety of areas, as others have given examples to.

It's general purpose programming where it's yet to really succeed.

Re: Show HN: Flowcode – Turing-complete visual programming platform

#70

Post by Towaway69 »

gabigrin wrote: post #5
artemonster wrote: post #2

Wow, I used to hate myself, but I hate this even more! /j. Jokes aside, congrats on the release! why choice of DOM for nodes instead of canvas?

Haha, thanks! As for the DOM nodes - as a React frontend developer by trade, the DOM was my first choice for simplicity when I started working on Flyde a few years ago. I was sure I’d eventually need to switch to Canvas or WebGL, but surprisingly, the DOM has held up pretty well. It’s been performant enough to render complex flows smoothly, and being able to leverage the existing React ecosystem has been a huge advan…

checkout Node-RED[1], they use a giant SVG as their canvas.

Has nice features such as vector image exports of flows ...

[1] https://nodered.org

Post reply on HN