Forgot your password?
typodupeerror
Programming

Has Flow-Based Programming's Time Arrived? 268

Posted by Soulskill
from the go-with-the-flow dept.
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.'"
This discussion has been archived. No new comments can be posted.

Has Flow-Based Programming's Time Arrived?

Comments Filter:
  • Like libraries? (Score:4, Insightful)

    by epyT-R (613989) on Friday October 18, 2013 @01:23AM (#45161687)

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

    • Re:Like libraries? (Score:5, Insightful)

      by niftydude (1745144) on Friday October 18, 2013 @01:38AM (#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.
      • 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 comp
      • 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.
        • by skids (119237)

          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.

      • by Joce640k (829181) on Friday October 18, 2013 @03:57AM (#45162417) Homepage

        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]

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

      • by Darinbob (1142669)

        Flow based? Sounds like MONIAC.
        http://en.wikipedia.org/wiki/MONIAC_Computer [wikipedia.org]

      • Re:Like libraries? (Score:4, Insightful)

        by fuzzyfuzzyfungus (1223518) on Friday October 18, 2013 @04:24AM (#45162499) Journal

        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.

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

        • 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

    • by hobarrera (2008506) on Friday October 18, 2013 @01:42AM (#45161777) Homepage

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

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

        • by ultranova (717540)

          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.

          So in other words, "black box programming" is a marketing term for using libraries.

          • by Rockoon (1252108)
            Its rare for a library not to have functions with side-effects.

            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
            • by gd2shoe (747932)

              In the object oriented world, all objects must be immutable or you cannot enforce black boxes.

              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

      • by Kjella (173770)

        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

        • 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

          • by gd2shoe (747932)

            ... as opposed to declarative languages such as SQL

            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.

    • I was more "like bash scripts?"

  • by Black Parrot (19622) on Friday October 18, 2013 @01:27AM (#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.

    • by huge (52607)
      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.
      • All hail 4GL
        • 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.

          • by Dcnjoe60 (682885)

            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.

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

      • by Dcnjoe60 (682885)

        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.

    • by Dcnjoe60 (682885)

      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

  • I use flow-based programming every morning, usually the first thing I do when I wake up.
  • by Gravis Zero (934156) on Friday October 18, 2013 @01:34AM (#45161737)

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

    • Re:No. (Score:4, Informative)

      by Rob Riggs (6418) on Friday October 18, 2013 @08:57AM (#45164073) Homepage Journal

      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.

  • by KarlH420 (532043) on Friday October 18, 2013 @01:39AM (#45161765) Homepage
    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.
    • by gtall (79522)

      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.

  • 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 (Score:5, Insightful)

      by AuMatar (183847) on Friday October 18, 2013 @02:43AM (#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).

  • 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]
  • by Todd Knarr (15451) on Friday October 18, 2013 @01:50AM (#45161805) Homepage

    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.

    • by Noughmad (1044096)

      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

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

  • by thatkid_2002 (1529917) on Friday October 18, 2013 @01:50AM (#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]
    • by hibiki_r (649814)

      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.

  • by Animats (122034) on Friday October 18, 2013 @01:57AM (#45161851) Homepage

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

    • by dkf (304284)

      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

      • by swillden (191260)

        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.

  • "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
  • A.k.a shell scripts (Score:5, Interesting)

    by iamacat (583406) on Friday October 18, 2013 @02:01AM (#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.

    • 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

    • by matria (157464)
  • by WetCat (558132) on Friday October 18, 2013 @02:09AM (#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.

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

  • by VortexCortex (1117377) <VortexCortex@Nos ... t-retrograde.com> on Friday October 18, 2013 @02:28AM (#45162011)

    "Everything Flows"
    -Cyberneticists

  • 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)

  • This sounds awfully like the Last One, a British 'language' from 1981 that used lines of code to pull together pre written blocks then produce the executable:
    http://en.wikipedia.org/wiki/The_Last_One_(software) [wikipedia.org]
  • 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".
  • Not this again! (Score:4, Informative)

    by beaverdownunder (1822050) on Friday October 18, 2013 @02:46AM (#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.

    • by Tom (822)

      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.

    • 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)

    by aralin (107264) on Friday October 18, 2013 @03:08AM (#45162223)

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

    • by swillden (191260)

      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.

  • by Geizh (3401633)
    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.
  • 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

  • functions without side effects

    Lambda calculus predates the invention of the compiler. It's always funny when programmers rediscover stuff and think they've invented something new. :P

  • 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

    • by Greyfox (87712)
      Every fad that comes along sells itself with the easy problems, though. Making programming easier for non-programmers has been the holy grail for a good 5 decades. Before that it was probably making computers easier to use for people who don't have soldering irons. "Just use our thing!" they promise, "And you'll just be able to hire chimpanzees to crap out code for you all day long for the cost of a few bananas a day!" Well just because you're using the latest fad doesn't mean you can hire chimpanzees to wr
  • by gr8_phk (621180) on Friday October 18, 2013 @07:51AM (#45163425)

    FBP claims to make it easier for non-programmers to build applications by stringing together transformations built by expert programmers.

    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.

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

  • 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

  • I've been doing Oracle SOA development for the past six months. The BPEL and XSLT transformation tools are supposedly business user friendly however I have to drop into the source code several times on every project to perform simple tasks and to make corrections to the assumptions that JDeveloper makes. Even things as simple as defining you want the value from the Nth occurrence of a repeating element have to be done in the source code. God forbid you don't want to use oracle as your namespace I have t
  • 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

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

It was kinda like stuffing the wrong card in a computer, when you're stickin' those artificial stimulants in your arm. -- Dion, noted computer scientist

Working...