* Re: Eiffel for DoD
@ 1994-10-11 14:53 Nick Sizemore
0 siblings, 0 replies; only message in thread
From: Nick Sizemore @ 1994-10-11 14:53 UTC (permalink / raw)
Subject: Re: Eiffel for DoD
Ken Garlington <73672.2025@COMPUSERVE.COM> writes:
> "Jeffrey W. Stulin" <jws@SEEKER.TIAC.NET> writes:
>> 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.
> As I (vaguely) recall, that "short list" was (pre-mandate):
>
> JOVIAL - Air Force
> CMS-2 - Army
> PL/M? - Navy
> FORTRAN
> COBOL?
>
> and maybe one of two others. This is why Ada came about in the
> first place. Of course, today we would get to add
>
> Ada
> C/C++
> Eiffel
> Lisp? (lots of AI coming up...)
> Visual Basic/C++/whatever...
>
> because there would be at least one group of software developers
> that could prove, to a metaphysical certainty, that one of these
> languages was clearly superior for their particular domain.
While I'm not an Ada expert I do recall being around (in the
Army) when the Ada initiative took shape, and I've followed its
history with some interest.
The problem was that the (pre-mandate) DOD had no effective
'short list'. The list in question is that of approved languages
other than Ada which may be used if justifiable based on life cycle
costs. C is unlikely, as is Visual Basic, since neither has,
effectively speaking, a standard. C++ may become one, as might
Eiffel, in time. LISP is already close due to the existence of
COMMON LISP and the COMMON LISP Object System (CLOS) as de facto
standards.
A failing of DOD in the past has been its unwillingness to stop
or redirect projects which ignored the ENTIRE DOD language policy,
i.e., were not using COTS, not using advanced software technology,
not using Ada, and not using an approved alternate language. As
there has been some confusion in recent postings regarding specifics
of the policy itself I have extracted the relevant paragraphs from
the 1987 version of the DOD directive and included them here.
The primary immediate impression I hope to correct is one which
holds any language may be used if justified by life-cycle costs.
The issue addressed by the directive is the previous plethora of
languages, suitable or otherwise. Addition of new languages at
will, even if justified for a given domain or project, may incur
unacceptable organizational costs.
From the perspective of the DOD directive the proper action upon
finding a relatively novel language to be superior (in some useful
sense) to any of the existing approved languages is to seek
inclusion of that language in the list. This will require review of
the language in terms of availability, standardization, availability
of conformance test capabilities, tool support, etc. It will also
imply evaluation as well as of the supportability of the approved
set with the new language, i.e., should something be deleted or
replaced, or should the new language simply be added.
Of course, this type of review would logically include
consideration of hard data on the extant base of code in the
existing languages in the DOD. This data, if GA is correct, is not
at present maintained, making an adequate evaluation problematic.
* = * = * = * = * QUOTE * = * = * = * = *
DoD DIRECTIVE 3405.1
COMPUTER PROGRAMMING LANGUAGE POLICY
APRIL 2, 1987
3405-1.HLP
Ada Information Clearinghouse 1-800-AdaIC-11, 1-703-685-1477
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Department of Defense
DIRECTIVE
April 2, 1987
NUMBER 3405.1
ASD(C)
SUBJECT: Computer Programming Language Policy
:
:
<marginally related material omitted>
:
:
D. POLICY
It is DoD policy to:
1. Satisfy functional requirements, enhance mission
performance, and provide operational support through the use of
modern software concepts, advanced software technology, software
life-cycle support tools, and standard programming languages.
2. Achieve improvements in DoD software management through the
implementation of processes for control of the use of higher order
languages, including specification of standards and waiver
procedures.
3. Limit the number of programming languages used within the
Department of Defense to facilitate achievement of the goal of
transition to the use of Ada* (reference (g)) for DoD software
development.
a. The Ada programming language shall be the single, common,
computer programming language for Defense computer resources
used in intelligence systems, for the command and control of
military forces, or as an integral part of a weapon system.
Programming languages other than Ada that were authorized and
being used in full-scale development may continue to be used
through deployment and for software maintenance, but not for
major software upgrades.
b. Ada shall be used for all other applications, except when
the use of another approved higher order language is more
cost-effective over the application's life-cycle, in keeping
with the long-range goal of establishing Ada as the primary DoD
higher order language (HOL).
c. When Ada is not used, only the other standard higher order
pro- gramming languages shown in enclosure 3 shall be used to
meet custom-developed procedural language programming
requirements. The use of specific HOL's shall be based on
capabilities of the language to meet system requirements.
Guidance in selecting the appropriate HOL to use is provided in
NBS Special Publication 500-117 (reference (h)).
4. Prefer, based on an analysis of the life-cycle costs and
impact, use of:
a. Off-the-shelf application packages and advanced software
technology.
b. Ada-based software and tools.
c. Approved standard HOL's.
5. Consider the potential impact on competition for future
software and/or hardware enhancements or replacement when selecting
Defense, public domain, or commercially available software packages,
or advanced software technology.
6. Use life-cycle management practices, as required by DoD
Directive 7920.1 (reference (e)) and DoD Directive 5000.29
(reference (d)), for the development, support, and use of software,
whether custom-developed or commercially acquired.
7. Reduce software obsolescence and the cost of software
maintenance through use of approved programming languages and
appropriate advanced software technology during all phases of the
software life-cycle.
:
:
<marginally related material omitted>
:
:
-------------------------------------------------------------------------
3405.1 (Encl 2)
SPECIAL TERMS AND DEFINITIONS
1. Advanced Software Technology. Software tools, life-cycle
support environ- ments (including program support environments),
nonprocedural languages, modern data base management systems, and
other technologies that provide improvements in productivity,
usability, maintainability, portability, etc., over those
capabilities commonly in use.
2. Automated Information Systems. A collection of functional user
and automatic data processing personnel, procedures, and equipment
(including automatic data processing equipment(ADPE)) that is
designed, built, operated, and maintained to collect, record,
process, store, retrieve, and display information.
3. Major Software Upgrade. Redesign or addition of more than
one-third of the software.
-------------------------------------------------------------------------
3405.1 (Encl 3)
DoD-Approved Higher Order Programming Languages
---------------------------------------------------------------------------
| | | | Industry |
| Language | Standard Number | DoD Control Agent| Control |
| | | | Agent |
---------------------------------------------------------------------------
| Ada | ANSI/MIL-STD-1815A-1983 | Ada Joint Program| ANSI |
| | (FIPS 119) | Office | |
---------------------------------------------------------------------------
| C/ATLAS | IEEE STD 716-1985 | Navy | IEEE |
---------------------------------------------------------------------------
| COBOL | ANSI X3.23-1985 (FIPS 21-2) | Air Force | ANSI |
---------------------------------------------------------------------------
| CMS-2M | NAVSEA 0967LP-598-2210-1982 | Navy | N/A |
---------------------------------------------------------------------------
| CMS-2Y | NAVSEA Manual M-5049, M-5045| Navy | N/A |
| | M-5044-1981 | | |
---------------------------------------------------------------------------
| FORTRAN | ANSI X3.9-1978 (FIPS 69-1) | Air Force | ANSI |
---------------------------------------------------------------------------
| JOVIAL (J73)| MIL-STD-1589C (USAF) | Air Force | N/A |
---------------------------------------------------------------------------
| Minimal | ANSI X3.60-1978 (FIPS 68-1) | Air Force | ANSI |
| BASIC | | | |
---------------------------------------------------------------------------
| PASCAL | ANSI/IEEE 770X3.97-1983 | Air Force | ANSI |
| | (FIPS 109) | | |
---------------------------------------------------------------------------
| SPL/1 | SPL/1 Language Reference | Navy | N/A |
| | Manual, Intermetrics Report | | |
| | No. 172-1 | | |
---------------------------------------------------------------------------
* = * = * = * = * END QUOTE * = * = * = * = *
Nick Sizemore
+------------------------------+---------------------------------+
|N. L. Sizemore | (602) 538-4883 [Voice] |
|Computer Sciences Corporation | (602) 538-4933 [FAX] |
|P. O. Box 719 | sizemore@huachuca-emh17.army.mil|
|Ft. Huachuca, AZ 85613-0719 | |
+----------------------------------------------------------------+
| "For aggregate success, members must be the same to the |
| system and different to the environment." |
| |
| Second Aggregate Law in General Principles of |
| System Design |
| Gerald & Daniela Weinberg |
+----------------------------------------------------------------+
^ permalink raw reply [flat|nested] only message in thread
only message in thread, other threads:[~1994-10-11 14:53 UTC | newest]
Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1994-10-11 14:53 Eiffel for DoD Nick Sizemore
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox