I used a flow based programming language for 7 years. Scale is not the issue since the nodes can be subflows. So you don't build one gigantic spaghetti bowl o

I used a flow based programming language for 7 years. Scale is not the issue since the nodes can be subflows. So you don't build one gigantic spaghetti bowl of a flow. You build a high level flow with the nodes being subflows. You do that recursively until actually implementing the business logic. I found it to be fantastic for building flows for complex processes. If I asked you to communicate something like a mortgage application process you're probably going to draw me a flow. So it's very natural to program in something that looks like a flow. The problem is that when you get to the task level it's not really a flow any more. If I asked you to communicate how to make pancakes you'd give me something like a recipe. Programming is similar. When it comes to the nitty gritty of building some algorithm it's easier to do it in text based code. The problem with flow based programming comes down to that gap. It's hard to bridge from the flow to the algorithm in a way that that is intuitive and with good tooling.