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: robertwessel2 on 27 Oct 2009 19:52 On Oct 26, 5:22 pm, c...(a)tiac.net (Richard Harter) wrote: > What do I mean by "turtles all the way up"? By this I mean the > thesis that the techniques and programming language concepts that > > are used in the small can be extended indefinitely to programming > > in the large. In other words if we use language X for 100 line > programs and 1000 line programs we can also use it for 1000000 > line programs. We may have to add some extensions and new > features along the way, but we can increase the size of the > programs we write indefinitely using the same ideas. > <p> > The antithesis is that it isn't turtles all the way up, or at > least it shouldn't be turtles all the way up. That is, the kinds > > of languages and programming technologies that we use in > large scale programming should be quite different from the kind > of languages used for programming in the small. While this is perhaps true, it's completely unclear what we need to successfully manage large projects. Sure a few things do help (like strong type, memory safety, good support for interfaces), but those also help on all but the smallest projects as well. At the level of several tens of thousands of lines of code, it's all irrelevant. Basically any language and methodology, including winging it, will work. At the million line level, there simply isn't any demonstrated reliable* methodology, unless you can break up the system into many small and highly independent pieces (consider the library of tens of thousands of device drivers on some modern OSs). No magic bullets, and all that *where reliable is defined as producing something approximating a working version of the desired system in sometime approximating the planned time and budget.
From: Pascal J. Bourguignon on 27 Oct 2009 20:25 "robertwessel2(a)yahoo.com" <robertwessel2(a)yahoo.com> writes: > [...] At the million line level, there simply isn't any > demonstrated reliable* methodology, unless you can break up the system > into many small and highly independent pieces (consider the library of > tens of thousands of device drivers on some modern OSs). Well, there's one proven methodology: the compiler. That is, metaprogramming. I can write working programs of one million lines of assembler any day. Only it's not me who will write this million of assembler lines each day, it's the compiler. I will only write 10,000 lines of source code. Now if you need to write a million of source line, then just don't do it. Use metaprogramming to generate this million of source lines from a smaller source. And so on, you can add layers of metaprogramming all you need to compact your sources and always have something of manageable size. -- __Pascal Bourguignon__
From: Tim Little on 27 Oct 2009 20:57 On 2009-10-28, Pascal J. Bourguignon <pjb(a)informatimago.com> wrote: > Now if you need to write a million of source line, then just don't > do it. Use metaprogramming to generate this million of source lines > from a smaller source. And so on, you can add layers of > metaprogramming all you need to compact your sources and always have > something of manageable size. So, you're saying that *every* programming problem can be solved in at most a few tens of thousands of lines of code? Certainly some problems can, but most can't. Metaprogramming is just a form of compression, and there is no compression system that can reduce every source below a given size. Some problems really are irreducibly complex, and demand complex solutions. - Tim
From: jpwoodruff on 27 Oct 2009 21:32 On Oct 27, 3:47 am, Mok-Kong Shen <mok-kong.s...(a)t-online.de> wrote: > Richard Harter wrote: > > Some significant advantages: > > > * Concurrency and parallelism are natural. > > I guess that such a language could profitably be used to simulate > the neuronal network of the brain. Could that be right? > > M. K. Shen In one domain - evaluating large mathematical expressions - dataflow languages express their programs well. One complete step in program design - memory map design - does not occur at all. That's where the early work on Sisal was directed if I'm not mistaken. Research on these mathematical programs - and the search for execution speed - still continues. Part of the charm ascribed to "dataflow machines" was their parallelism. Parallelism was to be as inherent in the execution as in the programming. That was to be a fundamental goal of the computer hardware for these machines. I think that an associative processor to be used for matching up tokens in the (executable) dataflow graph does not exist in large-scale hardware. Instead it is simulated by the "run time" that was mentioned earlier. That's just not the same thing at all. John
From: Pascal J. Bourguignon on 28 Oct 2009 00:32
Tim Little <tim(a)little-possums.net> writes: > On 2009-10-28, Pascal J. Bourguignon <pjb(a)informatimago.com> wrote: >> Now if you need to write a million of source line, then just don't >> do it. Use metaprogramming to generate this million of source lines >> from a smaller source. And so on, you can add layers of >> metaprogramming all you need to compact your sources and always have >> something of manageable size. > > So, you're saying that *every* programming problem can be solved in at > most a few tens of thousands of lines of code? Can you not specify all programming problem in less that a few thousands of lines of specification? Well, you can always write more detailed specifications, but I can assure you that sales peoples will always be able to put the whole specifications of your software on a 2-page booklet. > Certainly some problems can, but most can't. Metaprogramming is just > a form of compression, and there is no compression system that can > reduce every source below a given size. Some problems really are > irreducibly complex, and demand complex solutions. Yes indeed. However, assuming a big ontology (eg. take wikipedia, or even the whole web), wouldn't it be possible to express the needs for any software in less than ten thousands lines, and let the sufficiently smart system develop it, filling in the blanks in the specifications with all the knowledge it can extract from the web? Or take the problem actually in the other dirrection. Would you trust any implementation of a system that has orders of magnitude more than ten thousand lines of specifications? How can you ensure these specifications are consistent? How can you ensure that they're effectively implemented? Wouldn't you be more able to understand and check the specifications if they were shorter, that is indeed, given the ultimate limits to compression, if what they specified was less complex or of a more limited scope? If you accept that big systems must be decomposed into small programs, you should probably also accept that big specifications are as bad as big program(*), and that they should be short too, to be understandable and effectively implementable. Then the degree of automatization in the process of translating the specifications into executable code is only a matter of advancement of the techniques, while the size of the executable code is only (roughly) a function of the number of metaprogramming levels used. (*) Specifications = programs, as in: high level, declarative programs. -- __Pascal Bourguignon__ |