Data Flow languages and programming - Part I
in [Theory]
|
Prev: simple: P versus NP
Next: 19990823: General announcements. Goedel's question: if a theorem has a proof of length at most n, can we find it in time O(n^2)? Another question on what can be computed in limited time and space.
From: Richard Harter on 30 Oct 2009 01:14 On Tue, 27 Oct 2009 09:55:22 +0100, "Dmitry A. Kazakov" <mailbox(a)dmitry-kazakov.de> wrote: >On Mon, 26 Oct 2009 22:22:14 GMT, Richard Harter wrote: > >> Some significant disadvantages: [snip] >* Low abstraction level, basically lacking any abstraction. Data flow works >with primitive built-in atomic types forced into value semantics. > >* Already mentioned inefficiency because of value semantics (i.e. either >permanent marshaling inputs, or else blocking the producers or the >consumers when data are shared) Normally it is the programmer to choose how >to protect states. With the dataflow it must be the engine to decide. >Basically it is lack of abstraction again. Working with *data* instead of >*states*, that summaries it. > >* The networks of wired blocks cannot be encapsulated into reusable opaque >primitives. You can group blocks, that's it. Usual methods of decomposition >do not work, because there is a firewall between "block" and "data". You >cannot merge them (like in OO) into a reusable entity (type = values + >behavior). > >* Unmaintainable code. Look at large data flow programs (e.g. in DiaDem, >Simulink, LabView). It is impossible to use reasonable software processes >on them. How to compare two diagrams? When are they semantically >equivalent? How do I validate a diagram? How to search for anything in a >diagram? Another example of this problem is represented by GUI libraries, >which are mostly event controlled. Practically none of them can be easily >used in multitasking environment. It is a horror to debug hangups or >generators in messages routed from one messages loop to another. And the >proposal is to build *everything* this way. Shudder. > >* Semantic problems, the barriers of a block that fire the computation of >the block's output is a very primitive model that does not scale in >reality. It almost instantly goes into a mess of deadlocking vs. race >condition choices. And see above, it practicably cannot be debugged except >for trivial cases (without feedbacks, with all inputs synchronous etc) it >cannot be decomposed into simpler tasks... I will accept some blame for the above farrago. I did point out there is a wide variety of data flow languages and gave examples. It didn't occur to me that anyone would actually confuse data flow programming and graphical programming. No doubt I should have. That said, it seems clear to me that if one is thinking in terms of using data flow languages for high level concurrency one is talking about languages like Erlang, Axum, and Hermes. Richard Harter, cri(a)tiac.net http://home.tiac.net/~cri, http://www.varinoma.com Kafka wasn't an author; Kafka was a prophet!
From: Mok-Kong Shen on 30 Oct 2009 05:10 Ray wrote: > robertwessel2(a)yahoo.com wrote: > >> Also, this sort of parallel/independent development has been >> demonstrated to *not* be as independent as one would like. While many >> of the low level details of the independent implementations do show >> fairly little correlation, several studies (including one by NASA, >> IIRC) have found that there is a significant tendency for independent >> development groups to make similar errors interpreting specifications >> and making similar higher level implementation decisions. > > That seems to me to be likely the fault of those who wrote the > specification rather than those who were interpreting it. > Seriously, if people are reaching the *same* misinterpretation, > the flaw is in the document they're reading. To have correct and good specifications is indeed of paramount importance for the success of software projects. Long time ago, I was told by someone that there are systems that somehow tightly control and assist the designer in software development throughout the process of specifiction, code generation and documentation in the field of real-time embedded software. I never know how general it was, i.e. whether it was well applicable outside of the said special domain. (I just searched for it on the internet and found that the producer had been acquired by IBM. See an Wiki article http://en.wikipedia.org/wiki/I-Logix.) Could someone who have substantially worked with systems of such kind let us share his good or bad experiences with them? M. K. Shen
From: Nick Keighley on 30 Oct 2009 06:32 On 29 Oct, 18:15, "Dmitry A. Kazakov" <mail...(a)dmitry-kazakov.de> wrote: > On Thu, 29 Oct 2009 05:10:37 -0700 (PDT), Nick Keighley wrote: > > On 27 Oct, 08:55, "Dmitry A. Kazakov" <mail...(a)dmitry-kazakov.de> > > wrote: > >> * Unmaintainable code. Look at large data flow programs (e.g. in DiaDem, > >> Simulink, LabView). It is impossible to use reasonable software processes > >> on them. How to compare two diagrams? > > > convert it to a textual represention then run diff on it. I'm not > > saying it's trivial but I don't think its intractable either. > > Are pixel positions and sizes of the blocks relevant to the comparison? > (:-)) I presume the smiley means you can answer that yourself... > The very argument that a text form is somewhat better raises a suspicion > why not to use it from the start? where did I say better? They have different strengths and weaknesses. Programmers I know spend a fair amount of time drawing strange diagrams on whiteboards. Personnally, I think they should then throw the diagrams away and code it up but a lot of people like diagrams. You can have both. Rational Rose has the pretty pictures but underneath there's a textual language. The tools of the 80s did similar tricks. Rational Rose even separates the logical [(link box-a box-b arrow-c)] from the representiational [(box box-a 200 300 "snow- white" "cosmic-black")] > >> When are they semantically equivalent? > > > when they are the same. > > Yes two programs are equivalent when they are... yes, but I fail to see why the graphical form presents any different problems from the textual form. > > Code gives you exactly the same problem. > > Sure, but for a programmer it is easier to decide when he deals with text. > "Find 10 differences" is a game known for pictures, no for texts. that is true. I don't play find the differences with text either I use diff (or, better a graphical version). It would be nice if there were a graphical differences tool- that is one that would didplay the picture and highlight the differnces. Not undoable I'm sure. > (I am not an expert in psychology, but it seems that abstract visual > information cannot be digested at a finely detailed level. Maybe it is a > fundamental problem. Maybe not. But so far text works at best. not for roughly half the population of programmers. I can get more of a program on a diagram. > Look at the > younger generation, who read virtually nothing. They only watch. They have > got completely new gadgets (like mobile phones), my generation didn't have. > I.e. it was a fresh start. And what we see? SMS - naked texts reborn!) I played arounf with Macs when they didn't have any CLI. It was ...interesting... > >> How do I validate a diagram? > > > there were tools that could do this in the 80s > > There was no LabView that time, and there is no such tools now... (:-)) > AFAIK, engineers designing models in Simulink, LabView etc, validate the > generated code. They do not the diagrams. Cadre Teamwork could check that flows into and out of a data transform (is that the right word for a bubble) matched. It could validate the "syntax" of c-specs (state machines diagrams). Admittedly the p-specs (code) couldn't be validated. > >> How to search for anything in a diagram? > > > solved in the 80s it's because the diagram wasn't a bunch of pixels it was a logical structure. I started to write a DFD editor for fun (fun?!) perhaps I should dig it out again. > Ah, that is maybe because there were only alphanumeric display device back > then? (:-)) blinking lights and switches. If you can't read the machine code in binary you aren't a Real programmer. Octal is for quiche eaters. -- "The Dinosaurs have come and gone, we Theriodonts remain"
From: Pascal J. Bourguignon on 30 Oct 2009 07:19 Nick Keighley <nick_keighley_nospam(a)hotmail.com> writes: > It would be nice if there were > a graphical differences tool- that is one that would didplay the > picture and highlight the differnces. Not undoable I'm sure. Indeed. Have a look at: http://www.informatimago.com/develop/pic-merge-diff3/index.html A trivial patch to this script would highlight the differences. (Unfortunately, it's only a pixel diff/merge operation, we would have to use more sophisticated algorithms to detect in a concise form block transformations; but even in this case, this gimp script is rather effective, visually). -- __Pascal Bourguignon__
From: Dmitry A. Kazakov on 30 Oct 2009 11:21
On Fri, 30 Oct 2009 03:32:30 -0700 (PDT), Nick Keighley wrote: > On 29 Oct, 18:15, "Dmitry A. Kazakov" <mail...(a)dmitry-kazakov.de> > wrote: >> On Thu, 29 Oct 2009 05:10:37 -0700 (PDT), Nick Keighley wrote: >>> On 27 Oct, 08:55, "Dmitry A. Kazakov" <mail...(a)dmitry-kazakov.de> >>> wrote: > >>>> * Unmaintainable code. Look at large data flow programs (e.g. in DiaDem, >>>> Simulink, LabView). It is impossible to use reasonable software processes >>>> on them. How to compare two diagrams? >> >>> convert it to a textual represention then run diff on it. I'm not >>> saying it's trivial but I don't think its intractable either. >> >> Are pixel positions and sizes of the blocks relevant to the comparison? >> (:-)) > > I presume the smiley means you can answer that yourself... No, equivalence of two directed graphs is not a simple task. >> The very argument that a text form is somewhat better raises a suspicion >> why not to use it from the start? > > where did I say better? They have different strengths and weaknesses. > Programmers I know spend a fair amount of time drawing strange > diagrams on whiteboards. Personnally, I think they should then throw > the diagrams away and code it up but a lot of people like diagrams. > You can have both. Yes, physicists draw lots of diagrams too. Nevertheless the language of physics is differential equations. The role of diagrams is always supplementary, they cannot serve as a language. > yes, but I fail to see why the graphical form presents any different > problems from the textual form. It is easier to analyse textual form for both humans and computers. >> Ah, that is maybe because there were only alphanumeric display device back >> then? (:-)) > > blinking lights and switches. If you can't read the machine code in > binary you aren't a Real programmer. Octal is for quiche eaters. Yep, that was fun. You could immediately see if the program ran in a cycle, the pattern repeated itself. Blue screen, that's not suckers! Real men read the program counter of the crash location looking at the front panel LEDs! (:-)) -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de |