>> What we need is not more programmers. What we need is to enable non-programmers to participate in the creation process, not just the ideation process,” says Kenneth Kan, CTO of a company called Pixbi and a recent convert to flow-based programming.
I disagree with this. This might work fine for small programs, but will quickly fall apart for anything of significant size. National Instrument's LabVIEW [0] offers a graphical programming language called "G". G makes it easier for non-programmers (usually other types of engineers) to create the software they need. However, as their programs grow, they can easily get out of hand and become a dangled mess if they don't understand good program design. I am all for getting more non-programmers programming, but this method does not solve the need to understand programming fundamentals.
In my experience with LabVIEW, it was really great for making things like concurrency easy, and it was really great for quickly building GUIs to control hardware. I like to think that graphical programming makes some "hard" things easy, and some "easy" things hard (it's a bit manually intensive to make complex mathematical equations - though there are blocks you can use that let you drop in C code into the interface).
Like anything else, the methodology has its advantages and disadvantages.
I've been using LabVIEW and I agree with you. LabVIEW has great hardware support which makes it really easy to get up and running collecting data.
But like you said, I've looked over some previous LV projects that have multiple copy and pasted sections, terrible design, etc.
As a software engineer, LV holds you back in my opinion. I don't doubt for a second that some really amazing things can be created with LV but ultimately it is extremely tiring/annoying to reinvent the wheel to accomplish things that would be extremely simple in almost any other programming language. This seems to come into play when you move past the simple act of collecting data and doing primitive processing.
Edit: The other thing I forgot to touch on was the presentation of the "code". With wires running all over the place and ambiguous function blocks you quickly find yourself wishing you could cozy up with a text editor instead. The main reason I don't think data flow programming will "take over" all programming is because ultimately I think its a inferior presentation for professionals.
In a similar vein to LabVIEW, I've used MathWorks' Simulink and its Stateflow FSM environment quite a bit over the years and I've found that the most effective way to use it is to have your functions written in standard textual code, with the control flow (reactive/parallel/etc) connecting the function using the graphical wiring environment. That looks similar to what NoFlo is proposing, which is a promising sign for IMHO :)
My experience also. I've been working in various test and manufacturing automation roles at HP and I've seen some complex stuff done in LabVIEW that's very hard to read and practically impossible to hand off to a different engineer.
The typical LabVIEW user here is an experienced EE with limited SW engineering skills so I can see how a different "paradigm" might be appealing. As we all know, though, maintenance cost and sometimes performance also counts.
Also, I'm not sure why representing a program as data structures flowing between reusable components is described as something different or new. I think the major contribution of FBP, if such a thing really exists, is the GUI used to create these programs. Surely the fundamental building blocks have been programmed in a more traditional way.
"In my experience with LabVIEW, it was really great for making things like concurrency easy"
Absolutely. Ever since my stint with G, I've longed for a general purpose solution for handling flow control in concurrent code. If NoFlow avoids some of G's pitfalls, it could make an excellent addition to my programming toolbox.
I have two questions. First, what exactly is Flow-Based Programming? Emphasis on exactly. I know what dataflow is and I know who J. Paul Morrison is and I've even browsed through his book. I still can't figure it out, and the book (at least the parts I looked at) had too many diagrams and not enough code to clarify this most basic of questions. Every discussion on it seems hopelessly hand-wavey. What I want is the diffs between FBP and other computational models. Just the diffs, please! Or is it just dataflow? In that case, which version of dataflow? There have been many.
Second, we know from the history of these things that it's easy to sell managers and journalists on boxes-and-lines visual programming. The pictures look a lot easier to understand than reams of source code do, but that's always because the examples are trivial—invariably some variant of a box with 2 in it, another box with two in it, arrows leading from those to a box with + in it, and then an arrow leading to a box with 4 in it. These always turn out to be a siren song because they don't scale to application complexity. How exactly is FBP different? Emphasis on exactly.
I kept reading and reading through poetic descriptions of how valuable the method is, hoping to get to at least a short description of what the method actually is. Excitedly I clicked on "the company published FBP as a technical disclosure bulletin", only to get to the Wikipedia entry for "IBM Technical Disclosure Bulletin". Reluctantly I must conclude that the article is pure and content-less bullshit instead.
Well, we all know how reluctant scientists are to promote groundbreaking ideas, since all prestige in science comes from doing what's been done before.
No wait, scratch that. That's just in BizzaroWorld.
Yeah, I must have imagined the 1-2? computer science professors at MIT who had active data flow research programs when I showed up in 1979. The general opinion on campus was "this looks very interesting" but no one had yet figured out how to make it really work and be comprehendable.
The basic idea with FBP is that you have multiple processes that communicate over channels (kind of like actors, but the communication is unidirectional across those channels).
I'm not a fan of GUIs like this generally, but the idea of FBP is interesting in the same way that the actor model is interesting.
Aren't there like eleventy-bajillion enterprise tools that include exactly this kind of visual, dataflow-oriented methods of constructing large systems by wiring together individual components?
Its not exactly an "arcane" model that's been lost in the mists of time since its use in "1970s banking software".
And its very much not something that's been "suppressed by computer scientists for decades".
There are multiple communities of 'creative coders' who already work with this paradigm using tools like vvvv[0], MaxMSP[1], PureData[2] & others.
Closer(ish) to home we have QuartzComposer[3] available for OSX.
I like all of these tools but can't help feeling I'd be more effective if I could just get at the underlying code half the time (in cases where that's not an option).
How does flow-based programming compare with functional reactive programming, like Elm [1] and Bacon.js [2]? Could those be made visual with a graph editor like this? Bacon.js has some flow diagrams [3] to describe some of its advanced concepts.
The programming behind the JavaScript library is really solid, and was most actively developed from 2006 through 2009.
It never caught on, possibly because the mental model required for successfully hacking with "event streams" and "behaviors" is decidedly a functional one, and those concepts are quite abstract to begin with (more so than objects and prototypes). Also, studying the implementation is not for the faint of heart. On top of that, I don't think any big names got behind it and there wasn't exactly a marketing campaign.
Ahead of its time? Definitely. And it's probably still worth looking into as an alternative when trying to choose among the various reactive libraries that have popped up in the last year or so.
FRP is very similar in nature to FBP. (even the acronyms are similar) The main difference is in packaging.
The original FBP systems were still 70s-style near-metal code within the component design, but the architecture described a protocol just sufficient for statically and asynchronously connecting the components together, and a runtime method that is amenable to the simplistic approach of having each component run round-robin until all return a "finished" signal. It's very much an "industrial engineering" perspective.
FRP, on the other hand, comes from the traditions of functional programming, and so the evaluation order computation is given a more academic treatment, and the languages are given more explicit syntax, where FBP doesn't aim to describe itself much more deeply than the flowcharts. Both FRP and FBP have purity and immutability as core concepts.
So as I see it: different starting point, different packaging, same conclusions.
"Let's get non-musicians making music! We'll just give them a nice MIDI keyboard instead of that hard-to-use violin"
Sure, this will skip over some tricky bits of getting started with programming, just as a MIDI keyboard can make it easier to make violin sounds without having to learn all that pesky fingering.
However, as with playing the violin, those bits aren't really the hard part to learn; the easiest to use keyboard in the world won't make you a composer and flow based programming is not going to make you a programmer.
The title is sensationalist. The "coding method" is simply data flow programming. Many languages provide data flow facilities nowadays. The reason why graphical UIs for data flow languages have not become popular is that large programs become unwieldy to visualize and edit, whereas everyone know how to use text editors.
It makes me wonder at which point JavaScript will become more or equally unwieldy that using such a system will be a competitive trade-off. Of course, this is in detriment to the actual security and extensibility of so-called web apps. It's a great opportunity to coopt developers onto a platform with only industry-accepted functionality.
Here's the deal (and I'm sure that this is the same for most programmers): release something that uses this paradigm and let's me get something done and I'll use it. It's getting something done that matters. That's the same motivation for me using Go (easy concurrency), Perl (easy text mangling), Lua (easy embedded stuff), and on and on.
If Flow-Based Programming is the next big thing then great. Let's get at it.
But please don't sell me bullshit like: "The paradigm was so disruptive that it was suppressed by computer scientists for decades."
I haven't read the rest of the article, but I got to that phrase and my disposition instantly turned from "huh, this is interesting" to "snake oil", whether deserved or not.
Reminds me of the recent "One weird trick!" article [0] and lines like, "the simple solution dietitians don't want you to know!"
Content aside, that kind of thing immediately sets off alarms for me.
Flow based programming has a funny way of being suppressed... this has been tried many, many times. Some examples off the top of my head: Scratch, Windows Workflow Foundation, Arc Model Builder, etc. All of the marketing for NoFlo seems to be targeted at non-programmers who think "I could code anything if I could just understand the syntax!" Their main video basically says "Don't you wish you could finally stop paying those sneaky developers who act like everything takes longer than it really does? Now you can!"
>release something that uses this paradigm and let's me get something done and I'll use it
>This allows programmers to write individual functions that execute one step at a time, but route data between these functions asynchronously and concurrently
These concepts are not new. Concurrent programming is all about data pipelining, this is basically describing a gimped version of Erlang.. with pictures. The obvious practical advantages of a textual language make it laughable.
I thought this quote from the article was interesting:
Kuhn’s book on scientific revolutions includes a famous quote from physicist Max Planck about what really causes paradigm shifts:
"A new scientific truth does not triumph by convincing its opponents and making them see the light, but rather because its opponents eventually die, and a new generation grows up that is familiar with it."
Except, of course, scientists change their minds all the time based on the evidence.
Look at all the work in QM in the 20s and 30s. These guys had competing hypothesizes, and some won out based on the evidence. The people that held the opposing view? They quickly accepted the errors of their ways.
This is known as the bozo the clown argument. You know, somebody says "My perpetual motion machine will work! They laughed at Einstein, you know". And the reply is "yes, and they also laughed at bozo the clown".
Almost always, if everyone is against your idea, having tried it, you are probably wrong. There is probably no industry on the planet more open to change. We've gone from procedural to OO, functional programming is having a huge resurgence, static typed to dynamic typed, waterfall to extreme/agile/whatever, and so on.
And, despite the claims of the article, data flow programming has been alive and well the whole time. It hasn't been used much because of all the things that we have raised each time the topic is brought up, with no real response other than claims that we just don't get it, that people disagreeing is a sign that you are doing something right, and so on. I don't find it convincing at all. It's time to retire that Kuhn/Planck quote.
"'What we need is not more programmers. What we need is to enable non-programmers to participate in the creation process, not just the ideation process,' says Kenneth Kan, CTO of a company called Pixbi and a recent convert to flow-based programming."
Could not disagree more. I'm so tired of these initiatives to "get everyone coding!" Everyone can't be a programmer, just like everyone can't be a doctor and everyone can't be a mechanic. There are certain skills, mindsets, and desires that drive people to do what they do.
I think what most people don't realize is that thedailywtf is cathartic to the modern programmer. We really need less modesty and admit "Programs can be fucked up, and some people shouldn't be allowed to write them." (Of course, I don't care if a random person is fiddling with code in their spare time. It is when they are writing code that will be used by multiple people for years that ability starts to matter. Especially in large code bases.)
Anyway, back to the article...
Consider that a user wants to transform an input (inp) with operation X. Does it matter to them if X(inp) is a program they would invoke normally, or a function within an existing language? The former is probably more user-friendly, but both are conceptually similar. If the tool is handed to a user they can probably beat either solution together without much effort (assuming the environment to run said code isn't too complex).
But what if operation X is a unique problem that doesn't exist in a common library? The moment operation X needs to be written is where people need to become programmers (or have programmers do the work for them). If your business is large, pay professionals to do it, and let them get requirements and feedback from domain experts.
I'm asserting that management is capable of finding competent programmers. Which can be difficult. But hiring based on a mix of portfolio and credentials will probably yield better results than trying to train a domain expert to write code.
Getting back to the general point, there isn't a general solution for writing maintainable and scalable code. Being able to recognize good and bad code is a hard won skill. Being able to write and design it is even harder.
This article asserts that FBP is not only a silver bullet for designing large code bases, but also one so simple that a non-programmer can use it.
This isn't to say FBP is worthless. I think it could be used as a limited DSL in certain cases. For example, permitting an advanced user to describe a filter of data where conditional criteria for multiple fields.
Everyone can't be a doctor, but everyone should have a basic grasp of how their body works in order to live well.
Same with programming, if everybody had some base level of algorithmic literacy, they could at least have some idea if a mind-numbing repetitive task could be done with a simple script.
IFTTT does a great job of making it easy to glue web services together. NoFlo could be a powerful step up from that.
I agree that it is tiresome to see some of these initiatives, but you may consider the analogue that many people now can write, even though not everyone writes literature.
> Today’s web programmers grapple with problems that people in the early days never had to deal with. They’re building complex UIs, juggling a bunch of APIs, and running multiple processes at the same time. All of these tasks require mastering the flow of data between application components in real-time, something which even the most advanced developers struggle with.
No. The problem is not moving data around. The biggest problem on web development is the drive from the industry to shoe-horne applications on top of platforms that weren't meant for it.
Based solely on my previous experience with a "flow-based" programming system, which endeavored to make programming financial decision logic a matter of connecting boxes, it's the 80/20 problem. It makes 80% of the work dirt simple and able to be completed.
The remaining 20% still needs to be implemented in code, and takes most of the time. It got so bad that they actually ended up implementing "code" objects, just so the code could be edited and incorporated into directly into the tool instead of around it.
I'm a JS hacker working on the NoFlo UI, and one of our primary design goals is to make it easy to code new modules on the fly (in the same environment, with tests) when that makes more sense.
People waiting for "the breakthrough" that suddenly makes programming easy and available to all are kidding themselves. As others have said there's inherent complexity to programming and solving problems that can't be wished away with paradigm changing strategerized facilitations utilized by flow-optimized programmerators or whatever the secret code knowledge suppressed by scientists was prescribing.
On the broader point - and the comments by folks saying we should have made things better by now: we have. I started out learning to program with zero help, no tools, few manuals on an Apple II in some flavor of BASIC or machine code by trial and error.
Decades later having not coded a lick in more than 15 years I picked up Ruby On Rails quickly and easily (enough to get out MVP) and with the help of Stack Overflow and Google have spent the last three years getting better and better at it. I can do dramatically more today than I could have imagined in my days alone with an Apple II and a poor english translation of a poor chinese translation of a pirated Apple manual.
It's all better. The worst programmers have super powers available to them (they don't always use them admittedly) compared to prior days.
Things are getting better but they're earning it, not because "THEY" don't want you to know "SECRET KNOWLEDGE".
ya, my eyes gloss over when I read 'rediscoveries' like this ...
I think the finer point is more about workflow then programming.
That is state based workflow is fundamentally harder for developers to grok, also maintaining state is a kind of fallacy when scaling out and/or up.
Flow based workflows, while probably can't cover easily the breadth of exotic corner cases that FSM can achieve, are much easier to understand and state is byproduct of the system, not to mention that a full record of mutation occurs with a copy of data at every step (similar to MVCC - Multi-value-consistency-control)
Its nice to see yet another XML technology, which of course is based on older established concepts in computing, being emulated/replicated in the JS universe ... shame about the visual programming antipattern/lunacy.
I think programmers are always thinking about the flow of programs. Jumping through blocks of statements, following the chains of function calls and analysing their definitions when needed.
The _flow_ is there, but it's not visual. We are always imagining what would the compiler or interpreter do with our code.
On the other hand, we must be able to quickly navigate in the source tree. That's why text editors like Vim, that understand the contents of the programs (buffers, text objects, definitions), are so powerful. The same happens with Xcode, for example. The Interface Builder is a graphical tool that defines the code components as visually manageable objects.
Maybe the proposed paradigm could extend this ideas of representing the code in flows, as graphs of objects. I'm really curious to try it. Mainly because it seems to feet really well with handheld devices.
Okay, yeah, so I agree with most of the criticisms here. Flow-based languages didn't catch on because no-one came up with a really compelling general-purpose implementation that scales up to large, complex projects. It's not because it was actively suppressed by the programmer Illuminati to keep our salaries high.
I think the main reason FBP hasn't gone mainstream is because most implementations are built around a graphical programming environments (e.g. LabView, Pure Data, Scratch) in order to cater to non-programmers. But programmers love their text files, and for plenty of good reasons. Code represented as text can be edited by any general-purpose text editor, work well with version control systems, and can (usually) be easily split into separate files.
It's probably instructive, then, to look at a domain in which textual flow-based programming languages have become mainstream. I'm speaking, of course, about Hardware Description Languages, which are used by digital circuit designers to simulate and prototype complex circuits, like CPUs. The two dominant HDLs are VHDL and Verilog. Both of these languages use a flow-based model, in which logical blocks called entities are connected to each other through input and output ports. The reason these languages work is because the domain is a good fit for FBP and because they are designed for the domain experts (circuit designers) to use, and not for some non-technical manager to be able to understand.
Taking a similar approach to web programming may work. Logical blocks connected through ports. Except instead of ones and zeroes going through these ports, you have I/O events and data. I haven't looked at NoFlo, but it might be interesting.
Note that I'm not saying that VHDL and Verilog are good languages, even for their intended domain. They have plenty of warts, and a FBP language for software that basically copies one or the other would be terrible (especially VHDL; oh god, please nobody make VHDL for web programming). But the entity-port model is essentially sound, and I would be quite interested in a general-purpose language that adapts that model in a well thought-out way.
You know what costs us sanity? It's not code. It's people.
Scope creep. Last-minute specifications. Pointy-hairs who don't understand technical debt, and need everything done yesterday. Design by committee. Too many cooks in too many kitchens. Legacy processes, legacy data, legacy user habits. Unrealistic expectations, unrealistic timelines, and unrealistic budgets. Marginally competent coworkers. Office politics.
Compared to those, callback hell and and classitis are a dream come true. And while all the problems above are reducable with the right processes, you'll never shrink them all to zero.
"Algorithms may have mathematical underpinnings, but computer programming is a behavioral science." - @brixen
[+] [-] jliechti1|12 years ago|reply
I disagree with this. This might work fine for small programs, but will quickly fall apart for anything of significant size. National Instrument's LabVIEW [0] offers a graphical programming language called "G". G makes it easier for non-programmers (usually other types of engineers) to create the software they need. However, as their programs grow, they can easily get out of hand and become a dangled mess if they don't understand good program design. I am all for getting more non-programmers programming, but this method does not solve the need to understand programming fundamentals.
In my experience with LabVIEW, it was really great for making things like concurrency easy, and it was really great for quickly building GUIs to control hardware. I like to think that graphical programming makes some "hard" things easy, and some "easy" things hard (it's a bit manually intensive to make complex mathematical equations - though there are blocks you can use that let you drop in C code into the interface).
Like anything else, the methodology has its advantages and disadvantages.
[0]: http://en.wikipedia.org/wiki/LabVIEW
[+] [-] _pggx|12 years ago|reply
But like you said, I've looked over some previous LV projects that have multiple copy and pasted sections, terrible design, etc.
As a software engineer, LV holds you back in my opinion. I don't doubt for a second that some really amazing things can be created with LV but ultimately it is extremely tiring/annoying to reinvent the wheel to accomplish things that would be extremely simple in almost any other programming language. This seems to come into play when you move past the simple act of collecting data and doing primitive processing.
Edit: The other thing I forgot to touch on was the presentation of the "code". With wires running all over the place and ambiguous function blocks you quickly find yourself wishing you could cozy up with a text editor instead. The main reason I don't think data flow programming will "take over" all programming is because ultimately I think its a inferior presentation for professionals.
[+] [-] Serow225|12 years ago|reply
[+] [-] zwieback|12 years ago|reply
The typical LabVIEW user here is an experienced EE with limited SW engineering skills so I can see how a different "paradigm" might be appealing. As we all know, though, maintenance cost and sometimes performance also counts.
Also, I'm not sure why representing a program as data structures flowing between reusable components is described as something different or new. I think the major contribution of FBP, if such a thing really exists, is the GUI used to create these programs. Surely the fundamental building blocks have been programmed in a more traditional way.
[+] [-] albeec13|12 years ago|reply
May I ask why? I completely disagree with that statement and all the initiatives pushing that agenda.
[+] [-] meemoo|12 years ago|reply
NoFlo's UI design makes it frictionless to drop in to edit any component's JS, or build a new component.
[+] [-] lbenes|12 years ago|reply
Absolutely. Ever since my stint with G, I've longed for a general purpose solution for handling flow control in concurrent code. If NoFlow avoids some of G's pitfalls, it could make an excellent addition to my programming toolbox.
[+] [-] bergie|12 years ago|reply
I've written about this in http://bergie.iki.fi/blog/noflo-kickstarter-launch/
[+] [-] gruseom|12 years ago|reply
Second, we know from the history of these things that it's easy to sell managers and journalists on boxes-and-lines visual programming. The pictures look a lot easier to understand than reams of source code do, but that's always because the examples are trivial—invariably some variant of a box with 2 in it, another box with two in it, arrows leading from those to a box with + in it, and then an arrow leading to a box with 4 in it. These always turn out to be a siren song because they don't scale to application complexity. How exactly is FBP different? Emphasis on exactly.
[+] [-] jbellis|12 years ago|reply
It didn't really get better from there.
[+] [-] zeteo|12 years ago|reply
[+] [-] nathan_long|12 years ago|reply
No wait, scratch that. That's just in BizzaroWorld.
[+] [-] hga|12 years ago|reply
[+] [-] unknown|12 years ago|reply
[deleted]
[+] [-] dangoor|12 years ago|reply
http://c2.com/cgi/wiki?ActorsAndFlowBasedProgrammingDiscussi...
The basic idea with FBP is that you have multiple processes that communicate over channels (kind of like actors, but the communication is unidirectional across those channels).
I'm not a fan of GUIs like this generally, but the idea of FBP is interesting in the same way that the actor model is interesting.
[+] [-] dragonwriter|12 years ago|reply
Its not exactly an "arcane" model that's been lost in the mists of time since its use in "1970s banking software".
And its very much not something that's been "suppressed by computer scientists for decades".
[+] [-] keeran|12 years ago|reply
Closer(ish) to home we have QuartzComposer[3] available for OSX.
I like all of these tools but can't help feeling I'd be more effective if I could just get at the underlying code half the time (in cases where that's not an option).
[0] http://vvvv.org/ [1] http://cycling74.com/ [2] http://puredata.info/ [3] http://developer.apple.com/graphicsimaging/quartz/quartzcomp...
[+] [-] meemoo|12 years ago|reply
1. http://elm-lang.org 2. https://github.com/baconjs/bacon.js 3. https://github.com/baconjs/bacon.js/wiki/Diagrams
[+] [-] michaelsbradley|12 years ago|reply
http://www.flapjax-lang.org/docs/
https://github.com/brownplt/flapjax/
The programming behind the JavaScript library is really solid, and was most actively developed from 2006 through 2009.
It never caught on, possibly because the mental model required for successfully hacking with "event streams" and "behaviors" is decidedly a functional one, and those concepts are quite abstract to begin with (more so than objects and prototypes). Also, studying the implementation is not for the faint of heart. On top of that, I don't think any big names got behind it and there wasn't exactly a marketing campaign.
Ahead of its time? Definitely. And it's probably still worth looking into as an alternative when trying to choose among the various reactive libraries that have popped up in the last year or so.
[+] [-] chipsy|12 years ago|reply
The original FBP systems were still 70s-style near-metal code within the component design, but the architecture described a protocol just sufficient for statically and asynchronously connecting the components together, and a runtime method that is amenable to the simplistic approach of having each component run round-robin until all return a "finished" signal. It's very much an "industrial engineering" perspective.
FRP, on the other hand, comes from the traditions of functional programming, and so the evaluation order computation is given a more academic treatment, and the languages are given more explicit syntax, where FBP doesn't aim to describe itself much more deeply than the flowcharts. Both FRP and FBP have purity and immutability as core concepts.
So as I see it: different starting point, different packaging, same conclusions.
[+] [-] johnpmayer|12 years ago|reply
[+] [-] spellboots|12 years ago|reply
Sure, this will skip over some tricky bits of getting started with programming, just as a MIDI keyboard can make it easier to make violin sounds without having to learn all that pesky fingering.
However, as with playing the violin, those bits aren't really the hard part to learn; the easiest to use keyboard in the world won't make you a composer and flow based programming is not going to make you a programmer.
[+] [-] knz42|12 years ago|reply
[+] [-] AsymetricCom|12 years ago|reply
[+] [-] jgrahamc|12 years ago|reply
If Flow-Based Programming is the next big thing then great. Let's get at it.
But please don't sell me bullshit like: "The paradigm was so disruptive that it was suppressed by computer scientists for decades."
[+] [-] doorhammer|12 years ago|reply
Reminds me of the recent "One weird trick!" article [0] and lines like, "the simple solution dietitians don't want you to know!"
Content aside, that kind of thing immediately sets off alarms for me.
[0] http://www.slate.com/articles/business/moneybox/2013/07/how_...
[+] [-] hackula1|12 years ago|reply
[+] [-] pchristensen|12 years ago|reply
[+] [-] mtrimpe|12 years ago|reply
If it'll ever become big then it'll be more like what Javelin does by adding FRP to Clojure's persistent data structures [1]
[1] http://www.infoq.com/presentations/ClojureScript-Javelin
[+] [-] sanderjd|12 years ago|reply
[+] [-] adamnemecek|12 years ago|reply
[+] [-] HarryRotha|12 years ago|reply
[+] [-] _random_|12 years ago|reply
WWF: http://bit.ly/16YNGFK
[+] [-] wcummings|12 years ago|reply
>This allows programmers to write individual functions that execute one step at a time, but route data between these functions asynchronously and concurrently
These concepts are not new. Concurrent programming is all about data pipelining, this is basically describing a gimped version of Erlang.. with pictures. The obvious practical advantages of a textual language make it laughable.
edit for clarity.
[+] [-] unknown|12 years ago|reply
[deleted]
[+] [-] brianpaxe|12 years ago|reply
Kuhn’s book on scientific revolutions includes a famous quote from physicist Max Planck about what really causes paradigm shifts:
"A new scientific truth does not triumph by convincing its opponents and making them see the light, but rather because its opponents eventually die, and a new generation grows up that is familiar with it."
[+] [-] RogerL|12 years ago|reply
Look at all the work in QM in the 20s and 30s. These guys had competing hypothesizes, and some won out based on the evidence. The people that held the opposing view? They quickly accepted the errors of their ways.
This is known as the bozo the clown argument. You know, somebody says "My perpetual motion machine will work! They laughed at Einstein, you know". And the reply is "yes, and they also laughed at bozo the clown".
Almost always, if everyone is against your idea, having tried it, you are probably wrong. There is probably no industry on the planet more open to change. We've gone from procedural to OO, functional programming is having a huge resurgence, static typed to dynamic typed, waterfall to extreme/agile/whatever, and so on.
And, despite the claims of the article, data flow programming has been alive and well the whole time. It hasn't been used much because of all the things that we have raised each time the topic is brought up, with no real response other than claims that we just don't get it, that people disagreeing is a sign that you are doing something right, and so on. I don't find it convincing at all. It's time to retire that Kuhn/Planck quote.
[+] [-] albeec13|12 years ago|reply
Could not disagree more. I'm so tired of these initiatives to "get everyone coding!" Everyone can't be a programmer, just like everyone can't be a doctor and everyone can't be a mechanic. There are certain skills, mindsets, and desires that drive people to do what they do.
[+] [-] scj|12 years ago|reply
Anyway, back to the article...
Consider that a user wants to transform an input (inp) with operation X. Does it matter to them if X(inp) is a program they would invoke normally, or a function within an existing language? The former is probably more user-friendly, but both are conceptually similar. If the tool is handed to a user they can probably beat either solution together without much effort (assuming the environment to run said code isn't too complex).
But what if operation X is a unique problem that doesn't exist in a common library? The moment operation X needs to be written is where people need to become programmers (or have programmers do the work for them). If your business is large, pay professionals to do it, and let them get requirements and feedback from domain experts.
I'm asserting that management is capable of finding competent programmers. Which can be difficult. But hiring based on a mix of portfolio and credentials will probably yield better results than trying to train a domain expert to write code.
Getting back to the general point, there isn't a general solution for writing maintainable and scalable code. Being able to recognize good and bad code is a hard won skill. Being able to write and design it is even harder.
This article asserts that FBP is not only a silver bullet for designing large code bases, but also one so simple that a non-programmer can use it.
This isn't to say FBP is worthless. I think it could be used as a limited DSL in certain cases. For example, permitting an advanced user to describe a filter of data where conditional criteria for multiple fields.
[+] [-] meemoo|12 years ago|reply
Same with programming, if everybody had some base level of algorithmic literacy, they could at least have some idea if a mind-numbing repetitive task could be done with a simple script.
IFTTT does a great job of making it easy to glue web services together. NoFlo could be a powerful step up from that.
[+] [-] smokel|12 years ago|reply
[+] [-] hcarvalhoalves|12 years ago|reply
No. The problem is not moving data around. The biggest problem on web development is the drive from the industry to shoe-horne applications on top of platforms that weren't meant for it.
[+] [-] falcolas|12 years ago|reply
The remaining 20% still needs to be implemented in code, and takes most of the time. It got so bad that they actually ended up implementing "code" objects, just so the code could be edited and incorporated into directly into the tool instead of around it.
[+] [-] meemoo|12 years ago|reply
[+] [-] richardjordan|12 years ago|reply
On the broader point - and the comments by folks saying we should have made things better by now: we have. I started out learning to program with zero help, no tools, few manuals on an Apple II in some flavor of BASIC or machine code by trial and error.
Decades later having not coded a lick in more than 15 years I picked up Ruby On Rails quickly and easily (enough to get out MVP) and with the help of Stack Overflow and Google have spent the last three years getting better and better at it. I can do dramatically more today than I could have imagined in my days alone with an Apple II and a poor english translation of a poor chinese translation of a pirated Apple manual.
It's all better. The worst programmers have super powers available to them (they don't always use them admittedly) compared to prior days.
Things are getting better but they're earning it, not because "THEY" don't want you to know "SECRET KNOWLEDGE".
[+] [-] unknown|12 years ago|reply
[deleted]
[+] [-] jimfuller|12 years ago|reply
I think the finer point is more about workflow then programming.
That is state based workflow is fundamentally harder for developers to grok, also maintaining state is a kind of fallacy when scaling out and/or up.
Flow based workflows, while probably can't cover easily the breadth of exotic corner cases that FSM can achieve, are much easier to understand and state is byproduct of the system, not to mention that a full record of mutation occurs with a copy of data at every step (similar to MVCC - Multi-value-consistency-control)
This is similar to how http://www.w3.org/TR/xproc/ XProc works, which has a serious implementation in http://xmlcalabash.com/ and slowly gaining adoption in XML circles.
Its nice to see yet another XML technology, which of course is based on older established concepts in computing, being emulated/replicated in the JS universe ... shame about the visual programming antipattern/lunacy.
[+] [-] a0|12 years ago|reply
On the other hand, we must be able to quickly navigate in the source tree. That's why text editors like Vim, that understand the contents of the programs (buffers, text objects, definitions), are so powerful. The same happens with Xcode, for example. The Interface Builder is a graphical tool that defines the code components as visually manageable objects.
Maybe the proposed paradigm could extend this ideas of representing the code in flows, as graphs of objects. I'm really curious to try it. Mainly because it seems to feet really well with handheld devices.
[+] [-] zhemao|12 years ago|reply
I think the main reason FBP hasn't gone mainstream is because most implementations are built around a graphical programming environments (e.g. LabView, Pure Data, Scratch) in order to cater to non-programmers. But programmers love their text files, and for plenty of good reasons. Code represented as text can be edited by any general-purpose text editor, work well with version control systems, and can (usually) be easily split into separate files.
It's probably instructive, then, to look at a domain in which textual flow-based programming languages have become mainstream. I'm speaking, of course, about Hardware Description Languages, which are used by digital circuit designers to simulate and prototype complex circuits, like CPUs. The two dominant HDLs are VHDL and Verilog. Both of these languages use a flow-based model, in which logical blocks called entities are connected to each other through input and output ports. The reason these languages work is because the domain is a good fit for FBP and because they are designed for the domain experts (circuit designers) to use, and not for some non-technical manager to be able to understand.
Taking a similar approach to web programming may work. Logical blocks connected through ports. Except instead of ones and zeroes going through these ports, you have I/O events and data. I haven't looked at NoFlo, but it might be interesting.
Note that I'm not saying that VHDL and Verilog are good languages, even for their intended domain. They have plenty of warts, and a FBP language for software that basically copies one or the other would be terrible (especially VHDL; oh god, please nobody make VHDL for web programming). But the entity-port model is essentially sound, and I would be quite interested in a general-purpose language that adapts that model in a well thought-out way.
[+] [-] lukifer|12 years ago|reply
Scope creep. Last-minute specifications. Pointy-hairs who don't understand technical debt, and need everything done yesterday. Design by committee. Too many cooks in too many kitchens. Legacy processes, legacy data, legacy user habits. Unrealistic expectations, unrealistic timelines, and unrealistic budgets. Marginally competent coworkers. Office politics.
Compared to those, callback hell and and classitis are a dream come true. And while all the problems above are reducable with the right processes, you'll never shrink them all to zero.
"Algorithms may have mathematical underpinnings, but computer programming is a behavioral science." - @brixen