Has Flow-Based Programming's Time Arrived? 268
An anonymous reader writes "Flow-based programming keeps resurfacing lately. FBP claims to make it easier for non-programmers to build applications by stringing together transformations built by expert programmers. Many projects have already been using similar approaches for a long time, with less (or different?) hype. Is it time to take a closer look at flow-based programming? 'Clean functions – functions without side effects – are effectively pure transformations. Something comes in, something goes out, and the results should be predictable. Functions that create side effects or rely on additional inputs (say, from a database) are more complicated to model, but it’s easier to train programmers to notice that complexity when it’s considered unusual. The difficulty, of course, is that decomposing programs into genuinely independent components in a fine-grained way is difficult. Many programmers have to re-orient themselves from orthodox object-oriented development, and shift to a world in which data structures are transparent but the behavior – the transformation – is not.'"
Like libraries? (Score:4, Insightful)
old is new is old is new is old is...new?
Re:Like libraries? (Score:5, Insightful)
Fishing through that programming environment's icon set for the correct function is very close to what I imagine hell must be like.
What fun! Graphical patch cables! (Score:3)
This idea was obsolete when I did a subject in doing this sort of programming for analog computers (patch cables to amplifiers) in the 1980s. Oddly enough a good way to design analog computers was to optimise the model which started with discrete comp
Re: (Score:2)
Re: (Score:3)
It's not new at all, but doesn't have to be. It's a paradigm that has been challenging the CS community to build a good UI or language around for decades. So far the results have been mediocre.
It's good to see a more serious effort, however, using side-effect-free FBP isn't exaclty a good first step towards making a natural feeling UI, given that functional programming is essentially the polish arithmetic of the programming field, and is absolutely awful at modeling real-time.
Re:Like libraries? (Score:4, Funny)
Actually, sounds more like LabView.
Fishing through that programming environment's icon set for the correct function is very close to what I imagine hell must be like.
They have an icon for every possible programming function?
http://www.devtopics.com/wp-content/uploads/2009/04/image6.png [devtopics.com]
Re: (Score:2)
They have an icon for every possible programming function?
Yep, the environment is completely graphical, and so logic flows (if, while), arithmetic operations (+, -), boolean operations, and string operations, all require you to find the right icon.
Re: (Score:3)
Flow based? Sounds like MONIAC.
http://en.wikipedia.org/wiki/MONIAC_Computer [wikipedia.org]
Re:Like libraries? (Score:4, Insightful)
Actually, sounds more like LabView. Fishing through that programming environment's icon set for the correct function is very close to what I imagine hell must be like.
I suspect that it's pretty strongly dependent on implementation, with two main drivers: On the one hand, you have the needs of essentially-not-programmers-at-all, who have some input that needs to travel through a series of tubes and get transmogrified. The results aren't going to be pretty; but it's a legitimate need. (there are also those who argue that it's a good pedagogical approach for young children, as in classic Klick 'n Play [wikipedia.org](published by Maxis in the US, international publishing and titles are strangely all over the map, or the more recent Scratch [mit.edu].
On the other hand, "Flow-based programming" is essentially another flavor of Functional Programming, which seems likely to never truly die, no matter how obscure in real-world use, because of how central the concept of 'functions' in some reasonably generalized sense is to mathematics, ensuring a ready supply of people ready to charge into the breach and try to bring the elegance of pure mathematics to programming. Again.
Re: (Score:2)
the needs of essentially-not-programmers-at-all, who have some input that needs to travel through a series of tubes and get transmogrified
The needs of those who need to send input through a series of tubes and get transmogrified are already fulfilled by NSA and Gitmo.
Re: (Score:3)
Flow is a very different paradigm from FP. Technical features of FP such as tail recursion are not a specific part of flow programming, because while functional programming is intended to apply at every level of code, whereas flow programming is simply modular coding taken to an extreme.
In fact, while functional programming is a form of classic declarative programming, flow is essentially an attempt to implement something approaching semantic programming within the declarative paradigm. It's an attempt to d
Re: (Score:2)
Re:Like libraries? (Score:5, Funny)
Old being the new new has already gotten old. Old is the new old, new is the new new.
Re: (Score:3)
I still think that your average business application that mainly updates a db and has pretty vanilla looking maintenance screen is easier to code using the old style procedural approach, rather than trying to treat an invoice / customer / complaint as an object.
I realise you wouldn't write GTA using procedural programming, but for certain tasks it just makes things simpler.
Re: (Score:3)
"My thoughts exactly. Isn't 'flow based programming' just a renaming of 'procedural programming'? "
No. It's "black box" design.
This approach came along a long time ago with the advent of integrated circuits. The IC is a "black box". Give it input meeting certain specifications, get output of certain specifications.
The advantage of "black box" design is that you don't need to know what goes on inside the boxes (thus the name). You just put the boxes together in the right combination to get the result you want.
There are disadvantages to black box design:
All the inputs and outputs must be specif
Re: (Score:2)
So in other words, "black box programming" is a marketing term for using libraries.
Re: (Score:2)
For instance, the C standard library does not in any way present a system equivalent to black boxes. Some of the functions certainly qualify, but many do not.
Pretty much the only languages where you will find black-box equivalent libraries are the pure functional languages which there arent that many (most are hybrids that trade off purism for side-effects on purpose.) In the object oriented world, all objects must be immutable or you cannot
Re: (Score:2)
Not true. If you wrote a very small library with one class that contained a threadsafe counter, it would be both mutable, and quite possible to guarantee it's behavior (within the limits that can be guaranteed by the compiler, OS, hardware, etc), including all edge and corner cases. In other words, a mutable black box is entirely possible in OO code.
Your argument is akin to the one that says that it is impossible
Re: (Score:2)
An object has state, you have to initialize it, use it's functions in the right order or things will explode. Flow based programming is more like your Unix shell, where you have "cat | sort | uniq | ..." and don't have to worry about the state "sort", you simply throw data into it at once end and data comes out at the other.
Re: (Score:2)
Not entirely true. If you give sort a very large file, it's going to explode. You do need to worry about the state of the data that you're passing in, and what it will do to the state of the sort program.
On the flipside of the coin, well written OO code will practically initialize your objects for you, and keep you from doing stupid stuff with them (mutexes, etc). Yeah, I wish mor
Re: (Score:2)
Do you know that for sure? I imagine that if you pass it a huge file over standard input you might run into issues due to physical memory, but not knowing the implementation, that's about as far as I'd be willing to go. One can certainly imagine a case where giving it a file argument instead of standard input would result in it using an efficient approach for that circumstance.
Is It The Language Or The Library? (Score:2)
Re: (Score:3)
Both. For different reasons. In this context, specifically, I've not run into anything quite as useful as UNIX pipes anywhere else. They are somewhat limited to manipulating a stream of data, but they are eminently versatile with minimal typing, and minimal code confusion. This is language feature.
Sometimes libraries attempt cool things like this by using operator overloading, etc, but it's not the sam
Re: (Score:2)
My thoughts exactly. Isn't 'flow based programming' just a renaming of 'procedural programming'? I still think that your average business application that mainly updates a db and has pretty vanilla looking maintenance screen is easier to code using the old style procedural approach, rather than trying to treat an invoice / customer / complaint as an object.
Well to each his own, but to me it sounds like a near ideal case for OOP... every object is steward for a data row. Particularly if you're doing a MDI interface where you're reviewing a complaint and is looking through the customer profile, invoices etc. to see if the complaint looks genuine. There's no fixed order, there's no nesting level, there's no lifespan so the call of procedures might go like
viewComplaint()
viewCustomerHistory()
viewInvoice()
closeCustomerHistory()
submitAndCloseComplaintAnswer()
closeIn
Re: (Score:3)
Well to each his own, but to me it sounds like a near ideal case for OOP... every object is steward for a data row.
If your database is relational, it's actually a horrible idea because the objects are essentially materializations of potentially ephemeral tuples (selects generate ephemeral virtual relations that don't need to be materialized to have other operations work on them). That would make sense for only the base tables which are on non-volatile media, but if you insist on turning relational tuples into objects, you're screwing up the whole relational algebra thing.
I don't see how this is a good idea because you'r
Re: (Score:2)
Oh, boy. Hate to break it to you, but SQL is a de-facto procedural language masquerading as a declarative language. Think of it as a specialized interpreted scripting language. Yeah, the language does a bunch of stuff for you on its own, but so does any other procedural scripting language.
Re: (Score:2)
Object orientationâ(TM)s main purpose is to reduce complexity by keeping data (structure) and function in one place. In fact, your example is a perfect fit as such applications tend to become a right mess in a procedural manner as many parts access the same data.
Except that virtually all object-oriented languages (if not all of them - certainly all widely used) are procedural in nature.
Re: (Score:3)
A statement that has no meaning.
It has a meaning. It means that an OO language is not likely to be declarative/goal-oriented.
OO programming adds an additional layer of discipline. It says that objects are expected to be responsible for themselves, not simply containers for data that can be directly manipulated at the whims of external code.
Alan Kay says it quite clearly what OO means. Extreme late binding and messaging are the crucial points here. According to your description, all that OO would do for you is adding a little more structure to your source files, yet OO in Alan Kay's original sense gives you much more power, for example to catch message sends themselves (because the method selection mechanism itself is supposed to be late-bound!) and ma
Re: (Score:2)
Granted you can achieve the same properties by procedural programming (i.e. require the use of special functions to access the data) but that is just usinf the proverbial hammer to hit the screw
I am often amazed at this reasoning. So using an OO language where you require the use of special functions in a special place to access the data is OK, but using a bog-standard procedural language and having the same requirements is somehow the old "hammer vs screw" idiom.
I got news for you: Invoking some well known and often accurate idiom while making your argument doesnt make your argument accurate.
There is value in making such things formal but there is also value in not enforcing rules just for t
Re: (Score:3)
I was more "like bash scripts?"
"easier for non-programmers to build applications" (Score:5, Insightful)
Gee, never heard that one before.
What the people pushing these ideas don't seem to know is that it's not the tools, it's the way of thinking about a problem. I once worked at a place where we made a manager a tool that would let him create his own reports, and he immediately started adding up all flavors of apples and oranges (e.g., dollars of this and pounds of that). Then he wanted the small IT staff to help him make sense out of his reports.
Re: (Score:3)
Re: (Score:2)
Re: "easier for non-programmers to build applicati (Score:3)
A complex problem won't be simpler just because the tool isn't as powerful. All these ideas comes from a fundamental misunderstanding about what it is that actually makes system development hard.
Re: (Score:2)
A complex problem won't be simpler just because the tool isn't as powerful. All these ideas comes from a fundamental misunderstanding about what it is that actually makes system development hard.
But, if you break a complex problem down into it's simpler components and solve each of those components, then a simpler tool can be used on the components and the components strung together to solve the complex problem. That is how you solve a business problem in the real world. That is also how you solve a programming problem.
Re: (Score:2)
Re: (Score:2)
Gee, never heard that one before. What the people pushing these ideas don't seem to know is that it's not the tools, it's the way of thinking about a problem. I once worked at a place where we made a manager a tool that would let him create his own reports, and he immediately started adding up all flavors of apples and oranges (e.g., dollars of this and pounds of that). Then he wanted the small IT staff to help him make sense out of his reports.
Yep.
And even if they do get good at using it, now you've got a {whatever} doing "programming" (in a limited clunky "environment/language") instead of {whatever it was they were supposed to be doing}.
There's a marketing manager in my last job's company doing exactly that (not entirely unrelated to why it is my last job). I'm glad he's having fun playing programmer, but he does even less actual marketing than he was doing before ...
Re: (Score:2)
Gee, never heard that one before.
What the people pushing these ideas don't seem to know is that it's not the tools, it's the way of thinking about a problem. I once worked at a place where we made a manager a tool that would let him create his own reports, and he immediately started adding up all flavors of apples and oranges (e.g., dollars of this and pounds of that). Then he wanted the small IT staff to help him make sense out of his reports.
Yep.
And even if they do get good at using it, now you've got a {whatever} doing "programming" (in a limited clunky "environment/language") instead of {whatever it was they were supposed to be doing}.
There's a marketing manager in my last job's company doing exactly that (not entirely unrelated to why it is my last job). I'm glad he's having fun playing programmer, but he does even less actual marketing than he was doing before ...
If their job involves the collecting of data and assimilating it and compiling it into various formats, etc., as in marketing reports, and they can't get the data unless they do it them self, I'm pretty sure the organization would fault the IT shop and not the manager. Managers are usually evaluated on results and if the result is the reports, then he/she is successful.
Re: (Score:2)
Gee, never heard that one before.
What the people pushing these ideas don't seem to know is that it's not the tools, it's the way of thinking about a problem. I once worked at a place where we made a manager a tool that would let him create his own reports, and he immediately started adding up all flavors of apples and oranges (e.g., dollars of this and pounds of that). Then he wanted the small IT staff to help him make sense out of his reports.
While I understand what you are saying, it is hard to argue that Microsoft's Visual Basic and Access effectively allowed millions of non-programmers to build applications. Were they good, robust applications? Probably not, at least most of them. But at the time, those products were first released and centralized IT shops ruled, most departments would never have had their requests get high enough up the priority list to every be programmed by a "real" programmer.
Unfortunately, VB's own success killed it for
Re: (Score:2)
And before long, the whole company descends into chaos. Can we please keep non-programmers AWAY from trying to cobble together automated systems? While we're at it, can management please be made to bother to consult the development department BEFORE making technical decisions on things such as data structures, key formats etc?
The ugly trick is that if you want to keep non-programmers away from something, some programmer has to take one for the team and gingerly approach whatever horrible little ad-hoc business logic problem or whatever the non-programmer was trying to solve. If dual-class programmers were in ready supply, it's not like the non-techies would be clamoring for more chances to get their hands dirty.
Re: (Score:2)
The ugly trick is that if you want to keep non-programmers away from something, some programmer has to take one for the team and gingerly approach whatever horrible little ad-hoc business logic problem or whatever the non-programmer was trying to solve. If dual-class programmers were in ready supply, it's not like the non-techies would be clamoring for more chances to get their hands dirty.
I don't think that is true. End users have been doing their own thing for decades. They usually just do it with spreadsheets and databases. In the old days it was Lotus and dBase, today Access and Excel. In the 90s there was a lot of VB programs written by end users that while not of professional quality, surely got the job done for their purpose.
The reason that end users get their hands dirty has nothing to do with the availability of programmers overall. It is the priority of their projects compared to t
I use it (Score:2)
No. (Score:3)
it wasn't a good idea to start with and it hasn't gotten any better since then.
Re:No. (Score:4, Informative)
I disagree. I have been playing around lately with GNU Radio Companion [gnuradio.org], designing SDR (software-defined radio) tools using a cheap DVB dongle [osmocom.org]. The transformations of the signal into a human-digestible format is made very easy. I am a software engineer -- I have written a lot of code. But there is a certain class of problems that lend itself to flow-based programming. GRC is one. And ETL tools are another. That is not to say that one does not, from time to time, have to write one's own code block. I have done that for GRC and for some ETL tools. But for 99% of what I have needed, a simple flow graph was all that was required.
National Instruments LabView (Score:4, Insightful)
Re: (Score:2)
So did Prograph, now morphed into semi-comatose Marten. It is an object-oriented data -flow language. I quite liked it. I don't know if it makes programming easier or programs easier to understand, but had a very credible view of how to build apps.
Easier (Score:2)
Re:Easier (Score:5, Insightful)
Welcome to the late 90s. Out here 15 years later, nobody uses UML. The idea of UML as code is completely dead, the corpse was staked, burned, and scattered to the four winds. It never worked. The only thing that's left of it is class diagrams, which people were doing 20 years before UML existed (if not longer).
Re: (Score:2)
Oh, I do. But while they may use a few other types of diagrams, nobody uses UML to draw them. Especially not state diagrams- they got those completely wrong, and completely different from how existing disciplines like EE do them.
(For that matter most class diagrams don't use UML either- if you aren't going to be nitpickingly formal it adds nothing. The only time you'll see it is when its automatically generated).
Java Streams (Score:2)
Re: (Score:2)
That's functional programming, not flow programming...
The problem is the transformations don't exist (Score:5, Insightful)
The basic problem is that, while it sounds great in theory, in practice the transformations you want don't exist. If they did, you'd have software doing the job already and you wouldn't need to create it. Your business isn't going to go very far just doing the same thing everybody else is doing, is it? You need to be doing something they aren't. Which means, in this context, you need transformations that don't already exist (either because they haven't been written yet (ideally) or because the people who wrote them are keeping them confidential to keep you from copying what their business is doing (less than ideal)). So on top of your FBP team stringing components together, you're still going to need that expensive conventional development team to write the components for the FBP team to string together. You haven't saved much, in fact it's probably costing you more than just having the conventional dev team.
Plus, stringing components together isn't quite as simple as it sounds. Real-world systems usually depend on interaction and complex relationships between otherwise simple components. Keeping track of the synchronization between all those parts and keeping everything coordinated is usually the hard part. For instance, when creating an application to set up appointments the part where you take a set of existing appointment slots (some occupied, some free) and a set of one or more slots the customer would like ordered by preference and determine the best requested slot to put them in is easy. Picking up the current set of slots, putting them up on a Web page in a sensible way, letting the user select what ones work for them and set the order of preference, sending that information back to the server and, across this whole process, making sure that either nobody could alter the assigned appointments between the time you picked them up to display and the time the customer hit Submit and you started to sort out the assignment, that's nowhere near as simple. Doing this in a modern system with multiple servers where the submission may not go back to the server that handled the initial request, when you've got thousands of customers and hundreds of your users making, changing and cancelling appointments at the same time, ... can we say "highly non-trivial"? And it really doesn't fit the FBP model at all.
Even where things fit the model, it's rarely as simple as "just string them together". I work with software that fits that model. Well, it did. Once. Long ago. And then the business people said "Oh, but customer A wants it do to some other thing if it's a transaction for them.". Followed by "Well, we want to do X, unless C applies in which case we want to do Y.". "Oh, unless M was specified for the account, in which case do X even when C applies except where X set V to 7 we need it set to 14.". Lather rinse repeat for 10 years and the quick one-line summary version ran to 5 pages single-spaced. Until that is we tried to print it out and found things were nested so deep some lines were starting past the right-hand edge of standard letter paper, so it's more like 10 pages, legal-sized, in landscape mode.
Re: (Score:2)
The solution is to allow stringing together existing components, as well as a good API for creating additional components. This way, you could tell your 'real' programmers "I need a module that calculates FFT, but changes some parameters depending on this other output", and they would write in in a 'real' language and export the interface to your 'toy' language.
Many great programming languages are great because they're simple and it's easy to create new modules for them. A stellar example is Python with mod
Re: (Score:3)
The problem is proponents of flow-based programming propose that non-technical people will be able to create world-facing production applications such as web-apps and mobile applications, which although theoretically possible is completely impractical. ...and someone in the business will always want customisation anyhow.
Behavior Engineering + Flow-based programming (Score:3)
Re: (Score:2)
If there is one constant to programming, it is that requirements change. So any system that generates skeletons that then you have to work with will lead to utter failure, as you'll quickly reach a point where you can't generate anymore.
Remember the CASE tool craze, with Rational Rose and the like? It's pretty related to what you describe, but nothing good ever came out of it.
Not new (Score:3)
It may or may not be a good idea, but it's not new. The article is not very good, either. It's all over the place, from punched cards to XML.
Data flow programming has been tried many times. It's used heavily in GPUs, where pipelines are the only way to get work done. So there's reasonably good understanding today of what can and can't be done by data flow methods.
If you like "flow-based programming", one easy way to do it is to write programs in single-assignment style. Assign to each variable only once, and make it "const" or read-only if your language supports it. This makes your program a directed acyclic graph. Single assignment is a lot like functional programming, but values have names and the nesting depth of calls doesn't get so deep. It's also possible to use the same result as input to more than one function, which is hard to do in pure functional programming (That's the difference between a directed acyclic graph and a tree.)
The use of pure functions makes for cleaner programs, but more data copying. Data copying isn't necessarily bad today. It's cheap to copy data you just used or created, because it's in the cache. Modern CPUs have wide buses, are good at copying, and can probably do the copy in parallel with something else. Don't avoid copying data to "improve performance" unless the data item is large.
The place where this all comes unglued is when the program's goal is to affect something, not grind data down to a "result". Trying to write a GUI in a functional style is tough. (I once wrote a GUI in pure Prolog. Very bad idea.)
Re: (Score:3)
The use of pure functions makes for cleaner programs, but more data copying. Data copying isn't necessarily bad today. It's cheap to copy data you just used or created, because it's in the cache. Modern CPUs have wide buses, are good at copying, and can probably do the copy in parallel with something else. Don't avoid copying data to "improve performance" unless the data item is large.
If you treat your data structures as also obeying Single Static Assignment rules, you can share them widely by reference. That reduces the number of copies. With a sufficiently smart compiler/reference management engine, you can even go to using copy-on-write-to-shared, so that operations on an unshared value that is about to be replaced can be done inline. That gets the number of copies down even further, to nearly the level that you have with classic shared-writable-state programming, except without any o
Re: (Score:2)
With a sufficiently smart compiler/reference management engine, you can even go to using copy-on-write-to-shared, so that operations on an unshared value that is about to be replaced can be done inline. That gets the number of copies down even further, to nearly the level that you have with classic shared-writable-state programming, except without any of that mysterious changing-behind-your-back behaviour.
The best way to get the smart compiler/reference management engine, of course, is to use a functional programming language rather than try to emulate functional style in an imperative language.
re-orient (Score:2)
No, they most absolutely do not. Ideas come and go, and if programmers would 're-orient' themselves each time, they would be spinning endlessly and not get any work done.
As always, choose the proper approach, the proper tools, the proper environment, the proper language, and do the job. Let the
A.k.a shell scripts (Score:5, Interesting)
grep EVENT log*.txt | sort | uniq | awk '{print $2}' | ssh reportserver "gzip > results.txt.gz"
Flow based, side effect free, distributed computing on one line. There is a reason shell scripts refuse to die in the face of python, perl or anything else.
Indeed, actually exists FBP shell based FBP lib (Score:2)
Indeed, unix pipes, especially if usning named FIFOs as well, is a subset of the Flow based programming paradigm fullfilling quite a bit of it's specifications. A full FBP implementation adds a few things like option ports (could be done in shell with parameters though), custom information packet design (is only text strings in unix), and so called "initiation information packets", and surely a few more.
There is actually an attempt at implementing a full FBP system in shell scripts only, which is kind of co
Re: (Score:3)
Re: (Score:2)
You scoundrel! You can do pipes in Perl! Tsk, tsk, tsk!
it's not too bad if you don't care about getting the result back. I recently implemented an actual pipe-based system in perl where the results did need to be bidirectional, with open3, and ... well, it ain't pretty.
It's a real shame perl doesn't have the capability integrated into the core language with nice syntactic sugar.
Talend already used it successfully (Score:3, Informative)
Talend.com offers Talend Open Studio - a great free software product for flow-based visual programming, based on Eclipse.
I used it for projects for 5 years and was amazed, how easy to make complex data transformation by dragging and dropping components and links.
A result is a java (or Perl) program, which can run standalone.
The program is a visual data flow, easy to modify and understand even for non-programmers.
I really appreciate Talend team effort and recommend this product for all, who need data transformations.
Not Data Flow Programming (Score:2)
I scanned the summary as "data flow programming" and had flashbacks to university research projects around data flow computing... in the mid-1980's (probably before many of the 'hip' programmers were born). Alas, it was not to be the resurgence of programming in SISAL... just a another programming-by-drawing rehash. Imagine my disappointment.
Done. (Score:3)
"Everything Flows"
-Cyberneticists
We already have this. It is called "Unix" (Score:2)
As some other people already remarked, on the face of it this looks like the venerable Unix approach of small tools in a script. My point is that the real world outside, that you are trying to capture in a programming language, can be very complicated. For some domains, e.g. logic or arithmetics, the language can be pretty complicated too - see APL, LISP or Prolog.
But in thirty years of programming (computational linguistiscs), I have found that Unix scripts, awk and plain C covered pretty much 90% of (my)
The Last One (Score:2)
http://en.wikipedia.org/wiki/The_Last_One_(software) [wikipedia.org]
This is what BPEL and executable BPMN promise (Score:2)
Not this again! (Score:4, Informative)
This has been tried over, and over again many times over the last 30 years.
It just plain-old doesn't work. You get inefficient, bloated code at the best of times, and 99% of the time you need some sort of custom function that still requires conventional software development.
So, no, flow-based programming's time has _NOT_ arrived.
Re: (Score:3)
Bingo.
Every time some cretin tries to shoe-horn the entirety of computer programming into one simple paradigm, a ton of other cretins jump up and down hailing him as the new messiah.
And then, after a couple years worth of CS students have been corrupted with this useless crap and it hits the real world, it turns out that life is a wee bit more complicated.
Re: (Score:2)
Amen. I landed a position on a research project developing a graphical programming language almost exactly thirty years ago. It was newer then, but still not really new. People were probably wanting executable flowcharts since at least the 1960s, if not earlier.
A lot has changed over the last thirty years, but nothing that addresses the fundamental issues with graphical flow-based programming. Sure, some products have enjoyed some success, but it's still a niche approach, destined to remain a niche approach
Unix pipe (Score:4, Insightful)
So you mean like unix pipe. Where you have those wonderful transformations like sed, grep, cut, sort, etc ? Youngsters.
Re: (Score:3)
So you mean like unix pipe. Where you have those wonderful transformations like sed, grep, cut, sort, etc ? Youngsters.
Yes, but with strongly-typed (rather than stringly-typed) data.
FlowVR (Score:2)
It is advertised towards high-performance computing but suits small applications just fine.
Real Problem (Score:2)
People are not able to describe their problems and requirements in a conflict free way. You may reduce the amount of technical experience, like how to use J2EE or network communication etc., however, the complexity of software solutions cannot be hidden by a non creative system. Research has tried this, they even tried to use AI, it all cannot help you with the first step. Understand what you want. The second step, transforming requirements to architecture is also a creative task and cannot be mechanized. A
aka functional programming? (Score:3)
Lambda calculus predates the invention of the compiler. It's always funny when programmers rediscover stuff and think they've invented something new. :P
my 2 cents (Score:2)
A modern library implementing dataflow programming is: https://rx.codeplex.com/ [codeplex.com]
The relationship between the actor model and flow based programming is discussed here: http://c2.com/cgi/wiki?ActorsAndFlowBasedProgrammingDiscussion [c2.com]
Personally i like using f# with rx using this wrapper: https://github.com/fsharp/FSharp.Reactive [github.com]
I see FBP as a generalized form of functional programming where you can, and have to, specify how the expressions are put together temporally.
It gives you the advantage of automatic (in rx
Re: (Score:2)
Fail (Score:3)
This notion of allowing non-programmers to do programming is flawed on its face. The challenges of programming can not be overcome by drawing some cute pictures. And if you have expert programmers making the building blocks it will only take them a few minutes more to connect them which eliminates the need for the "non-programmer" entirely. Then there is this notion of "pure functions". Dude, functional programming is a fad. Real programs manipulate data.
I've been "programming" with Simulink for 5 years now and it's great for control systems but shit for most other kinds of programming. So let your controls engineer use it to design and test and even generate C code. Then drop that code into your app and call it as a function. Never let that guy convince your organization that this is the way to go and ALL of the software should be created this way.
VRML (Score:2)
This sounds like the event system of VRML. I really like that. There are "EventIns" and "EventOuts", and they can be transformed. So you can define a "TimeSensor" that generates a scalar signal to be fed into a RotationTransformer which is linked to a piece of geometry to make it spin.
Or you could define a ClickSensor that feeds a boolean signal into the TimeSensor that ...
It workes really nice.
An EE says this is garbage (Score:2)
I'm a hardware/software engineer (i.e. I do both). By analogy to logic design (ASIC's, FPGA's), this is a big step backwards. Once upon a time logic was designed using schematics. Everybody gave that up about 20 years ago, and switched to HDL's (VHDL, Verilog). For those unfamiliar with them, HDL's are text based hardware description languages which get compiled and then synthesized into gates, flip-flops, etc.
Despite this change 20 years ago, there are those who cling to a love of schematics. You can draw
Re: (Score:2)
You can also transform the HDL to a schematic for the times you *want* to see a schematic.
Usually that's done only for small blocks to see what the synthesizer hath wrought, and whether you can tweak the HDL for more optimal synthesis. Reading the resultant automatically generated schematics is an exercise in deciphering a puzzle. Usually easier than reading the equivalent structural HDL, but not by much.
Flow-Based Programming has *both* a visual and textual representation.
As does the example I mentioned (schematic is only required at the top level). For anything non-trivial, it isn't worth it. If flow based programming is easier, it's probably only for a small cl
I'll believe it when I see it (Score:2)
Here's the problem (Score:2)
Look, money is made by companies like Facebook which is why they have the natural language parsing graph engine (waves hands) which should be used for what the OP is talking about but instead is used to stalk each others' friends' drunk photos.
If you are talking about "real programming" that is another ball of wax, but if you are talking about 98% of web apps, android apps, etc. there is already a full corpus and standard way of representing whatever is to be done. There only so many patterns.
These patterns
More power to the people! (Score:2)
My users will love this. They are getting bored with overly-complex parametric CAD models, driven by somebody's undocumented Excel macro, reaching into the Access-database-from-hell, that pulls the wrong tables from SQL Server and our "who-changed-this-field?" ERP system, fed from a LabView rats-nest-of-code system.
Should be fun when they call me, because "computers are YOUR job, not ours".
Re:Isn't this just... programming? (Score:4, Interesting)
When you look at a C or Java program, when you're looking through the source code, the main thing that is presented to your eyes is the actual algorithm, the code that is doing the work. Sometimes you have to do a lot of effort to even figure out where a program starts. A good class diagram can capture a lot of that, but usually there is still a lot missing in class diagrams. So you might say those languages are algorithm based or something.
With flow based programming, when you look at a program, the first thing, and most obvious thing you see is the connections between modules; the way control and data are passed around the system is obvious. But you have to do extra work if you want to look inside the 'black box' modules that are actually doing the work.
With apologies to Dijkstra, one might say that Flow Based programming is an exceptionally bad idea which could have only originated at IBM (in my mind the division of labor between those who are making the 'black boxes' and those who are connecting them together is extremely difficult to get right), but the idea of making the connections between modules more obvious is definitely a good one. I hate looking at new codebases sometimes for exactly the reason that it's hard to see how the modules are put together.
Re: (Score:3)
Re: (Score:2)
With apologies to Dijkstra, one might say that Flow Based programming is an exceptionally bad idea which could have only originated at IBM
Hahaha. :-) If you've read EWD-37 you know that you never have to apologize to Dijkstra for lambasting IBM. ;-)
This isn't new... (Score:2)
This isn't new. Back in the early 90s, there were various end user tools to design simple systems that used a card metaphor. Basically, you strung a bunch of cards together to build your program and for each card you told it what that card did (accepted input, made a decision, generated a report, etc.). In reality, it was building a flow chart (but not using the traditional systems). When it was all done, you hit the button and your program ran. If it needed changed, you edited the individual card or inse
Re: (Score:2)
Which, on topic, is often significantly based on FBP. The “UNIX way” for command-line programs is essentially FBP.
Re: (Score:2)
Re: (Score:2)
True story.
Re: (Score:2)
Re: (Score:3)
My last labview program had lots of lines going underneath other ones which really defeated the entire purpose of such a simple rep
Re: (Score:2)
Does Betteridge's Law Apply more 90% of the time? (Score:2)
Q.E.D.
Re: (Score:2)
AFAIK PLC's run pretty simple programs, or at least very special purpose. I don't mean that pejoratively, just that your concerns when setting up PLC's are rather different than traditional software. I'd think they'd have to be to be describable using ladder logic (they were using it as recently as 10 years ago? Wow. Wasn't it designed for relays?)
Bottom line: would that approach extend well to other types of programming? I'm skeptical.
Re: (Score:2)
"Functions without side effects"...funny that they don't mention Haskell. Haskell is the *only* pure language (meaning without side effects) out there today with significant adoption.
You can have functions without side effects in other languages. Best if the language allows you to enforce that with a "pure" qualifier, which several do (I actually think the default is backward, and you should have to qualify any function that isn't pure). A language can have mutable local variables, and still have pure functions.
I love Haskell - it's fun to learn and a great way to learn functional programming, because it forces you to do everything functionally. The ADT's should be a must have for any l