Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

We are sorry to see you leave - Beta is different and we value the time you took to try it out. Before you decide to go, please take a look at some value-adds for Beta and learn more about it. Thank you for reading Slashdot, and for making the site better!

Has Flow-Based Programming's Time Arrived?

Soulskill posted about a year ago | from the go-with-the-flow dept.

Programming 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.'"

Sorry! There are no comments related to the filter you selected.

Like libraries? (3, Insightful)

epyT-R (613989) | about a year ago | (#45161687)

old is new is old is new is old is...new?

Re:Like libraries? (4, Insightful)

niftydude (1745144) | about a year ago | (#45161755)

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.

Re:Like libraries? (0)

Anonymous Coward | about a year ago | (#45162025)

LabView

Or Verilog
Or SystemC

Here's a list [wikipedia.org] .

What fun! Graphical patch cables! (2)

dbIII (701233) | about a year ago | (#45162113)

I was thinking of that too. LabView looks utterly cool on some sort of brochure or in a movie scene but was a slow way to put together scripts (just like "it's a Unix system, I know this" - with the similarly cool looking but ultimately useless file viewer).

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 components into something like a script and then convert that back into a simpler system of discrete components.

Re:Like libraries? (1)

Pino Grigio (2232472) | about a year ago | (#45162123)

It sounds to me like a pipeline, with each component in the pipeline transforming the data. It's gStreamer... or that kind of thing, with a fancy front end for dragging and dropping elements into bins and connecting bins together with T's. Not exactly new.

Re:Like libraries? (3, Funny)

Joce640k (829181) | about a year ago | (#45162417)

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:Like libraries? (3, Insightful)

fuzzyfuzzyfungus (1223518) | about a year ago | (#45162499)

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:Like libraries? (4, Funny)

hobarrera (2008506) | about a year ago | (#45161777)

Old being the new new has already gotten old. Old is the new old, new is the new new.

Re:Like libraries? (2)

rich_hudds (1360617) | about a year ago | (#45161819)

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.

I realise you wouldn't write GTA using procedural programming, but for certain tasks it just makes things simpler.

Re: Like libraries? (0)

Anonymous Coward | about a year ago | (#45162069)

You are missing the point. 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. Quickly, no one knows for sure who accesses the data and in what manner. Changes to the data structure become a nightmare as one can never be sure of the impact. Contrast this to an object oriented approach where the chances of breaking other parts of the system is much lower (as long as the interface and its semantics are preserved). 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

Re:Like libraries? (2)

Jane Q. Public (1010737) | about a year ago | (#45162121)

"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 specified exactly, and conform to a standard, or the whole approach falls down. Everything must be precisely documented, and no gray areas allowed.

And you don't learn anything from black boxes. That's all they are: boxes.

Re:Like libraries? (0)

Anonymous Coward | about a year ago | (#45162201)

So what exactly is a function (like qsort) to the user if not a black box? And what exactly is a class (like array) or an object of such a class to an user if not a black box?

And ultimately, even processor instructions are black boxes. So programming in assembly language is also black box programming, since you are just chaining black boxes (processor instructions) together. Or do you really know how exactly ADD is implemented in your processor?

Re:Like libraries? (1)

Kjella (173770) | about a year ago | (#45162139)

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()
closeInvoice()

It's fine if you have a big task and is breaking it down into many managable and reusable sub-procedures but when you have many independent forms (screen objects, to avoid the OOP object) with individual life spans then it feels like trying to put a square peg into a round hole. Plus it's a simple way to "bundle" related procedures like for example if they add a new field to a "Complaint" you have to find and edit viewComplaint() and submitAndCloseComplaintAnswer() and maybe there's a bunch of others like escalateComplaint() and did you catch them all? In OOP they should all be in the Complaint class, in procedural programming you're hoping they all have sane naming so you can find them. And sanity is in short supply in most large business applications.

Re:Like libraries? (0)

Anonymous Coward | about a year ago | (#45162353)

In an object-oriented model the flow would be:

aComplaint := Complaint.get()
aComplaint.view()
aCustomer := aComplaint.getCustomer()
aCustomerHistory := aCustomer.history()
aCustomerHistory.view()
anInvoice := aCiustomerHistory.getInvoice()
aComplaint.adjudicate()

Obviously there are a few missing details but the flow-based logic is easy to follow and understand.

Re:Like libraries? (0)

Anonymous Coward | about a year ago | (#45162481)

Assuming the view() methods return the object itself:

Complaint.get().view().getCustomer().history().view().getInvoice().adjudicate()

See? We've got a flow!

Re:Like libraries? (0)

Anonymous Coward | about a year ago | (#45162151)

No, it's a renaming of "functional programming". Just instead of "mapping a function over a list" you say "applying a transformation to a stream". But it's exactly the same.

Re:Like libraries? (2)

Opportunist (166417) | about a year ago | (#45162083)

I was more "like bash scripts?"

Isn't this just... programming? (0)

Anonymous Coward | about a year ago | (#45161695)

Coming from a fairly basic understanding of programming (I'm happy pushing bits around microcontrollers, but Object Oriented design makes my brain dribble out of my ears), isn't this how programs are supposed to be written? What's the big deal?

It's just... (1)

Anonymous Coward | about a year ago | (#45161747)

scripting, in sh.

Re:It's just... (1)

TeXMaster (593524) | about a year ago | (#45161971)

Which, on topic, is often significantly based on FBP. The “UNIX way” for command-line programs is essentially FBP.

Re:Isn't this just... programming? (3, Interesting)

phantomfive (622387) | about a year ago | (#45161831)

The two main problems of software engineering are getting data and control from where it is, to where it needs to be. Flow based programming focuses on those two aspects.

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.

"easier for non-programmers to build applications" (4, Insightful)

Black Parrot (19622) | about a year ago | (#45161701)

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:"easier for non-programmers to build applicatio (0)

Anonymous Coward | about a year ago | (#45161797)

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?

Re:"easier for non-programmers to build applicatio (2)

huge (52607) | about a year ago | (#45161917)

That sounds like a Structure Query Language that was developed some years ago to allow business users to query databases. It would free programmers to focus on programming instead of running reports. Looks like it worked pretty well.

Re:"easier for non-programmers to build applicatio (1)

theshowmecanuck (703852) | about a year ago | (#45161949)

All hail 4GL

Re: "easier for non-programmers to build applicati (2)

blippo (158203) | about a year ago | (#45162217)

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:"easier for non-programmers to build applicatio (0)

Anonymous Coward | about a year ago | (#45162271)

Er, yes ... the way of thinking about the problem in dataflow programming languages is the whole point. The tools are an aside (and in fact you don't want to be writing a complex vector calculation using black boxes of add and multiply anyway).

Re:"easier for non-programmers to build applicatio (1)

JaredOfEuropa (526365) | about a year ago | (#45162347)

Actually that's a poor example; reporting is an area where this way of programming has worked well, at least in my own experience. In most places I've worked, managers knew bugger all about programming or SQL, but they understood their own data well enough to produce reports themselves in tools like BusinessObjects, even fairly complex reports. In this case, the tool is an enabler for people who already know how to think about the problem.

Engine vs. Library (0)

Anonymous Coward | about a year ago | (#45161711)

When you mix the two and don't tell the application programmer then you get Symbian.

I use it (1)

surfdaddy (930829) | about a year ago | (#45161719)

I use flow-based programming every morning, usually the first thing I do when I wake up.

Re:I use it (0)

Anonymous Coward | about a year ago | (#45162215)

Does it taste the way coffee should?

Simple Answer. (0)

Anonymous Coward | about a year ago | (#45161721)

No.

another Soulskill article....don't bother reading (1)

Anonymous Coward | about a year ago | (#45161727)

Flow as in flow chart programming. Think UML diagrams with prebuilt libraries. Known as visual programming if you're old enough to remember the hype the last time... or was that the last last time this came up? It hasn't taken off in 30 plus years... probably a reason for that.

No. (2)

Gravis Zero (934156) | about a year ago | (#45161737)

it wasn't a good idea to start with and it hasn't gotten any better since then.

There is no other kind. (0)

Anonymous Coward | about a year ago | (#45162017)

it wasn't a good idea to start with and it hasn't gotten any better since then.

Flow-based computation has always been what occurs under the hood, and it's only blind programmers who haven't realized that that's what they're actually doing, and hence they do it poorly.

Has Flow-Based Programming's Time Arrived? (1, Insightful)

Anonymous Coward | about a year ago | (#45161751)

See Betteridge's law.

Re:Has Flow-Based Programming's Time Arrived? (0)

Anonymous Coward | about a year ago | (#45162327)

See Betteridge's law.

No, Betteridge doesn't even approach a 90% hit ratio.
You can only apply it if you already know the answer.

Re:Has Flow-Based Programming's Time Arrived? (1)

bukharin (344329) | about a year ago | (#45162339)

See Betteridge's law.

No, Betteridge doesn't even approach a 90% hit ratio.
You can only apply it if you already know the answer.

I very much doubt this. Citation please.

National Instruments LabView (4, Insightful)

KarlH420 (532043) | about a year ago | (#45161765)

NI LabView has had flow based visual programming for more than a decade. The nice thing is make parallel flows to your data, and it's multi-threaded.. It makes an easy way to visualize that something is run in parallel.

Re:National Instruments LabView (0)

Anonymous Coward | about a year ago | (#45161913)

NI LabView has had flow based visual programming for more than a decade. The nice thing is make parallel flows to your data, and it's multi-threaded.. It makes an easy way to visualize that something is run in parallel.

It's just horribly implemented.

Re:National Instruments LabView (1)

Eyeballs (64172) | about a year ago | (#45162125)

Actually, LabView has been in development for 30 years (they started to build it in 1983 and released the first version in 1986).

Easier (1)

Metabolife (961249) | about a year ago | (#45161769)

I'll go against the push button responses on here and say that it definitely might be the future. As systems become complex enough that we need UML diagrams to visualize what's happening, this is like taking the UML and actually turning it into code. It gets really interesting when you're capable of making your own flows out of existing flows to simplify your task. Why can't it complement code and not replace it?

Re:Easier (0)

Anonymous Coward | about a year ago | (#45161807)

If UML is needed for users to understand how a system presents itself, it is already fucked.

Re:Easier (0)

Anonymous Coward | about a year ago | (#45162045)

Most UML diagrams are as indecipherable as the programs that are created with them. Or are you being facetious? I really hope you're being facetious. Otherwise...

Re:Easier (4, Insightful)

AuMatar (183847) | about a year ago | (#45162093)

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:Easier (0)

Anonymous Coward | about a year ago | (#45162403)

Pretty much like JSP, completely useless for anything that isn't a textbook example.

The only method I have seen work well to describe things are flowcharts. Usable both for describing machine sequences and for instructing humans.

Re: Easier (1)

Anonymous Coward | about a year ago | (#45162129)

Visual programming models have all failed. Mainly because real systems are so much more complex than any one diagram van express. Why not break down the problem and create multiple diagrams, one to solve each problem? Well there you have it, that is exactly what programmers do. Once you have identified the smaller problems it is a question of which approach is more efficient: type code into an editor or draw lines on a diagram tool. If experience is of any value the editor always wins, especially because getting the basic flow of any application to production quality code takes adding stuff like error handling, both of which are triaval in an editor but extremly annoying in a visual tool).

No (0)

Anonymous Coward | about a year ago | (#45161779)

Because it's not a novel concept, and real programmers have been doing this long before some kid thought it wasn't a thing and started calling it FBP.

Like labview? (1)

hooiberg (1789158) | about a year ago | (#45161791)

I have been tryign to programming in Labview, in which you literally string components together. If you want to want to make anything even a bit more advanced than the stuff in any tutorial, it becomes a mess. And more important: you will still need the same thought patterns to get your stuff to work. It would be just like learning to type in Japanese. Everything looks completely different, but it still does the same.

Re:Like labview? (2)

dbIII (701233) | about a year ago | (#45162145)

Done that too - and also programmed an analog machine with patch cables (the inspiration for labview IMHO). That taught me that it's a bad idea to go anywhere near the patch cables without the equivalent of a normal script in the first place. You just end up with a tangle that may be able to do done in a simpler or better way but you just cannot see how in that representation.
My last labview program had lots of lines going underneath other ones which really defeated the entire purpose of such a simple representation. If it's going to work well it has to be modular enough that it's going to look simple no matter how you represent it.

Got news for ya (0)

Sulik (1849922) | about a year ago | (#45161795)

Your fancy FBC compiler will be written in C[++], with its primary purpose being that folks who suck at programming also get to do some programming...

Re:Got news for ya (0)

Anonymous Coward | about a year ago | (#45162453)

No true Scotsman....

The compiler could be written in FBP. It sounds like you're jealous that "ordinary" people will be able to do whatever you can do, making your skillset obsolete. Sorry buddy, the future is coming.

non-programmers do not program? (0)

Anonymous Coward | about a year ago | (#45161799)

so what is the point?

Java Streams (1)

HRbnjR (12398) | about a year ago | (#45161803)

I don't know if this is the same concept as the new Streams API in Java 1.8, but if you are a Java guy, I think they are *really* cool: http://download.java.net/jdk8/docs/api/java/util/stream/Stream.html [java.net]

Re:Java Streams (1)

viperidaenz (2515578) | about a year ago | (#45161899)

That's functional programming, not flow programming...

The problem is the transformations don't exist (5, Insightful)

Todd Knarr (15451) | about a year ago | (#45161805)

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:The problem is the transformations don't exist (1)

Noughmad (1044096) | about a year ago | (#45161943)

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 modules such as NumPy and SciPy. The declarative QML/QtQuick is also very simple to extend, and is a joy to program in, although it's not used for data transformations AFAIK. Yes, there are currently still languages where you have to write code instead of dragging and dropping. However, I could see a system using a similar interface for custom modules which would be connected with a graphical interface.

Re:The problem is the transformations don't exist (2)

beaverdownunder (1822050) | about a year ago | (#45162131)

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.

Re: The problem is the transformations don't exist (0)

Anonymous Coward | about a year ago | (#45162191)

Yeah, except non programmers are notoriously bad at identifying what pieces are missing. So they will end up shouting at their devs for delivering the wrong pieces, and would they please just solve the f**ing problem?! Thatâ(TM)s when the dogma - FBP in this instance - starts to become a problem rather than a solution. Been there done that.

Behavior Engineering + Flow-based programming (2)

thatkid_2002 (1529917) | about a year ago | (#45161809)

I think where this would be interesting is using Behavior Engineering (not UML!) to debug the design (and requirements) and then have automatically generated skeleton loaded into some sort of Flow-based programming system. If you're unfamiliar with BE (it's not really taught outside Griffith University) then you can have a look at http://en.wikipedia.org/wiki/Behavior_Trees [wikipedia.org]

Not new (2)

Animats (122034) | about a year ago | (#45161851)

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:Not new (2)

dkf (304284) | about a year ago | (#45162305)

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 of that mysterious changing-behind-your-back behaviour.

SSA rules also make type analysis much easier, in turn making compilation and optimisation easier...

The 1980's called (1)

maroberts (15852) | about a year ago | (#45161869)

We can all go back to programming in C/Pascal/Fortran and forget all this OO crap now, can we?

Re:The 1980's called (1)

phantomfive (622387) | about a year ago | (#45161891)

Structured programming is the new black!

re-orient (1)

l3v1 (787564) | about a year ago | (#45161873)

"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."

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 idiots 're-orient' themselves however often they want to.

A.k.a shell scripts (4, Interesting)

iamacat (583406) | about a year ago | (#45161875)

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.

Re:A.k.a shell scripts (0)

Anonymous Coward | about a year ago | (#45161939)

I really wouldn't mind a nicer syntax, though. Can't we have pipes in a modern language?

Re: A.k.a shell scripts (0)

Anonymous Coward | about a year ago | (#45162205)

Except if results.txt.gz already existed in which case you have just created a really bad side effect.

Re: A.k.a shell scripts (0)

Anonymous Coward | about a year ago | (#45162469)

resuts.2013-10-18T1016.txt.gz

Re:A.k.a shell scripts (0)

Anonymous Coward | about a year ago | (#45162441)

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.

I implemented something similar to this for an exception reporting system to notify the security administration team by email that a staff member had left the organization and their record in the PKI system needed to be archived. The script ran weekly. A point-and-click co-worker asked why I was using a Unix command shell instead of Microsoft Notepad and then copying it to the server using PuTTY/WinSCP, why I was writing a script and most mind-boggling he asked why didn't I just use Microsoft Visual Basic or a Microsoft Excel spreadsheet. I told the co-worker to go back to his cubicle and play with their crayons.

Lame Dichotomy (0)

Anonymous Coward | about a year ago | (#45161881)

“There’s two roles: There’s the person building componentry, who has to have experience in a particular program area, and there’s the person who puts them together,” explains Morrison. “And it’s two different skills.”

Nope. There's the person who can do both, and there's the person who's only smart enough to draw lines.

N00bs (0)

Anonymous Coward | about a year ago | (#45161883)

I still code in PET Basic.

Re:N00bs (1)

phantomfive (622387) | about a year ago | (#45161909)

Heh......when I switched from C64 Basic to a more modern programming language that actually had else statements, I thought they were so lame. "Who would use those?" I asked, "Who would use them when GOTO statements work perfectly well?"

True story.

Re:N00bs (1)

clickclickdrone (964164) | about a year ago | (#45162097)

Thing is, ultimately, those GOTO's are still there, they're just hidden under a more acceptable paradigm.

Mathlab (0)

Anonymous Coward | about a year ago | (#45161901)

Does this for mathematicians. That's why I always hated working with it, I din't know most of the functions in it and I wanted control over my program.

Talend already used it successfully (2, Informative)

WetCat (558132) | about a year ago | (#45161905)

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.

"Flow-based programming"? I call it bash scripting (0)

Anonymous Coward | about a year ago | (#45161925)

We have proven implementations of "flow-based programming" floating around since the 80s.

More importantly (1)

mybeat (1516477) | about a year ago | (#45161931)

Can it flow in the cloud?

Not Data Flow Programming (1)

GumphMaster (772693) | about a year ago | (#45161951)

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.

Slashdot downtime (1)

YoungManKlaus (2773165) | about a year ago | (#45161957)

Can anyone tell me what October 18, 8 pm to Saturday October 19, 1 am (Eastern Time). is supposed to be in UTC so people might actually be able to calculate their local downtime-frame?

Re:Slashdot downtime (0)

Anonymous Coward | about a year ago | (#45162117)

US Eastern is GMT-05:00.

Powershell. (0)

Anonymous Coward | about a year ago | (#45161981)

Since I've progressed beyond 1979, instead of mentioning UNIX and pipes I'll point out that Powershell is especially powerful in this facet of a pipeline/flow.

Also, Workflow Foundation (WF).

The Code is the Model (1)

Rothron the Wise (171030) | about a year ago | (#45162003)

The code is the model. You can't make it much simpler. You can simplify the common things, but this will make the language less general, more domain specific. For programming synthesizers it makes a lot of sense.

If a function call is represented with two boxes with a line between them, the simplest of applications will be a confusing mess.

Re:The Code is the Model (0)

Anonymous Coward | about a year ago | (#45162461)

Parent is/should be +5 Insightful.

Code as we know it is far more conceptually modular and dare I say it fluid and thus also more forthright and even easier than any labyrinth of boxes.

Lego as wonderful as it is will always remain Lego, but code can be and almost always is far more than simply code: it doesn't just have syntax it has context and programmers defining and/or expanding that very context is central.

Done. (2)

VortexCortex (1117377) | about a year ago | (#45162011)

"Everything Flows"
-Cyberneticists

Re:Done. (0)

Anonymous Coward | about a year ago | (#45162159)

"They all float down here"
-IT

We already have this. It is called "Unix" (2)

paai (162289) | about a year ago | (#45162013)

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) programming needs. If and when necessary I tacked on a larger database system. Of course I tried the new (well, in the nineties they were new) OO systems, but I rapidly got lost in a jungle of libraries and methods and even more documentation. Compare that to the almost ascetic (and aesthetic) clarity of the Unix environment.

Yes, I feel that Unix still has a lot of mileage in it and intentionally or not, this item and the reactions on it, confirm me in this view

Paai

Re:We already have this. It is called "Unix" (0)

Anonymous Coward | about a year ago | (#45162301)

Except UNIX has a single flow control model for those pipelines, has difficulty forking data to two places except in very simple cases (tee), and cannot join to processes together to feed a third. In essence, UNIX has pipes, but this has graphs. But sure, it's an evolution of that basic concept, and a very powerful concept it is.

Re:We already have this. It is called "Unix" (0)

Anonymous Coward | about a year ago | (#45162325)

(That should be "two" processes, and I guess you can do that in code actually, but standard shell languages don't support it within pipeline specifications.)

This is what BPEL and executable BPMN promise (1)

Chrisq (894406) | about a year ago | (#45162061)

This is what BPEL and [wikipedia.org] executable BPMN [bpmnhandbook.com] promise. In practice for the business its "string these together and get a programmer top write a transformation or show you were to obtain a key data element that is missing from the stream" at best, or "try to string these together in an illogical way and complain to the development team that the components don't know what you mean".

Yeah, I could use that. (1)

Robert Slade (2869683) | about a year ago | (#45162085)

I have no experience with programming so I could definitely use something like this. Reminds me of an old game my son used to play.

D is for lysdexia (0)

Anonymous Coward | about a year ago | (#45162103)

Am I the only one who read "Flaw based programming"?

Not this again! (3, Informative)

beaverdownunder (1822050) | about a year ago | (#45162107)

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:Not this again! (0)

Anonymous Coward | about a year ago | (#45162375)

Lies! It's a programming model, you're talking products then complaining the products' weaknesses disprove the usefulness of the model. In fact, these kinds of system are in use and are successful in many different domains already, especially in the AV/multimedia/CGI world. Non-programmers are using such systems inside Maya, etc. every day without even caring that they're "programming". You think they need custom functions 99% of the time? That's simply not true. They need them sometimes, sure, but if the infrastructure is flow-based it's easy to provide them as middleware - flow-based programming is an awesome substrate for middleware.

Meanwhile, from a CS point of view, the power is that they really really do a good job of expressing parallelism. The fact that you have to drop out of this model to write low-level code isn't a weakness, it's a strength. You use standard 60s/70s/80s-era imperative code within a single black box, which is running in a single-threaded compartment. Then you use flow-based when you want to string those pieces together, potentially across multiple cores or even multiple machines. That's formally "Communicating Sequential Processes" (CSP).

The apparent weaknesses come from shoddy product designs, and PR claiming that no one needs to learn to program any more. That's never going to happen, but if you see past the obvious PR lies you still get the future of programming.

IMHO, of course :p

Re:Not this again! (2)

Tom (822) | about a year ago | (#45162397)

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.

Unix pipe (3, Insightful)

aralin (107264) | about a year ago | (#45162223)

So you mean like unix pipe. Where you have those wonderful transformations like sed, grep, cut, sort, etc ? Youngsters.

FlowVR (2)

Geizh (3401633) | about a year ago | (#45162277)

If you're wondering what flow-based programming feels like, I work on an open-source framework called FlowVR [sourceforge.net] .
It is advertised towards high-performance computing but suits small applications just fine.

pipe (0)

Anonymous Coward | about a year ago | (#45162471)

I have |

What else do you need?

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?