I remember seeing code bubbles when you released it and thinking it looked much more promising than the flow-based approaches to abstracting away code files that we usually see. NoFlow and the like tend to ignore the fact that:
1) The approach has been tried countless times before and failed.
2) Programmers don't need code abstracted away. Text is great for telling a machine what to do. The real pain point is in linking pieces of relevant text, something that OOP does pretty successfully, but still leaves some room for improvement.
3) Nobody has 25 feet of screen space to see an entire program on, and scrolling around over giant flows is a huge PITA.
4) Attempts to solve the screen real estate issues through collapsable nesting of flow paths usually lead the same incomprehensible rat's nests of logic that regular old code does.
5) Business people don't want to code, despite their fantasies of kicking all the expensive programmers to the curb. Computers usually do exactly what you tell them to, and talented programmers are different than your typical business people in that they have a knack for taking high level requirements and turning them into highly complex, low level implementations. Someone who has no interest in this sort of work will ever be any good at it IMHO.
6) Building flows requires 99% of the implementation to already be complete. Stringing together prebuilt modules with if/thens is not that difficult or unreadable in textual code anyway.
Regarding (3), I think if you need 25 feet of screen real estate in a graphical environment, then your code is probably not organized well, regardless of whether it's textual or graphical.
Regarding (1), I think we need to understand why it's been tried and why it's failed. Knowing that it's been tried before and failed should be enough to make you skeptical, but it shouldn't be enough to outright reject something unless it's a copying an old idea wholesale. That said, I think NoFlo specifically has very few new or interesting ideas.
1) The approach has been tried countless times before and failed.
2) Programmers don't need code abstracted away. Text is great for telling a machine what to do. The real pain point is in linking pieces of relevant text, something that OOP does pretty successfully, but still leaves some room for improvement.
3) Nobody has 25 feet of screen space to see an entire program on, and scrolling around over giant flows is a huge PITA.
4) Attempts to solve the screen real estate issues through collapsable nesting of flow paths usually lead the same incomprehensible rat's nests of logic that regular old code does.
5) Business people don't want to code, despite their fantasies of kicking all the expensive programmers to the curb. Computers usually do exactly what you tell them to, and talented programmers are different than your typical business people in that they have a knack for taking high level requirements and turning them into highly complex, low level implementations. Someone who has no interest in this sort of work will ever be any good at it IMHO.
6) Building flows requires 99% of the implementation to already be complete. Stringing together prebuilt modules with if/thens is not that difficult or unreadable in textual code anyway.