Tim Little <t... at (no spam) little-possums.net> writes:
On 2009-10-28, Pascal J. Bourguignon <p... at (no spam) 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.

Tim Little wrote:

[snip]
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.

Yet we keep building bigger systems than we can do comfortably,
because we want them to do more. The new Boeing 787 is reported to
have 6.5 million lines of code in the various aircraft systems (not
counting things like the passenger entertainment systems). And I can
assure you that Boeing doesn't have any desire to take on a software
project that big, but rather it's what they needed to do to accomplish
their goals of building a next generation airliner ('course they're
still working on that).
[snip]
Good specifications are basically of similar difficulty to write as
the actual code. This is the downfall of many formal methods - a
specification complete enough that allows an automated checker of some
sort to verify that the software implements the specification is
basically as hard to write as the software. And as hard to verify
that it's correct.

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.

On Wed, 28 Oct 2009 17:29:04 +0100, "Dmitry A. Kazakov"





mail... at (no spam) 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
dcor... at (no spam) connx.com> wrote:

On Oct 26, 3:22=A0pm, c... at (no spam) 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]

robertwessel2 at (no spam) yahoo.com wrote:
[snip]
Yet we keep building bigger systems than we can do comfortably,
because we want them to do more. The new Boeing 787 is reported to
have 6.5 million lines of code in the various aircraft systems (not
counting things like the passenger entertainment systems). And I can
assure you that Boeing doesn't have any desire to take on a software
project that big, but rather it's what they needed to do to accomplish
their goals of building a next generation airliner ('course they're
still working on that).
[snip]
Good specifications are basically of similar difficulty to write as
the actual code. This is the downfall of many formal methods - a
specification complete enough that allows an automated checker of some
sort to verify that the software implements the specification is
basically as hard to write as the software. And as hard to verify
that it's correct.

Verification seems to be an inherently unachievable goal. If one
uses a software to do verification, that software itself evidently
has to be verified.

So I personally wonder how absolute correctness
could be achieved in practice at all. Anyway, a recent news said that
some 7000 lines of code of the kernel of an operating system has been
verified with a sophisticated verification system plus some 6 man years.

M. K. Shen

Pascal J. Bourguignon wrote:
Tim Little wrote:

[snip]
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.

I barely know anything in this direction. But isn't it that UML
is supposed to be able to do stepwise refinement of design up
to the point of transition to executable codes? I saw long time
ago also a leaflet advertising a different commercial system
that claims to include even the code generation step.

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.

On Oct 26, 3:22=A0pm, c... at (no spam) 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?

On Mon, 26 Oct 2009 17:04:36 -0700 (PDT), user923005
dcorbit at (no spam) connx.com> wrote:

On Oct 26, 3:22=A0pm, c... at (no spam) 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.

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.

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.

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.

On Wed, 28 Oct 2009 16:08:06 GMT, Richard Harter wrote:

On Mon, 26 Oct 2009 17:04:36 -0700 (PDT), user923005
dcorbit at (no spam) connx.com> wrote:

On Oct 26, 3:22=A0pm, c... at (no spam) 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.

On 27 Oct, 00:04, user923005 <dcor... at (no spam) connx.com> wrote:
On Oct 26, 3:22 pm, c... at (no spam) 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.