Re: ARIANE-5 Failure (DC-X works)

[zink@panix.com (David Zink)]

In article <dewar.834643137@schonberg> dewar@cs.nyu.edu (Robert Dewar) writes:
>Samuel said
>
>"Your definition misses a subtle distinction.  I can't define it
>formally.  I think most of us view programmers as people who tell a
>system HOW to do something.  The MatrixX user identifies WHAT to
>compute, but not HOW."
>
>The reason you cannot define this discinction formally is that it is
>a meaningless one. That was the whole point of Lambert's point about
>VHLANOS. One person's program is another persons abstract specification.

I agree that only micro-code or assembly language programmers tell the
machine HOW to compute instead of just WHAT.  However I have been
wrestling with the question of how to distinguish between Pascal
Programmers and Data-Entry operators.

You see, the Data-Entry operator enters a bunch of symbols (programs
the database) so that it will print out a specific set of values
(behave in a certain way).  I compare them to Pascal programmers
because of your phrase 'executable specification'.  Pascal compilers
produce not executable code but data (P-code) which the pascal
database engine massages to generate the reports I've requested.

I next thought, "Ah, but the Pascal Programmers manipulates the data
he enters in order to produce more desirable output."  Having worked
in the financial industry for some time, I quickly remembered that this
was no different than Data-Entry.  However it does qualify the Pascal
Data-Entry crew as 'engineers', so if we label them 'Software
Engineers' instead of programmers, at least we have believable
nomenclature.

But it still leaves me wondering what a 'Programmer' is.  Obviously
those mathematicians using Matrix-X are not, as anyone can see (formal
distinctions being a bit of a joke when they cannot distinguish things
people can easily distinguish).

Your points about whether the code is delivered in ADA seem equally
meaningless.  Either ADA is a language in which a team of fools cannot
create a dysfunctional program, or it is not.  It hardly matters to
me or any thinking person whether the team of fools is biological or
cybernetic.

The only value to programming in ADA or any other high-level language
is that it allows competent programmers to significantly reduce their
accidental error rate.  Its value is not that it forces a wise choice
of algorithms, or that it forces the program specification to bear a
meaningful relation to the actual problem to be solved, though it
=can= help the program specification bear a meaningful relationship to
the program behavior.  These last issues are the proper domain of
programmers.  The first is the proper domain of tools.

If the mathematicians entered equations into a database and the
runtime code retrieved those equations and evaluated them using
validated ADA code/methods, would they be programmers or (as I
suspect) data-entry operators?  If, the (equation) data being constant
for individual runs of the program, the data was extracted from the
database and transformed into executable/compilable code, does that
transform the mathematicians into programmers?

In which case I've transformed an awful lot of data-entry operators
into programmers over the years.  I should tell them they're
underpaid.

Perhaps you see why I'm confused.

				--David

PS (a few passing thoughts):

If I were accepting machine generated code for a project of mine, I
would want awfully iron-clad proof that the code-generator's output
implemented the input.

Until we eliminate documentation and specification altogether, until
the program *is* its documentation and specification, I doubt that
we'll have reliable programs.

The main advantage of assembly language programming is that it kept
incompetent programmers from ever completing a project.  Unfortunately
the cost was that even competent programmers were hard put to avoid
subtle errors.

What I'd like is a language with no subtle errors.