What if programming were just like connecting dots, and drawing conclusions to solutions? In a way, it already is. That sounds simple enough, until you try to do it. Try to debug it, try to fix it, try to keep your sanity. Even for the most experienced among us, it can be a challenge.
The team at NoFlo, which recently launched their kickstarter campaign, have a fresh take on an old idea. Flow Based Programming has been around for awhile, invented in the 70’s by J Paul Morrison of IBM. The concept is simple enough: take programming to flow charts, and vice versa. Programming itself is a like an algorithm, and flow charts are the cleanest way to present them. By combining the two, we have a very intuitive way to both map out a project and see it through, in a very cohesive way.
Henri Burius, founder of NoFlo, has that original concept of bringing the whiteboard to the desktop in mind. When you map out a project, you connect ideas with lines to one another, and decide how it should work. In those early planning stages, you know just what you want the project to be about and how it should perform. Sometimes, when it gets to programming, things get lost in translation. From the Kickstarter page:
If you’re a programmer, deep down, you know code is bad, it rots, and with each new line your software accrues complexity debt. New code means more bugs, more refactoring and more time needed to bring someone else up to speed.
NoFlo is trying to open up the world to a smoother programming experience. The real brilliance behind NoFlo is keeping it simple for the user, whether it be a programmer or layperson. Allowing us to take something from concept to practice in as few steps as possible means the original vision can be more readily realized.
When I spoke with the NoFlo team, I wanted to know why this concept, which has been kicked around since before many of us were born, was ready for primetime now. They noted that FBP was already being used. Dan Trocchini, founder of The Grid and on NoFlo’s core team, says “The flow-based revolution has already happened, but successful implementations are highly specialized and industry-specific, so the news rarely percolates to the developer community at large. Literally every tool in the fx-driven pipeline of modern Hollywood use flow-based tools that go under names like, “Nodal Editors.”
The NoFlo team, with J Paul Morrison, founder of FBP, on the left
If NoFlo sounds a bit like Quartz Composer, the object oriented program no longer supported by Apple, that’s fair. NoFlo just takes that concept a touch further. From the NoFlo team:
Quartz Composer is probably the closest thing out there to the NoFlo Environment, but it's not as developer friendly and only suitable for prototypes not production ready software. The few Flow-based tools relevant to developers like Yahoo! Pipes and Quartz Composer have mission-critical flaws; they don't give easy ways for developers to drop down from the visuals and hack on custom components and they do not respect modern software dev idioms like testing and git. FBP is a general paradigm, likewise, Nolfo is a generalized application development platform, with clear escape hatches to code. NoFlo is tightly integrated with Github and we built-in a TDD workflow. Something not highlighted in our Kickstarter video is the way programmers can code in NoFlo.
NoFlo is shown with a built-in code editor, giving depth to collaboration
NoFlo really does represent a needed shift in the way we work, but not the way we think. For me, the real question became what would happen to those programmers who have such a strong grasp on what is going on now, should a system like NoFlo catch on. Dan Tocchini from NoFlo tells me that “NoFlo can be incrementally integrated into an existing code-base, it’s not all or nothing. NoFlo graphs can be used as a service or embedded in existing code. It still takes practice to become familiar solving high-level problems using visual graphs, but it takes much more effort to become adept at solving those same high-level problems with procedural text.” He went on to point out that programmers would have much more time to create component libraries, should a system like NoFlo catch on widely.
It’s great to see a system where everyone wins, really. We all get a more approachable way to solve problems, which is what any program or app is really designed to do. The hardcore programmers get to work on deeper stuff, and the designers of the world can get working on a product themselves, at least on a entry-level basis. NoFlo is an exciting concept, one which I hope catches on widely, and quickly. For more info, check out their Kickstarter campaign. They’re halfway to their goal already, so the project is pretty much in the bag, but your support is still appreciated. As Android fans, we should embrace that the Android stretch goal is much lower than the iOS mark, and work to make it happen for them, and us.
Like this post? Share it!
I like Corona, it’s foe the noob devs (=me). BTW “The real brilliance behind NoFlo SI keeping it simple…”
*scratching my head*
this article is on a entirely different level.. :D
i’m interested.. organization of code has always been one of weaknesses.. toss in some templates for common projects and this will be huge.. Get this into schools and 2-3 years from now a whole mess of kids will be some crazy wicked good programs..
Wish I had this back when my brain was a sponge..
Honestly,.. this is a complete bull shit. Flow-based programming cannot be the future of programming.
lol it isn’t. the damn thing has been around for as long as I remember.
Only variant that I thought was even slightly useful was a plugin for Eclipse, and even that was just for the sake of visual “tidiness”.
I’m answering some of the “why now” questions at: http://bergie.iki.fi/blog/noflo-kickstarter-launch/
You may also want to watch Bret Victor’s recent “the future of programming”: http://vimeo.com/71278954
Slow news day?
*UCK MY PUSSY
I hope they get more than $250K and achieve their Stretch goals – Java Implementation (Android Apps)
Coding in java sucks!
I hope so too =)
I feel your pain, it’s like diagramming in UML, too much concern about “how” things “should” be done, when all you want to do is process input to produce the right output!
The concept of visually building a program is stupid and all similar projects have hit a dead end. Well written and structured code in a modern high level language is far better than this shit. Spaghetti code isn’t the result of text based programming, it is the result of bad programmers and poorly designed projects.
No worries! NoFlo works without the UI, you can build the graphs via JSON, procedurally or a DSL. And, the components are traditional OO code. noflojs.org/documentation/
Software logic is inherently a graph. Functions connect to other functions, sending data along. A framework for controlling flow of data between Github shared components with a graph and an *optional* UI is … stupid?
I love the idea. I really do. The computer music composition world went through a phase like this 10-15 years ago. It was fun, dragging instruments and hooking up “patch cables” between them, making little bits of song and hooking them together. It was a way to get the sound you wanted without putting so much work into it that you lost your inspiration.
But except for some really intricate pieces that defenders of that paradigm spent a ton of time on, the music people made with them sounded… kind of samey. I’m afraid that’s what’s going to happen with NoFlo, too.
The concept is sound. It’s really not that different than tools like VB and Xcode: you’re placing a “physical” representation of programming objects into a workspace and doing all the tedious connection work with the mouse instead of the keyboard. The boxes just represent different things here. But as with those tools, most of your business logic is still going to have to be written in plain old procedural code, hidden behind those little boxes. And inevitably, you’ll run into use cases that the little-boxes-and-lines paradigm can’t handle.
Maybe there’ll be some great success story where a coder obsessed with making this work bangs his head against it so long that he bends its limitations and produces something amazing. For most developers, though, it’s just going to be limiting. And if it’s successful, we’ll have yet another round of middle managers thinking they can reduce their development staff costs by either hiring receptionist-level talent or doing it all themselves, with disastrous results, as with every previous “revolutionary” no-code-required software development product like Forest & Trees and Alpha Four in the early ’90s up to today.
I won’t even go into what it says about a web development project when, at least two years into development, they have a “gravatar” component but no MySQL component.
This kind of diagrammatic programming has been done before, with products like Metastorm & webMethods. It’s nothing new. You still end up doing text programming within the individual nodes though, and it makes you dependent upon yet another tool when all you originally needed was a decent text editor & the compiler/debugger.
And Photoshop makes you dependent upon yet another tool when all you originally needed was MS Paint lol…
If you want to go back on WordPad of course you can, but NoFlo will allow you to organize your code better.
The diagram UI makes a lot of people say “It’s another Google App Inventor, this has been done before,it’s for kid, …. ” but what people don’t get it’s that the diagram UI is just the “Bonus”, NoFlo is a whole framework that structures the code into independent units.
Other products were trying to generate code from the diagram, but still in a OOP style. So they’re taking a Flow Based Programming representation (the diagram UI) to generate OO code. So you can imagine how messy it is.
Here the approach is different as the whole program is Flow based. So the diagram is the natural representation of the code and its structure.
So NoFlo is not discouraging people to learn programming, on the contrary, it is learning them how to structure their program the cleanest way (Unix style with independent and simple units).
When teaching someone to program, showing him NoFlo-style diagram should be the first thing to do so that he gets how an app must be splitted to keep being clear and maintainable.
I’ve used webMethods, & I’ve used Curam’s Rational Rose based development environment – in the end though it’s a bit like using Word to develop HTML. You end up with a load of machine-generated code that you end up needing to debug anyway, which isn’t always the best optimised, clearest to read, easiest to maintain or anything much really. You gain some rapid development advantage but often you end up losing in terms of maintenance & support costs when it goes tits-up.
for UI design, like programmable component, similar though can be found in Qt Creator, nice work. maybe it can be applied in CG. I like text flow design concept in unix where text is the eternal interface, with bunch of components and pipe, we can tackle surprising hard problems.
Anything that claims “you don’t even have to know how to ” is a bag of trouble. There’s a reason drag and drop programmers from all walks discover that they can’t hang on larger projects. The method of doing things confines you to what the tool is able to describe. The minute you break out of that and need to really develop something different you’re lost. You don’t understand anything about the code you’ve been writing or how to adapt it.
Awesome, chart-topping iPad app developed with the visual, flow-based Quartz Composer: https://vimeo.com/22872265
Use of flow-based tools to design Iron Man’s HUD in Iron Man 2: https://www.youtube.com/watch?v=j1PCtz6VZSI
How Facebook visually prototyped their version of Android OS: http://www.youtube.com/watch?v=GGAtBvKsJAI
Flow-based development of AI “brains” to control autonomous agents in Lord of the Rings battle scenes: https://www.youtube.com/watch?v=W5pNPJAhsBI
Well thanks for the clarification. I am sorry for the rude comment. But as a software developer, I can’t see the benefit of noflo(or any flow based framework) over traditional program building through applying design patterns and good practices. What bothered me is how the video tries to draw a cause and effect relation between writing code in a non flow based pattern and the creation of spaghetti code.
My views regarding might change, so I’ll give it a try when I have time soon. Thanks and keep up the good work.