Re: Eiffel for DoD development?

[eachus@spectre.mitre.org (Robert I. Eachus)]

     Gee I was trying to end this debate, but some people insist on
not "getting it."

In article <jws-1102940843050001@seeker.tiac.net> jws@seeker.tiac.net (Jeffrey W. Stulin) writes:

 > >      The optimal number is one.

 > Absurd. That is like saying that DOD should standardize on one type of
 > screwdriver!

   The if I turn that around, it becomes clear who is being absurd.
How many different 1" 10-32 Pan-head screws should a maintenance depot
have to stock?  Slotted and Phillips, or can they agree to just stock
the Phillips head?  Do you want them to include 23 other types of
screws just in case some mechanic doesn't like Phillips screwdrivers
and prefers Allen wrenches?

   This is the right way to look at the issue.  There may be better
ways of tightening some fasteners, but the DoD HAS to pay attention to
the cost of new tools, training, stocking issues, etc.  There has to
be a significant payoff to justify a switch.

 > A reason for the profusion of languages is wide range of potential
 > applications; No language is appropriate for all situations.

   Yawn!  Who said that such a magic language existed?  Ada was
designed to be appropriate for all DoD embedded applications, and has
proven to have a wider domain of applicability.  But the policy is
designed to allow for exceptions when they occur.

 > What DOD should be doing is a compromise: keep a short list of accepted
 > languages and let each development project choose the best language (from
 > the list) for the job.

   Ah, so you have read the policy, and realized that this is exactly
what is done?  No?  Try again then.  As I remember it, the list
started with eight languages and has shrunk as some of those languages
went away.  (TACPOL and JOVIAL J3 for example.)  But there are some
languages which never have and never will made the list.  Eiffel is
one, would you care to guess others?

   In another thread responding to this question, someone mentioned
SQL.  That is a perfect example, and if you read the policy, you will
find in the database domain, use of SQL requires no waivers, no
exceptions, no nothing.

   On the other hand, where once ATLAS (and ATLAS variants) were the
only usually the language considered for certain types of testing
software, there has been a lot of work on developing a set of Ada
packages (ABBET).  Soon I imagine that ATLAS will be dropped from the
approved list--once the needed tools are in place--since ABBET seems to
be much more maintainable.

  > Using the wrong tool for a job is worse than having to maintain a
  > new tool.

    And using the wrong tool AND having to maintain it is the worst
possible combination.  If you can't understand that many of us have
been there and had to do that, you are totally missing the point.  We
just went through this exercise recently.  To reduce maintenance
costs, we had to port a compiler written in a vendor specific variant
of one obsolete language, which compiled a different vendor specific
variant of an obsolete language, was hosted on an obsolete mainframe,
and targeted an obsolete computer architecture.

    Maintenance costs on the mainframe were such that spending over a
million dollars on the port would have been acceptable--I think the
final cost was half that.   But we still have (now) a special purpose
front end for the gcc compiler, and a special assembler, and a special
linker all to maintain for ONE project.  That way lies madness.

--

					Robert I. Eachus

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