I think the <i>types</i> of problems each programmer tends to confront make up a large part of the disconnect between the ones who "drink the koolaid" of a programming paradigm or process and the people who are unimpressed.<p>I typically do games. Games are useful to think, in part, in OOP terms; there is very little "data flow" and (typically) there are a lot of objects that need to interact in asynchronous ways. There are specific parts that could be reduced to flow based programming (FBP), but it seems like the wrong paradigm for writing an <i>entire</i> game, as an example close to me. I could imagine FBP certain AI logic state machines being useful, for instance.<p>But other areas of development have flow-style tools and that's clearly the <i>right</i> way to write code. Signal processing is an obvious example: When you want to send an audio signal through a reverb, split it to two different types of processors and re-merge it later with a fader tied to an external control, laying those components out with boxes is 1000x better than trying to write code in text to do the same thing.<p>So I think articles like this are useful to introduce everyone to various other paradigms, in case they might be applicable to a problem that you're working on. But it's never a "silver bullet" simply because each tool works best in certain problem domains. A friend tried to convince me that I should drink the functional programming koolaid, for instance, but on drilling deeper I found that he had never worked on a game, and didn't really grok what <i>kinds</i> of code you would normally end up putting in a game.<p>What I'd <i>love</i> to see is an article that compared a lot of different processes and paradigms and talked about <i>where</i> each is most useful. Especially if that article surprised me. :)<p>Problem is that most people are familiar with their own areas and toolsets; we'd probably need a team of people from different specialties to collaborate on it. Maybe a wiki where people could add in their experiences trying each approach or tool on their own problem domains? Then when someone <i>does</i> use functional programming to write a game, they could talk about the pros and cons and the kind of game they wrote. And <i>that</i> would be useful data.
"Flow" programming is great for non programmers.I used it to develop VST plugins on pc and when I was working in video editing(compositing).<p>However,I wouldn't use that to develop web apps.It's often quicker to actually write the code,since app development is rarely just about piping stuff.
One of the main issues with Flow-Based Programming is often while it optimizes generally in the opposite direction of Functional-Programming (Currying vs. Topological Sorting I.E.: Execute when needed vs. Execute as soon as possible) is that you tend to lose control of your software.<p>While I'm not suggesting a purely imperative approach, to a certain degree gains can be had in an imperative context over either Functional/Flow Programming via in depth knowledge of OS/Hardware processes and are generally NOT developer fast/friendly.<p>From a personal stand point Flow-Based Programming is amazing for concurrency since it lets you see where you can use threads/processes. As which sections of code are less <i>attached</i> to the rest.
I have to admit, haven't read all comments... but:<p>FBP, is nothing new ... In the enterprise world ( the world that I`m working in ) it is used quite frequently, and there are some products that live of this for example ( windows workflow foundation, workflowgen ) for the c# world.<p>FBP is a way of doing things, let's say it is a pattern, like MVC ( less than more, but bare with me ) they each serve a specific task. To be a tad more clear, let's say that MVC is more of a generic on size fits all approach while the FBP is more of a custom tailored way of doing things for (highly) specific things. So, MVC would be great for a wiki and FBP would be great for the whole wiki item management from treating the adding, verifing, drafts, plublish etc etc. ( I`m sure there are a lot of better examples out there ...)<p>The benefit of NoFlo is that they actually made something that is usually regarded as "enterprise-ish crap" and made it appealing. And again they did a great job with the visual editor, but from my own experience with visual flow design ... sooner that later you will be back to the code ( we you need to stray a bit from the Happy Path ).<p>Also, I think that frameworks like NoFlow are a very good step for Node in general showing that a lot more interesting things could be done apart for the tasteless and colorless REST apis.
Things like this are great for data-processing pipelines with an enumerated set of common operations, most of which input and output the same data type. For instance, any data that can be redefined as a matrix, since a lot of matrix operations result in another matrix (or a vector, which is just a restricted matrix).<p>However, I can't help but feel that applying it any more generally is a hammer->nail issue. Or, at least, completely invalidates the idea of "massively reusable components". To make components more reusable, they have to make fewer assumptions about their input. To make fewer assumptions, they will typically need to do less. The reductio ad absurdum argument is that you end up with a bunch of components that each correspond to what would have been a line of code in a text editor, and all you've gained is a pretty picture.
One other thing I'd like to bring up - Go is a surprisingly strong tool for building flow based programs. It does have a few weaknesses, though, such as the lack of a graphical front end, but this isn't a requirement to write a flow based program.<p>The other (more significant) weakness is that you will have to either deal with interface{} casting quite a bit, or write type specific versions of the basic utilities.<p>On the plus side, you get virtually free concurrency and nearly purpose-built communication channels!
Visual programming has interested me for a long time because it is amazing how many times it has been tried and the result been unusable.<p>If I had the time and resources, I'd very much like to try developing a visual programming system that uses a user interface change that I think would greatly change things. Basically, using the middle mouse wheel to zoom in/out. If you've played the Supreme Commander game series, you will have the best idea of what I mean. As it is, you end up with absolutely everything trying to be jammed in to one gigantic flat space. That's terrible. Better would be zooming in on a 'box' (function, data structure, etc) and having its guts become the new 'context' you're working in. So far as I have been able to find, this has never been attempted.
Thanks for the write up, has inspired me to give NoFlo a go. Reminds me of Reaktor (an app used to design audio DSP effects/instruments)<p>Will be checking your blog for a more hands on series.