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!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Has Flow-Based Programming's Time Arrived?

Soulskill posted 1 year,6 days | 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) | 1 year,6 days | (#45161687)

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

Re:Like libraries? (4, Insightful)

niftydude (1745144) | 1 year,6 days | (#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 | 1 year,6 days | (#45162025)

LabView

Or Verilog
Or SystemC

Here's a list [wikipedia.org] .

What fun! Graphical patch cables! (2)

dbIII (701233) | 1 year,6 days | (#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) | 1 year,6 days | (#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) | 1 year,6 days | (#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) | 1 year,6 days | (#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) | 1 year,6 days | (#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) | 1 year,6 days | (#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 | 1 year,6 days | (#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) | 1 year,6 days | (#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 | 1 year,6 days | (#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) | 1 year,6 days | (#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 | 1 year,6 days | (#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 | 1 year,6 days | (#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 | 1 year,6 days | (#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) | 1 year,6 days | (#45162083)

I was more "like bash scripts?"

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

Anonymous Coward | 1 year,6 days | (#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 | 1 year,6 days | (#45161747)

scripting, in sh.

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

TeXMaster (593524) | 1 year,6 days | (#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) | 1 year,6 days | (#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) | 1 year,6 days | (#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 | 1 year,6 days | (#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) | 1 year,6 days | (#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) | 1 year,6 days | (#45161949)

All hail 4GL

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

blippo (158203) | 1 year,6 days | (#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 | 1 year,6 days | (#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) | 1 year,6 days | (#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 | 1 year,6 days | (#45161711)

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

I use it (1)

surfdaddy (930829) | 1 year,6 days | (#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 | 1 year,6 days | (#45162215)

Does it taste the way coffee should?

Simple Answer. (0)

Anonymous Coward | 1 year,6 days | (#45161721)

No.

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

Anonymous Coward | 1 year,6 days | (#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) | 1 year,6 days | (#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 | 1 year,6 days | (#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 | 1 year,6 days | (#45161751)

See Betteridge's law.

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

Anonymous Coward | 1 year,6 days | (#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) | 1 year,6 days | (#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) | 1 year,6 days | (#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 | 1 year,6 days | (#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) | 1 year,6 days | (#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) | 1 year,6 days | (#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 | 1 year,6 days | (#45161807)

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

Re:Easier (0)

Anonymous Coward | 1 year,6 days | (#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) | 1 year,6 days | (#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 | 1 year,6 days | (#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 | 1 year,6 days | (#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 | 1 year,6 days | (#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) | 1 year,6 days | (#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) | 1 year,6 days | (#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) | 1 year,6 days | (#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 | 1 year,6 days | (#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 | 1 year,6 days | (#45161799)

so what is the point?

Java Streams (1)

HRbnjR (12398) | 1 year,6 days | (#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) | 1 year,6 days | (#45161899)

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

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

Todd Knarr (15451) | 1 year,6 days | (#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) | 1 year,6 days | (#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) | 1 year,6 days | (#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 | 1 year,6 days | (#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) | 1 year,6 days | (#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) | 1 year,6 days | (#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) | 1 year,6 days | (#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) | 1 year,6 days | (#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) | 1 year,6 days | (#45161891)

Structured programming is the new black!

re-orient (1)

l3v1 (787564) | 1 year,6 days | (#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) | 1 year,6 days | (#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 | 1 year,6 days | (#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 | 1 year,6 days | (#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 | 1 year,6 days | (#45162469)

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

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

Anonymous Coward | 1 year,6 days | (#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 | 1 year,6 days | (#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 | 1 year,6 days | (#45161883)

I still code in PET Basic.

Re:N00bs (1)

phantomfive (622387) | 1 year,6 days | (#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) | 1 year,6 days | (#45162097)

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

Mathlab (0)

Anonymous Coward | 1 year,6 days | (#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) | 1 year,6 days | (#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 | 1 year,6 days | (#45161925)

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

More importantly (1)

mybeat (1516477) | 1 year,6 days | (#45161931)

Can it flow in the cloud?

Not Data Flow Programming (1)

GumphMaster (772693) | 1 year,6 days | (#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) | 1 year,6 days | (#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 | 1 year,6 days | (#45162117)

US Eastern is GMT-05:00.

Powershell. (0)

Anonymous Coward | 1 year,6 days | (#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) | 1 year,6 days | (#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 | 1 year,6 days | (#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) | 1 year,6 days | (#45162011)

"Everything Flows"
-Cyberneticists

Re:Done. (0)

Anonymous Coward | 1 year,6 days | (#45162159)

"They all float down here"
-IT

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

paai (162289) | 1 year,6 days | (#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 | 1 year,6 days | (#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 | 1 year,6 days | (#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) | 1 year,6 days | (#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) | 1 year,6 days | (#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 | 1 year,6 days | (#45162103)

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

Not this again! (3, Informative)

beaverdownunder (1822050) | 1 year,6 days | (#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 | 1 year,6 days | (#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) | 1 year,6 days | (#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) | 1 year,6 days | (#45162223)

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

FlowVR (2)

Geizh (3401633) | 1 year,6 days | (#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 | 1 year,6 days | (#45162471)

I have |

What else do you need?

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?