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 28 Oct 2009 13:54 On Wed, 28 Oct 2009 17:29:04 +0100, "Dmitry A. Kazakov" <mailbox(a)dmitry-kazakov.de> wrote: >On Wed, 28 Oct 2009 16:08:06 GMT, Richard Harter wrote: > >> On Mon, 26 Oct 2009 17:04:36 -0700 (PDT), user923005 >> <dcorbit(a)connx.com> wrote: >> >>>On Oct 26, 3:22=A0pm, c...(a)tiac.net (Richard Harter) wrote: >>>> SHOULD IT BE TURTLES ALL THE WAY UP? >>>> >>>> In the famous anecdote, the little old lady replies to the noted >>>> philosopher, "It's turtles all the way down." =A0When it comes to >>>> writing software many writers on software design and many >>>> programming language creators seem to believe that it is turtles >>>> all the way up. >>>> >>>> What do I mean by "turtles all the way up"? =A0By 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. =A0In other words if we use language X for 100 line >>>> programs and 1000 line programs we can also use it for 1000000 >>>> line programs. =A0We 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. >>> >>>I've never seen a convincing argument to show that this is wrong. >>> >>>We can use a 26 letter alphabet to make little words. >>>We can use a 26 letter alphabet to make bigger words. >>>We can use a 26 letter alphabet to make little paragraphs. >>>We can use a 26 letter alphabet to make bigger paragraphs. >>>We can use a 26 letter alphabet to make little books. >>>We can use a 26 letter alphabet to make bigger books. >>>We can use a 26 letter alphabet to make entire libraries. >> >>>Why isn't the same thing true of programming languages? >> >> It is. We can use 1's and 0's to build software. > >Yes, but that is the machine language. When communicating ideas about >software to other people we are using natural languages. > >> Similarly human brains are made out of atoms. > >So is the ink used to print books. This is an invalid comparison. Atoms is >the "language" of the Universe, considering the latter as a machine. Human >brain does not operate atoms, its language is different. True enough, which was the point. > >> Nothing wrong with the argument except that it is not relevant. >> As the Jedi Master said, These are not the turtles you want. > >The argument is that it is not clear what a hierarchy of programming >languages adds. You are missing the point. He made an observation and called it an argument. It wasn't. He did go on to question whether a hierarchy of programming languages had value. However his subsequent paragraph had no significant connection to his observation. [snip rhetoric] 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: Richard Harter on 28 Oct 2009 14:01 On Tue, 27 Oct 2009 10:54:34 -0700 (PDT), gremnebulin <peterdjones(a)yahoo.com> wrote: >On 27 Oct, 00:04, user923005 <dcor...(a)connx.com> wrote: >> On Oct 26, 3:22 pm, c...(a)tiac.net (Richard Harter) wrote: >> >> >> >> > SHOULD IT BE TURTLES ALL THE WAY UP? >> >> > In the famous anecdote, the little old lady replies to the noted >> > philosopher, "It's turtles all the way down." When it comes to >> > writing software many writers on software design and many >> > programming language creators seem to believe that it is turtles >> > all the way up. >> >> > 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. >> >> I've never seen a convincing argument to show that this is wrong. >> >> We can use a 26 letter alphabet to make little words. >> We can use a 26 letter alphabet to make bigger words. >> We can use a 26 letter alphabet to make little paragraphs. >> We can use a 26 letter alphabet to make bigger paragraphs. >> We can use a 26 letter alphabet to make little books. >> We can use a 26 letter alphabet to make bigger books. >> We can use a 26 letter alphabet to make entire libraries. >> >> Why isn't the same thing true of programming languages? > >what do you make libraries into? > >At each stage in your >list some extra organising structure is introduced. A library >has shelves and indexes, it is not a single gigantic book or trillion- >word sentence. > >So the answer to "why not" is "we have reached the highest organising- >pricniple >allowed by the language, and we still have more to organise". (what do >you make libraries into? ) > >Currently we are struggling to cope with applications spread accross >multiple nodes and processores, a situation which was not forseen >in most traditonal HLLs. Just so. I should have pointed that out in the original. We get more speed and power by distributing processing. The price is that we have to deal with distributed programming. A useful paper in context is "The Problem with Threads" by Edward A. Lee. The URL is http://www.eecs.berkeley.edu/Pubs/TechRpts/2006/EECS-2006-1.pdf 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: Ray on 28 Oct 2009 14:16 Pascal J. Bourguignon wrote: > Why should you care about the detail of the micro-instructions of your > MC6800? Cannot you write a specification for a microprocessor in two > lines? Let the system care about the details itself. Problem: you have a few thousand binaries written for this CPU that nobody produces anymore; you need to write software that runs them in emulation. No "two-line specification" is going to contain enough information to allow you to write software that will emulate that CPU sufficiently well that all these programs work. Likewise, if your aim is to produce a C compiler, you will need *ALL* of the specification of the C language as part of your specification. Likewise, if you need a stress analysis of the Eiffel Tower, you will need a complete schematic of the tower - its parts, their exact dimensions, and the way they fit together. Specifications simpler than the problems they intend to solve exist, certainly; but they incorporate, implicitly or explicitly, additional information whose retrieval and interpretation I know of no way to automate. If your boss (or the salesguy) hands you a specification that you must provide a program that does foo, he is relying on you the human to know (or be able to find out) what foo is and how foo is done. And that information, even though he didn't provide it, is part of the specification of the problem. Bear
From: Pascal J. Bourguignon on 28 Oct 2009 14:46 Ray <bear(a)sonic.net> writes: > Pascal J. Bourguignon wrote: > >> Why should you care about the detail of the micro-instructions of your >> MC6800? Cannot you write a specification for a microprocessor in two >> lines? Let the system care about the details itself. > > Problem: you have a few thousand binaries written for this > CPU that nobody produces anymore; you need to write software > that runs them in emulation. > > No "two-line specification" is going to contain enough > information to allow you to write software that will emulate > that CPU sufficiently well that all these programs work. > > Likewise, if your aim is to produce a C compiler, you will > need *ALL* of the specification of the C language as part > of your specification. Instead, you could use Scheme. R5RS, the specifications of scheme is only 50 pages, and this includes a formal specification! The point is that there is a lot of artificial complexity that has no fundamental, or existential reason to be. We can live without a 200,000-book tax code. > Likewise, if you need a stress analysis of the Eiffel Tower, > you will need a complete schematic of the tower - its parts, > their exact dimensions, and the way they fit together. I wouldn't take the Eiffel Tower as an example of a complex structure: it was designed "by hand", on paper, and without automatic computers. > Specifications simpler than the problems they intend to > solve exist, certainly; but they incorporate, implicitly > or explicitly, additional information whose retrieval and > interpretation I know of no way to automate. If your > boss (or the salesguy) hands you a specification that > you must provide a program that does foo, he is relying > on you the human to know (or be able to find out) what > foo is and how foo is done. And that information, even > though he didn't provide it, is part of the specification > of the problem. Indeed. The question is what part of the system must take responsibility for the details of foo. In the case of assembly language instructions, we leave that up to the compiler. With higher level tools, why couldn't we leave it up to the adequat level system part, to find out about the details of foo, and how to implement them using lower level system parts? Granted, until we've automatized these levels, we need to implement them ourselves, and this is the bad situation we are in. What I say is that the solution is not in trying to improve what we're doing at a given level, it is in not doing ourselve that level job; instead, write a meta-tool, that will do our job at this level in its own way, automatically and systematically, therefore eventually in a debugged or proved way. -- __Pascal Bourguignon__
From: Joshua Cranmer on 28 Oct 2009 15:11
On 10/28/2009 02:46 PM, Pascal J. Bourguignon wrote: > I wouldn't take the Eiffel Tower as an example of a complex structure: > it was designed "by hand", on paper, and without automatic computers. You must have absolutely no experience with civil engineering, then. The designs of buildings easily run into the 100's of pages, and yes, even when they're drawn by hand. After all, you have to worry about the structural components, mechanical components, electrical, plumbing, etc. Even the structural components of a "simple" steel tower are complex, especially if it's the input to a physical modelling program. I think one of the diagrams I had dedicated 10 pages for the structural part of a building which is just a single large enclosed room with one floor. -- Beware of bugs in the above code; I have only proved it correct, not tried it. -- Donald E. Knuth |