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: Pascal J. Bourguignon on 28 Oct 2009 11:44 Joshua Cranmer <Pidgeot18(a)verizon.invalid> writes: > On 10/28/2009 12:32 AM, Pascal J. Bourguignon wrote: >> 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. > > The PDF 1.6 specification was, if I recall correctly, approximately > 1400 pages of text. My draft of C++0 weighs in at a whopping 1314 > pages. The JVM spec is smaller, at only 542 pages. The full x86_64 ISA > comes in volumes; even the ancient MC6800 ISA took 40 pages or so to > explain. > > Many specifications, to approach the degree of completeness required > for independent implementation, need to drag on for hundreds or > thousands of pages. 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. -- __Pascal Bourguignon__
From: Richard Harter on 28 Oct 2009 12:08 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. Similarly human brains are made out of atoms. Nothing wrong with the argument except that it is not relevant. As the Jedi Master said, These are not the turtles you want. 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: Dmitry A. Kazakov on 28 Oct 2009 12:29 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. > 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. As we know it adds nothing to the power, rather subtracts, since many "higher level" language are not Turing-complete. One can argue that they provide a better mapping to the domain, but the domain is actually always in the brain of a human programmer. So it looks rather so that we cannot adequately communicate to humans. Even considering multi-paradigm/language approach as a kind of patchwork to cover this nakedness. It is still not convincing why the patchwork should lay patches over patches and in so many layers. It won't hold better, it won't make you warmer... -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de
From: Mok-Kong Shen on 28 Oct 2009 12:45 Pascal J. Bourguignon wrote: > Mok-Kong Shen writes: >> Verification seems to be an inherently unachievable goal. If one >> uses a software to do verification, that software itself evidently >> has to be verified. > > Happily, the verification software may be simplier than the verified > software. Therefore it should be easier to verify. Possibly by a > second order verification software that is itself even simplier to > verify. And so on, until you can have it verified it by hand by as > many human you need to reach the required degree of confidence. Sure, this is the very philosophy underlying program verifications. But how "sure" can a human ensure that everything he designs/constructs is correct? Certain industries, e.g. aerospace manufacturers, chip manufacturers etc., that critically depend on the correctness of their design software, have since long invested much resources in verification. Yet I believe Murphy's Law remains true and human errors can never be entirely eradicated but only (hopefully) reduced to tolerable levels. (Or else why disasters did occur e.g. in a few very carefully designed space missions?) M. K. Shen
From: Mok-Kong Shen on 28 Oct 2009 12:52
Pascal J. Bourguignon wrote: [snip] > What we really need is metaprogramming. The only usable > metaprogramming solution I know is Lisp and its macros. With > metaprogramming, you can implement as many steps you need to keep the > complexity in check. I don't like to enter into debates about programming languages, which tend normally to ahve a flavour akin to religious debates. For fans of C++ (I am not one of these) would very likely disagree with you. M. K. Shen |