Re: Further Ted Holden ranting...

Re: Further Ted Holden ranting...

[Robert I. Eachus]

    I feel I should apologize for wasting bandwidth by responding
publicly to HTE.  However, there are some issues here which seem to be
of great interest to the wider group...

In article <1078@fedfil.UUCP> news@fedfil.UUCP (news) writes:

  > I do know that the entire software development community of the
  > United States has irrevocably standardized on C and C++, and that
  > they've also basically taken one look at Ada, and said "You've got
  > to be kidding!"

     The first part of that statement is a contradiction on its face,
so I won't bother with it.  The second part is a real issue which will
not go away for years.

     About ten years ago, when I was at Honeywell, three of us went
all out to teach Ada and software engineering to a more or less random
sample of "Software Engineers" from our division.  This group, and
others like it later broke into about 70% successes, 30% failures.
The majority liked Ada, found the software engineering we taught as
part of the course to be a great help, and follow-up showed that they
were much more productive in Ada than in assembler, FORTRAN, C, or
whatever thay had been using.  The 30% could not convince the Ada
compiler to let them do what they wanted.  Most of them could not even
complete simple assignments on the order of list sorting or summing a
list of numbers.

    "Can't teach an old dog new tricks?"  No, age was not a major
factor, nor was assembler usage.  It was mostly temperament.  Some
programmers couldn't live with the restrictions that Ada imposed, and
were not willing to think about the problem, and let the compiler
worry about the bits.

     The thing that Ted Holden doesn't seem to understand, is that
this "problem" is not unique to Ada.  We had a C project which applied
software engineering discipline to developing a database with exactly
the same results, and a lot of good code from the progammers who could
live with the discipline.  I've worked on several similar PL/I
projects.  The same thing is happening today with C++.  If you want
the software engineering advantages, then you have to live with the
discipline, and some poeple can't.

     (There are also programmers who can live with the discipline, but
don't like Ada, or PL/I, or Pascal, or...  This is a very different
issue.)

     Ten years from now, those who can't work in a disciplined fashion
will be gone from the software field, but right now there is a
surplus.  (And some of those people are people I count as friends, and
haven't been able to find jobs for months or years.  A lot more show
up in the stacks of resumes we get for each available opening.
Ted--or anyone--if you know of openings for such people, I'll direct
them to you.

   > I know that such complex software items as the varied flavors of
   > UNIX, the commercial databases, the commercial wordprocessors,
   > Windows NT, etc. etc. ad infinitum are all being written in
   > C/C++.  They all work.

   Riiight!  Some versions of Unix work better than others, but that
is not a language issue.  I don't know how to quantify the languages
used for commercial databases, but I think you will find that most
"industrial strenth" database management systems are still assembler,
and of those that aren't a substantial fraction are in Ada.
Commercial wordprocessors and Windows NT do not belong in the same
paragraph with "They all work."

   > I know for sure that it is always safer to simply use something
   > which is known to work than to reinvent it.

   You think the DoD doesn't know this?  It is just that they have, of
necessity, a much higher standard of "known to work."  In many cases
this requires developing test plans that can verify that the software
will operate correctly in circumstances which cannot be tested in the
laboratory.  The military has a term for people who discover bugs in
weapons software--casualties.  You can't just send most of this stuff
to beta testers and hope they will discover the problems.

   > Aside from all of that, history is full of examples of resources
   > being used wisely and well by the winning side: the victory ship
   > and the escort carrier from WW-II are two such examples.

   If you study the history of that late unpleasantness, and I do, the
Victory ship and the escort carrier are perfect examples of just the
opposite.  The United States could, and did, count on being able to
outproduce the Axis.  This means producing lots of what you know how
to build quickly today, rather than the best equipment for the job.
Escort carriers were pre-war designs that were unsuitable for fleet
actions, but the construction details had all been worked out.

    (Incidently, I'm currently reading _Heisenberg's_War_ by Thomas
Powers.  Very good book about atomic research in Germany during the
war, and how the Allies reacted to what they knew.  I highly recommend
it.)
--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...