From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=BAYES_00,INVALID_DATE autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,f7ce51f6a7d4ea50 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 1994-10-11 19:26:14 PST Path: bga.com!news.sprintlink.net!howland.reston.ans.net!europa.eng.gtefsd.com!MathWorks.Com!zombie.ncsc.mil!paladin.american.edu!auvm!HUACHUCA-EMH17.ARMY.MIL!sizemore Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU Newsgroups: comp.lang.ada Message-ID: <9410110753.A03922@huachuca-emh17.army.mil> Date: Tue, 11 Oct 1994 07:53:47 MST Sender: Ada programming language From: Nick Sizemore Subject: Re: Eiffel for DoD Comments: To: INFO-ADA@VM1.NODAK.EDU Date: 1994-10-11T07:53:47-07:00 List-Id: Subject: Re: Eiffel for DoD Ken Garlington <73672.2025@COMPUSERVE.COM> writes: > "Jeffrey W. Stulin" 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 : : : : 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. : : : : ------------------------------------------------------------------------- 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 | +----------------------------------------------------------------+