3 ms·
Thank you for providing an example. I look at that and I see a couple of things. First, this is procedural programming straight out of my old, old COBOL books.
by RogerL 13y ago
Thank you for providing an example.
I look at that and I see a couple of things. First, this is procedural programming straight out of my old, old COBOL books. Batch processing - read some files, process the data, output it. That graph is pretty, but no different from the structured analysis and design that was forced on me in the mid 80s.
That stuff was a nightmare to work with. No real search, endless 2D layout issues, no way to reuse, a very little bit of information conveyed in a lot of space, no way to debug, and so on. And, if your program is anything but batch/data flow oriented, good luck.
I see maybe 100-300 lines of JSON in the image. Or Lua. Whatever. A modest amount of paste code to tie already written components together in in/out chains. Now, I get that your diagram is more easily 'groked' than JSON, and that is a benefit. But what if I want to search for things? Use awesome tools like sed to batch change stuff? Perform static analysis? All that graphical stuff just falls apart. Oh, perhaps there is some DOM, and I access that, but then I'm right back into the incredible power and expressiveness of text.
More importantly, I'd like to see the flow diagrams of all those nodes you are connecting together. I am prepared for egg on my face here, but are those written in NoFlo, or text? I'm guessing the latter.
So, how is this different than LabView? I completely understand the value of being able to quickly plug together pre-existing components when you have a tiny interface (you just have in/out nodes, basically, in that diagram). A small solution for a small problem, and I don't mean that dismissively.
Despite the article's claim, and as many have already said, this stuff has been around for decades. There are definitely places for it. But having lived through it, I tell you SA/SD died a very deserved death.
Sorry, this isn't directed at you, you were just the person kind enough to provide an asked for example.
The other major thing that sticks out for me is that that graph is just a high level, block diagram of the program. Well, "just" not meant to be dismissive. The original article talks about the horrors of programming where changing one thing means changing 10 other components. They are not describing programming, they are describing hacking spaghetti code with no design. If that is the way you program, or the way the code base you are working on is coded, then I can see why these flow diagrams seem so revolutionary - a design is being done, and software is broken up into discrete components. That's pretty fundamental SW engineering. But the magic is not in the 2D visual display, but in the idea of small components that do one thing and that are not intimately tied to other components. So hey, if the tool helps you learn or use that method, good, I guess. How you reasonably scale it up to anything large is beyond me (I've done entire avionics systems in data flow diagrams, and it ain't pretty at that scale, believe me).
- pekk 13y ago> this is procedural programming straight out of my old, old COBOL books. Batch processing - read some files, process the data, output it. Modularizing systems into separate, standardized units has a tendency to look like this (or like shell scripting). Is this a huge problem?
- seanmcdirmid 13y agoNot at all. The point is that the visual code doesn't differ much from the textual code in terms of architecture and complexity.
- leifaffles 13y agoI think there is some broad confusion over "flow-based programming" implying "non-programmers using a graph editor to connect things". So I'm going to ignore that completely in favor of talking about flow-based programming for programmers. Here's an example I have experience with: The GRL research language [1] is a dataflow language for behavior-based robotics. It's a real programming language that batch compiles down to C code that runs in O(1) time and space (it's not Turing complete). It escapes from the "spaghetti code" problem you mention by providing an abstraction of a procedure as a compile-time rewrite rule that transforms the dataflow graph (for Lisp hackers, every procedure is basically a macro that can be passed around by value at compile-time). (FWIW, graphical editors can actually be a useful and pleasant way to construct throwaway flow graphs, but aren't particularly useful for developing new abstractions (i.e. dataflow procedures or data types). They run into the spaghetti code problem you mention, by which the only way to reuse a chunk of functionality is copy-paste) The system has been used for things like programming actual robots, Half Life bots [2], and motor control for interactive game-like thingies [3]. What it's really great at is managing stateful information over time. Things like moving averages, low pass filters, and other types of state machines (flip-flops, "just true" constructs, etc) all become first-class values in your programming language. So how could this be used in a more flexible environment that isn't ideological about dataflow programming? While dataflow graphs may be limited in their expressiveness, we can use them to encapsulate many types of state machines, particularly those that change over time or in response to stimulus. Under this model, every self-contained flow graph becomes a thunk whose input values are determined by evaluating arbitrary expressions in the host language (and can be dynamically instantiated). For implementations of this technique, see [3]. Finally, [4] is an implementation of the stateful time-based dataflow constructs I wrote for a game in C#, which power things like motor behaviors, input processing, collision avoidance, animations, and interpolations. As a bonus, you can add events on top of these for a simple implementation of functional reactive programming. So do you want to build a web app in a dataflow language? Maybe not. Do you want flow-based constructs in your programming language? Depending on what you're building, the answer could range of "Not really" to "I can't live without them." [1] http://www.cs.northwestern.edu/~ian/grl-paper.pdf http://www.cs.northwestern.edu/~ian/grl-paper.pdf [2] http://www.cs.northwestern.edu/~gdunham/flexbot/manual/grl_for_flexbot.htm http://www.cs.northwestern.edu/~gdunham/flexbot/manual/grl_f... [3] http://www.aaai.org/ocs/index.php/AIIDE/AIIDE11/paper/view/4081 http://www.aaai.org/ocs/index.php/AIIDE/AIIDE11/paper/view/4... [4] https://bitbucket.org/leifaffles/chad/src/d6a13c2315cce41dba1b4572749bd3969c821286/ChadEngine/Signals/Library/Stateful.cs https://bitbucket.org/leifaffles/chad/src/d6a13c2315cce41dba...