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.

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.

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

I think that most of the problems inherent in any large-scale

On Oct 28, 10:54 am, c... at (no spam) tiac.net (Richard Harter) wrote:

However his
subsequent paragraph had no significant connection to his
observation.

Perhaps the connection was only clear to me.

WHAT ARE DATA FLOW LANGUAGES?

Some significant advantages:

* Concurrency and parallelism are natural.  Code can be
distributed between cores and even across networks.  Many of the
problems associated with threads disappear.

Some significant disadvantages:

* The mindset of data flow programming is unfamiliar to most
professional programmers.  Most dataflow programming languages
are niche languages used by non-professional programer users.

On Oct 28, 10:54 am, c... at (no spam) tiac.net (Richard Harter) wrote:
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.
snip
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.

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.  

I made an analogy and never called it an argument.

It wasn't.  He did go on to question whether a
hierarchy of programming languages had value.  

I went on to say

that we do the same thing with programming
langauges.  

For instance, in C, I will write simple functions to build
libraries.

 I will use libraries to build filter programs.  I will
pipe filter programs in a chain to accomplish complicated tasks.

 This
is a metaphor that works pretty well.  

A lot of computer science seems to me to be largely mythology.  
What I mean by that is (for instance)
the notion that OO programming will allow less expensive complicated
systems.  It is possible to write complicated systems in OO languages
for a reasonable cost.  But empirical studies have shown that the cost
is not lower than writing the same systems in a simple language like C
[1].  So now people are trying other paradigms like Aspect Oriented
programming.  I am not saying that alternative paradigms are bad.  In
fact, I program almost exclusively in C++ and love the OO metaphor.  I
am just saying that a change in paradigm doesn't usually change much.
For instance, in C++, by creating objects we do NOT reduce
complexity.  We only hide it.

* 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.

Joshua Cranmer <Pidgeo... at (no spam) 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.

If someone has some ideas about a programming language/paradigm that is
fault-resistant, not only in the sense that it reduces the number of
actual bugs and/or errors produced, but also in the sense that many bugs
have no significant effect on function and behaviour then large-scale
projects may be a lot easier to manage.

Whether this will ever be a possibility remains, in my opinion, unknown
to date.

I think that most of the problems inherent in any large-scale
programming project result from the inherent 'fragility' of all
programming languages.

If you compare a large computing project with a large engineering
project

there are clear similarities, but one very significant
difference is that almost any undetected error in code has the potential
to result, somewhere down the line, in catastrophic outcomes; whereas if
a nail is not quite hammered in as far as specified or if a light
fitting (or even a window) is put in the wrong place then the building
usually remains safe, functional, and fit for purpose.

I think that most of the problems inherent in any large-scale
programming project result from the inherent 'fragility' of all
programming languages.

If you compare a large computing project with a large engineering
project there are clear similarities, but one very significant
difference is that almost any undetected error in code has the potential
to result, somewhere down the line, in catastrophic outcomes; whereas if
a nail is not quite hammered in as far as specified or if a light
fitting (or even a window) is put in the wrong place then the building
usually remains safe, functional, and fit for purpose.

If someone has some ideas about a programming language/paradigm that is
fault-resistant, not only in the sense that it reduces the number of
actual bugs and/or errors produced, but also in the sense that many bugs
have no significant effect on function and behaviour then large-scale
projects may be a lot easier to manage.

Whether this will ever be a possibility remains, in my opinion, unknown
to date.

In engineering works there are "factors of safety" to take account
of variability of materials, unpredictability of actual loadings
and inaccuracies in construction etc. etc. In computing, analogous
has been done. For results for control of critical (including
in particular potentially dangerous) processes, one employs
double or triple hardware to take care of the possibility of
malfunction of hardware. As far as I know, in order to better
detect programmer errors, one similarly employs different and
independent teams of programmers to do the same job and then with
test cases to compare the results of the resulting programs.
However, if I don't err, this comparision is only done in the design
phase of the software and later only the work of one of the teams
is selected for practical application. A safer way, I think, would
have these presumably equivalent software (resulting from different
teams, employing preferably different programming languages and
environments) in actual production runs to always work parallelly
on multiple hardware (of possibly different types), so as to futher
reduce the risk of errors, since testing of software in the design
phase might not be thorough enough to uncover all errors that may be
present. Of course, errors could not be "absolutely" eradicated,
in accordance with Murphy's Law.

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.

On 27 Oct, 08:55, "Dmitry A. Kazakov" <mail... at (no spam) 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 the run diff on it. I'm not
saying it's trivial but I don't think its intractable either.

When are they semantically equivalent?

when they are the same.

Code gives you exactly the same problem.

How do I validate a diagram?

there were tools that could do this in the 80s

How to search for anything in a diagram?

solved in the 80s

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?


Now, I admit that if our tiny building blocks are poorly made, the
bigger building blocks become more and more fragile.
But that is true no matter which programming language we use to build
the smallest blocks. And it is always a tragic mistake to try to make
one big giant block that does it all (Forth metaphor is not an
exception because the mega word comes from its babies).

I also don't think it matters which direction we build the turtles, as
long as they make it from top to bottom.