Ada - The Project
The DoD High Order Language Working Group

William A. Whitaker, Colonel USAF, Retired
PO Box 3036, McLean VA 22103


"Ada - The Project, The DoD High Order Language Working Group", copyright 1993, was originally published in ACM SIGPLAN Notices (Vol. 28, No. 3, March 1993). It is carried here with permission.

Permission to copy without fee all or part of this material is granted provided that the copies are not made or distributed for direct commercial advantage, this ACM copyright notice and the title of the publication and its date appear, and notice is given that copying is by permission of the Association for Computing Machinery. To copy otherwise, or to republish, requires a fee.


The Department of Defense (DoD) High Order Language Commonality program began in 1975 with the goal of establishing a single high order computer programming language appropriate for DoD real-time embedded computer systems. A High Order Language Working Group (HOLWG) was chartered to formulate the DoD requirements for High Order Languages, to evaluate existing languages against those requirements, and to implement the minimal set of languages required for DoD use. Other parts of the effort included administrative initiatives toward the eventual goal. Specifically, DoD Directive 5000.29 which provided that new defense systems should be programmed in a DoD "approved" and centrally controlled high order language and DoD Instruction 5000.31 which gave the interim defining list of approved languages. The HOLWG language requirements were widely distributed for comment throughout the military and civil communities worldwide. Each successive version of the requirements, from STRAWMAN through STEELMAN, produced a more refined definition of the proposed language. During the requirement development process, it was determined that the set of requirements generated was both necessary and sufficient for all major DoD applications (and the analogous large commercial applications). Formal evaluations were performed on dozens of existing languages. It was concluded that no existing language could be adopted as a single common high order language for the DoD, but that a single language meeting essentially all the requirements was both feasible and desirable. Four contractors were funded to produce competitive prototypes. A first-phase evaluation reduced the designs to two, which were carried to completion. In turn, a single language design was subsequently chosen. Follow-on steps included the test and evaluation of the language, control of the language and validation of compilers. The production of compilers and a program development and tool environment were to be accomplished separately by the individual Service Components. The general requirements and expectations for the environment and the control of the language were addressed in another iterative series of documents. A language validation capability (the test code suite) and associated facilities were established to assure compliance to the language definition of compilers using the name "Ada". The name Ada was initially protected by a DoD-owned trademark.




The computer programming language, Ada, was the outcome of one part of a rare engineering project initiated and technically managed at the level of the Office of the Secretary of Defense (OSD), specifically, by the Office of the Director of Defense Research and Engineering (DDR&E). This paper describes the early days of the project in which the development of Ada took place. However, the purpose of the project encompassed more than just another language definition and development. This paper covers the broad project, but not the internal details of the winning language design team effort led by Jean Ichbiah.

Since the Ada effort was an extraordinarily open project, all the concrete information about it is already a matter of public record. In addition, there have been a number of summaries [Carlson, 1980], one in the front of most every Ada book, for instance. This raises the question of what this paper is going to add to this literature. My goal is to add a firsthand perspective of the details that get lost in the textbooks, to provide insight into DoD handling of a project like this, and to point out some of the transient aspects that seemed very important at the time. This will put a very personal slant on the presentation; it is as I remember it.


Since this a personal history, I will give some background about how I became involved. I spent 15 years at the Air Force Weapons Lab (AFWL) at Kirtland AFB, New Mexico, then the largest scientific computing organization in the DoD. Over this period software programs had gotten much larger and more expensive, but tools and support had not kept pace. With each new machine, operating system, or compiler it appeared that all the common, first-level tools had to be regenerated. I wrote various tools half a dozen times over the years, and finally felt like giving up. The tools never got out of the first generation because one could not build with confidence or share with others who had different machines. We did manage to greatly improve the applications codes because each was supported by several people full time. Like everyone else, we did not usually worry if that code was portable since we initially did all the production in-house. This was fine locally, but bad for the DoD. Finally a very elaborate and successful porting system was implemented, but it was only for applications code.

In the late 60's, several manufacturers were the designing next generation of supercomputers. As a major potential customer, AFWL was involved to determine how our software would mate to their designs, if the code could be structured for their architectures, parallel, pipeline, or otherwise. As a customer, we were in a favored position and had access to the proprietary designs of each manufacturer. I discovered that each was planning a different FORTRAN-like language extended beyond the 1966 standard. I proposed that it would be more convenient for the customers (namely the government), and for competitive evaluations, if the language could be common, so far as was feasible. This thought was violently rejected by all parties without any discussion. I considered this attitude to be very short-sighted on the part of the manufacturers. Nevertheless, the thought stayed with me, and might be considered the genesis of the DoD common language program.

When I came to OSD in January 1973, the office to which I was assigned had recently had its name changed from Electronics and Computer Sciences (E&CS) to Electronics and Physical Sciences (E&PS), which showed that computers stood very low in the Services' research pecking order. I was responsible for the Service basic research (6.1) programs, advanced weaponry research (since I was from the Weapons Lab), and any computer activity I could find.

In 1973 I initiated the DoD "Software Initiative" to reduce the "High Cost of Software". (There have been several later "Software Initiatives" in the DoD, but this was the first and must have been well received as a talking point since the name has been reused.) While conducting "math area" research reviews in April, I was struck by the total lack of DoD research into improving the development of operational software. This seemed like a major DoD problem to me but there was no recognition of it by the Service research organizations (Army Research Office (ARO), Office of Naval Research (ONR), and Air Force Office of Scientific Research (OSR) - known collectively as the OXRs). The Defense Advanced Research Projects Agency (DARPA) supported computer research, but none of it was directed toward operational software, and DARPA was not under my control anyway. The Service research organizations were reasonably responsive to someone who can hold up their money, so I tasked the OXRs to explore the area of software for possible research opportunities. That summer a "Symposium on the High Cost of Software" was organized at the Navy Post Graduate School in Monterey [Monterey, 1973].

At the symposium, Barry Boehm of TRW gave the keynote speech. He had just completed a study sponsored by the Air Force Space and Missile Systems Office (SAMSO) on Command and Control Information Processing for the 80's (CCIP-85). Volume 4 [SAMSO, 1972] of the study (originally Volume 6) - the one on software - estimated that the Air Force was spending over $1.5 billion a year on software, which was often late and unreliable, and that the costs were rising. This was a shocking conclusion at the time, and the dollar estimates, now seemingly small, were rejected out of hand. When the Air Force published the rest of the study but refused to publish this volume. My boss, George Heilmeier, Director of E&PS, thought that was inappropriate and obtained its release by suggesting that he might find it necessary to copy and distribute such critical information within the Pentagon, if the Air Force did not do so.

At that point I met David A. Fisher from the Institute for Defense Analyses (IDA), a DoD funded "think tank" from which each OSD office could request some support. E&PS asked for an IDA study to validate Boehm's figures. It was not that we doubted the figures, but that we needed all the documentation we could get if we were to initiate a major effort. Further, IDA could draw on Pentagon figures and get a different perspective on software costs. Fisher did the IDA study [Fisher, 1974] and substantiated the Boehm figures exactly, but by an entirely different procedure. He so impressed us that he was co-opted into the follow-on project.

We got some agreement that software cost and reliability was a problem, but the question was - what could be done; more specifically, what could be done by OSD? We got the problem passed to the Services in the annual Budget Memorandum of the Secretary of Defense, which is raising it to the "highest level" in the DoD. The question was then what programs OSD should enter into to solve the problem?

We had identified the proliferation of programming languages as having a major impact on costs, or at least, this proliferation made it effectively impossible to do anything to improve the cost picture. At this time each of the Services had programs to develop unique languages, computer architectures, and hardware. Their previous efforts certainly had not reduced the cost of software, and none of these programs was likely to do so either, but maybe a joint effort could. I figured that a common language for use throughout the DoD would be a first step to building an engineering discipline of software, to supersede the then current "black art". My initial proposal was that a common language would facilitate the development of common tools, techniques, training, and metrics, and would not coerce, but enable, the sort of cooperation and long-term development that characterizes a scientific or engineering culture. Key to the payoff from the project was the expectation that a common language would promote the production and use of common tools and reusable code. Early economic analyses concluded that half of the benefit of a single powerful language would be from its technical merits, and half simply from the advantages of commonality.

This was the DoD and it took a while to get organized. During that time (1974) I was encouraged by a number of people; chief among then was Bernie Zempolich of the Naval Air Systems Command (NAVAIRSYSCOM). He had just returned from the Industrial College of the Armed Forces (ICAF), where after graduation he remained as the first civilian Research Fellow. His study was entitled "An Analysis of Computer Software Management Requirements for Operationally Deployable Systems". We interacted when he was the Command Technology Manager for the Navy All Applications Digital Computer (AADC). He became a founding member of the project. In fact, before the working group was established, his pioneering work in this area gave impetus and technical support to the entire DoD thrust. During the early years of the project, he served as secretary and spokesman. He contributed enormously to the early work of the project. These contributions - technical, administrative, and policy - established the future direction of the program. "Credit" also goes to him for jokingly dubbing the future HOL with the acronym "DOD-1".


The starting position in 1974 of the Common DoD High Order Language Program was to produce a minimal number of common, modern, high order computer programming languages for Department of Defense embedded computer systems applications and to assure a unified, well-supported, widely available, and powerful programming support environment for these languages. This was an intuitive statement of the task. To obtain acceptance, a justification had to be made, especially to initiate an effort at the OSD level, rather than the usual Service programs. We had to make sure we were addressing the real problem, rather than just doing what was easy, in order that this be a needs-driven engineering development, not a research exercise.

The total cost of DoD software increasingly attracted the attention of the highest levels of management within the Department of Defense. Cost studies estimated that the then-annual expenditure of funds for software within the DoD was in excess of $3.0 billion dollars (small now, but impressive at the time). A large portion of these growing software costs represented increased performance requirements and the transference of efforts previously considered a part of the hardware system design. The percentage of this amount that was susceptible to reduction through technical improvements could not be precisely determined. However, there was extensive anecdotal support visible to OSD in frequent reports of software development troubles indicating that the percentage would be significant, especially when the indirect costs of schedule slippage and system readiness problems attributable to software development delays and poor reliability were included.

Software costs include the design, development, acquisition, management, and operational support and maintenance of software. Only a small fraction of these tasks are involved with the functions which are defined by the Federal Government as Automatic Data Processing, those functions that have their exact analogy in the commercial sector and share a common technology, both hardware and software. A much larger fraction, more than 80%, of the DoD's computer investment is in computer resources which are embedded in, and procured as part of, major weapons systems, communications systems, command and control systems, etc. In this environment the DoD found itself spending an even larger share of its systems resources on software.

At this point I must offer some definitions, and explain how they came about. Computers in the DoD are of two general varieties. Automatic Data Processing (ADP) covers those "stand alone" systems that do ordinary commercial computer jobs: accounting, financial management, payroll, inventory, word processing, etc. The other kind, now popularly called Embedded Computer Systems (ECS), are those "embedded" in aircraft, missiles, tanks, shipboard, etc. An ECS can be a computer-on-a-board, or a special purpose device hardened to heat, cold, gravitational pull (g's) and electromagnetic or nuclear radiation. Or it may be an ordinary commercial machine operating in the traditional air-conditioned room, indistinguishable from the hardware in accounting.

The distinction is not hardware, but under what set of regulations the computer is procured. Historically there have been two computer hierarchies in the DoD corresponding to two different responsible Committees of the Congress. ADP is administered under provisions of the Brooks ADP Act (Public Law 89-306) and through Comptroller organizations in the DoD. For these systems there is a set of rules designed to eliminate duplication and promote competition in that part of the computer industry that concerns itself mainly with the private sector, and deals with roughly interchangeable products and simple economic judgements.

Weapons systems are handled and monitored (oversight) by different Congressional Committees and by different organizational elements in the DoD responsive to those Committees. At the time of the HOLWG, this was DDR&E at the OSD, and the Service Assistant Secretaries for Research and Development. There was a "5000 Series" of regulations (DoD Directives and Instructions) to govern weapons systems, including their computers. In the early 70's these were generally called "weapons systems computers". A short time later they were called "embedded systems" to convey the message that also they included functions such as control, communications, and intelligence systems, not just bombs and guns. More correctly, the name referred to the fact that they were procured as part of an overall system, not to their being physically "embedded" in a weapon. Nevertheless the image of "embedded" is strong and this has become the popular expression. Later an Appropriations Act invented the name "mission critical", which is certainly morale boosting anyway. Any attempt to parse these terms out of historical context is doomed.

These distinctions may seem esoteric to an outsider, but within the DoD the great religious conflicts of history pale to insignificance by comparison. The software initiative was specifically for defense system, developed under the 5000 series of regulations, and was originated by the organization (DDR&E) in charge of those systems. However, there was no intent to exclude the ADP applications or their problems. Indeed, there was an active liaison and consideration of this area during the whole process, but all the documents were very carefully worded to make sure they were within the proper administrative scope.

In determining the scope of the problem we set out to address the "tall pole in the tent", that is, the major portion of DoD software costs associated with Embedded Computer Systems, software integral to defense or weapon systems, including target detection and tracking, weapons direction, communications, command and control, avionics, simulators, test equipment, and other such applications and their run-time support systems. Additionally, software which supports the design, development, and maintenance of such systems must be included when identifying total costs. Within this systems environment, the DoD found itself spending an increasingly larger share of its financial and manpower resources on software. While programming language commonality throughout the DoD would not, by itself, make software less expensive, it would enable a large number of technical and managerial initiatives leading to such savings. And it was something that was uniquely within the scope and power of OSD to implement.

Another consideration was the impact of software on hardware costs. We were entering a period in which there was the expectation that systems should become much more responsive and flexible because they were controlled by "easily changeable" software, rather than hardwired hardware, practically impossible to modify. This enormous advantage would be realized only if software really was modifiable. There was a growing experience that assembly language "spaghetti software" was becoming more difficult to modify and maintain. Clearly some change in the way we were doing business was necessary.

The ultimate hardware advantage from software is the potential for switching out a piece of obsolete and expensive hardware for new smaller, cheaper technology. Much of the obsolete hardware in the field was being kept because the software would run on no other machine. It may be that the contractors were not eager to change this situation, since such old hardware required a lot of expensive maintenance and probably only the one that made it could keep it up. But the DoD was left with systems for which the yearly maintenance cost might exceed the cost of modern hardware.

A corollary to this situation is that when hardware was selected at the beginning of a major development, it was sure to be obsolete 10 years later when the system was in the field. Unfortunately it could not effectively be upgraded. These weapons systems implications are not unlike those for general ADP; however, the application must color the requirements. Software transportability (like reuse) was a major factor to the DoD, but not to an individual manager with a three month horizon.

While significant progress had been made in achieving commonality in computer hardware and software for scientific and business applications, the physical and real-time constraints imposed on embedded computer systems placed technical obstacles in the path of commonality efforts for these systems. Additionally, in the case of scientific and business systems, there had been a powerful incentive for the computer industry to develop standards (FORTRAN and COBOL) as a marketing tool. This incentive had not been present in the development of embedded computer systems for the DoD. On the contrary, it could be argued that short-term management goals (contractor and government) encouraged proliferation.

Another factor in the decision was that at that time, the DoD had a greater influence on software technology than on hardware. Some years previous, the DoD was the major innovator and consumer of the most sophisticated computer hardware possible. By 1974 the DoD represented only a small fraction of the total commercial market. In software, that unique position still existed. A significant fraction of the total software industry was devoted to DoD related programs and that was true in an even larger proportion for the more advanced and demanding systems. Thus, there was both an opportunity and a responsibility in the software arena, which was long past for hardware.

To summarize, the logic of the initiative was as follows: The use of a high order language reduces programming costs, increases the readability of programs and the ease of their modification, facilitates maintenance, etc. and generally addresses many of the problems of life cycle program costs. A modern powerful high order language performs these tasks and, in addition, may be designed to serve also in the specification phase and provide facilities for automatic test. A modern language is required if real-time, parallel processing, and input/output portions of the program are to be expressed in high order language rather than assembly language inserts, which destroy most of the readability and transportability advantages of using an HOL. A modern language also provides error checking, more reliable programs, and the potential for more efficient compilers.

Many of the advantages of a high order language can be realized only through computer tools. A total programming environment for the language includes not just compilers and debugging aids, but text editors and interactive programming assistance, automatic testing facilities, extensive module libraries, and even semi-automatic programming from specifications. Universal use of these tools can significantly reduce the cost of software and lead to the development of more powerful tools. The average DoD programmer's tool box was rather bare in the 1970's. Because of the difficulty of preparing these tools for each new language and machine and operating system, and the time involved, only the very largest projects had been able to assemble even a representative set. While in many cases development of tools can be shown to be desirable in the long run, day-to-day pressures not to perform the tool development activities usually prevailed. The use of a common high order language across many projects, controlled at some central facility, allows the sharing of resources in order to make available the powerful tools which no single project could generate. It makes those previously generated tools available at the beginning of a project, reducing star-up time.

Reducing the number of languages supported to a minimal number, therefore, should provide the greatest economic benefit. There are costs associated with supporting any particular project and general costs of supporting the language. For a sufficiently large number of users, presumably the basic cost would be proportionally less. Perhaps 200 active projects contributing to a single support facility may not be much cheaper than two facilities each supporting 100 projects. There are, however, unique advantages to having a single military computer language. For a single language, one could reasonably expect that language to be supported on new computers with a compiler (based upon the experience of the British with their common language effort, CORAL). Such support is not a reasonable expectation with five or ten common languages. Indeed, for a single common language, its use in DoD and the provision of tools by the DoD could make it a popular candidate for use elsewhere. The multitude of languages adopted by the military in the past (excepting FORTRAN and COBOL) did not receive this sort of acceptance. A single powerful supported high order language might even be expected to influence academic curricula, improving the training not so much of individual programmers but the understanding and capabilities of the general engineering community for support of DoD programs.

During 1974, elements in each of the Military Departments independently proposed the adoption of a common programming language for use in the development of major defense systems within their own Departments and undertook efforts to achieve that goal. Those efforts included the Army's Implementation Language for Real-Time Systems study, the Navy's CS-4 effort, and the Air Force's High Order Language Standardization for the Air Force study. Additionally, the Defense Communications Agency had pursued the "Development of a Communications Oriented Language". The fact that each of the Military Departments independently sought a standard military language to supplement COBOL and FORTRAN illustrated the need for a DoD-wide coordinated approach, as well as its timeliness.

Nevertheless, the proposal for language commonality across DoD was extremely radical at the time and initially met almost universal opposition. In fact, it was regarded as unrealistic to expect to use a high order language for embedded systems. It may be surprising that a consensus did not mandate a common high order language for embedded systems much earlier. There are, however, a number of managerial and technical constraints that acted against this. For many DoD systems, severe timing and memory considerations were dominant, governed by real-time interaction with the exterior environment. Because of these constraints, and restrictions in developmental cost and time scale, many systems opted for assembly language programming. This decision was influenced by past experience with poor quality compilers and the fact that an assembler routinely comes with the machine, while the compiler and its tools usually must be developed after the project has begun. The advantages of high order languages, however, were compelling, and more systems turned to them. Because of limitations of available high order languages, the programs generated often included very large portions done in assembly code and linked to an HOL structure, negating many of the HOL advantages.

Further, many systems found it convenient to produce their own high order language or some incompatible, dialect of an existing one. Since there was no general facility for control of existing languages, each systems office did the configuration control on its language and compilers and continued this for their particular dialect through the entire maintenance phase of the system. This had the effect of reducing the contractual flexibility of the government and restricting competition in maintenance and further development. This lack of commonality negated many advantages of high order languages including transportability, sharing of tools, the development of very powerful tools of high efficiency and, in fact, not only raised the total cost of existing tools, but in some cases essentially priced them out of the market. Development projects were very poorly supported and forced to live with technology far below what should be the state-of-the-art.

The target for a major language project was to be DoD "software in the large". This is often given a limited interpretation, namely that DoD programs are individually large, which is certainly true and drives many of the technical requirements on the language. But the fact that the DoD has hundreds of such large programs provides an opportunity for economies of scale that are potentially much greater than the sum of individual projects. The problem is not just that of producing a subsystem of 200,000 lines of code, but of the servicing of a "system" that is all the code produced by the DoD for (by 1990) $30 billion per year ("programming in the very large"). This path drives other requirements and properties, like machine independence which forces the validation requirement and the rejection of subsets. But these advantages can be realized only if the technology is applied with consistency over the whole of the DoD, and an even larger community if possible. So a strong position from the DoD was vital to the plan.


The process of building a constituency for the Software Initiative began with the setting up of a fairly informal Weapons System Software Committee between DDR&E and OSD Installations and Logistics (I&L), the branch responsible for maintenance. I represented DDR&E and R. D. "Duke" Hensley, who made a very large contribution in this starting year of 1974, represented I&L. Meetings involved discussions of the software problem and possible actions. From this grew the nucleus of the DoD language project and the coordination that led to the establishing memo.

In December 1974, this Committee was renamed the Weapon System Software Management Steering Committee (SMSC) in a memo "Management of Weapon System Software" by M. R. Currie, A. I. Mendolia, and T. E. McClary and added representation from the Office of the Assistant Secretary of Defense (Comptroller) (ASD (Comp)), to study the general area of software management for weapon systems. This committee was later renamed the Management Steering Committee for Embedded Computer Resources (MSC-ECR). Barry DeRoze from I&L became the first Chairman. He was the prime mover in the OSD arena for coordination of the Directives. This position was later occupied by H. Mark Grove, who shepherded the formation of the Ada Joint Program Office (AJPO) in 1980.

The enabling memo [Currie, 1975a] (Figure 1) for a DoD High Order Language Working Group (HOLWG) was issued in January 1975, but by that time the work was fairly well under way. The technical work proceeded in the HOLWG. The SMSC drafted DoD Directive 5000.29 [DoD1976b], which formally established the committee and renamed it as the MSC-ECR. Then the HOLWG formally became a subcommittee of the MSC-ECR and in November 1976 a HOLWG Charter was formalized, long after the fact. It all sounds a little baroque. These dates, which are the "facts" of history that an outsider might find in the records, have nothing to do with what was actually going on. There was a studied and logical progression, but the paper trail was constructed after the fact to please those who needed boxes filled.

The MSC-ECR took care of much of the general administrative coordination. It wrote and coordinated DoD Directive 5000.29 and DoD Instruction 5000.31. On January 31, 1977, the MSC-ECR issued an Issue Paper 77-1 recommending authorization to proceed with the preliminary design phase for a common language, with $300,000 from each Service. Throughout the lifetime of the program monies were allocated as necessary. While prudent management was exercised, this was recognized as an important program and there was never any funding or timing constraint imposed from above after approval to proceed to the next step.

The MSC-ECR also sponsored economic analyses of the benefits of language commonality. This was a necessary step in the formal process. The MITRE Corporation performed an economic analysis of language commonality [Clapp, 1977] under the auspices of the MSC-ECR and ASD(I&L). An automated decision analysis sponsored by DARPA was generated by Decision and Design Incorporated [Fox, 1978] to investigate introduction strategies and benefits. The HOLWG internally generated a program to quantify economic benefits [HOLWG, 1977c]. These were targeted to questions of expectation of savings to the Department of Defense resulting from the successful completion of this program. They further examined various introduction strategies and rates. Significant savings were demonstrated, and these were magnified by rapid introduction. Savings of hundreds of millions to tens of thousands of millions of dollars were independently derived.

As a result of these studies and of general concerns, the program was exceptionally well supported at OSD. Monies were always made available once a decision was made. However, since this program was a new start and not in the five-year plan, this often meant persuading the Services to divert funds from other projects. No schedule was imposed from above, but there was a feeling that this was a fleeting moment of opportunity.


The intent was to have a common real-time language to replace the existing mix, while maintaining the standards of FORTRAN and COBOL, the success of which had provided impetus to this consolidation program. Further, to assure non-proliferation during this effort, all other implementations of new high order programming languages for R&D programs were halted. The January 1975 DDR&E memo (Figure 1) to the Military Departments directed "A working group should be formed from representatives of your Departments and chaired by ODDR&E" establishing the HOLWG, and making it the agent for this effort. This initial authorization was the first major milestone of the project; others are listed in Figure 14.

At this point it is necessary to explain something about the workings of OSD. Contrary to what one might expect, OSD does not rule the DoD and the Services with an iron rod. The main control is money, and the DoD has very little money of its own - most of the money is appropriated to the Services. But the Service funding passes through DoD on the way, and the distribution process could get very slow and sticky, so the Services do listen. Nevertheless, OSD actions can usually be characterized as coordination. If OSD memos, like that setting up the HOLWG, sometimes seem to be expressed mildly, one should not misjudge their import. There are fairly few directing memos. They, like Directives and Instructions, are extensively coordinated before they are issued, not only within OSD but with the Service recipients. Characteristically, the action is agreed to by all parties, not necessarily without some arm twisting, before a memo is signed. Everyone knows the intent and what is expected, even when the memo is worded gently and with delicate political sensitivity. So a memo may mean more than it says.

The membership of the HOLWG consisted of a chairman, myself, appointed by and representing DDR&E, plus representatives of each Military Department appointed by and reporting to the Departmental Assistant Secretaries (Research & Development), plus other components and agencies to be called upon to present their comments and specific expertise. (Specific membership of the HOLWG is discussed later.) Throughout the program, authority came from DDR&E and the memos were the form of communicating this authority. These memos may appear to be mild, not what one might think of as a military order, but in the DoD this is the way most things get done. Each DDR&E memo was a major milestone in the effort.

28 Jan 1975 MEMORANDUM FOR ASSISTANT SECRETARIES OF THE MILITARY DEPARTMENTS (R&D) SUBJECT: DoD Higher Order Programming Language In studying the computer software problems of the DoD, it has become clear that standardization in higher order programming languages is necessary. The advantages in training, instrumentation, module reutilization, program transportability, etc. are obvious. In business and scientific applications, COBOL and FORTRAN have evolved as standards, but in the areas of weapon systems, command and control, test equipment, etc., the DoD has supported a large number of limited use developments, many for a single project. That each of the Military Departments has independently proposed a standard military language to supplement COBOL and FORTRAN testifies to the need. We concur that such standard language efforts should do much to reduce the high cost of software to the DoD and further suggest that the benefits would be multiplied if a single common military language were the outcome. We call upon the Military Departments to immediately formulate a program to assure maximum DoD software commonality. A working group should be formed from representatives of your Departments and chaired by ODDR&E. This group will investigate the requirements and specifications for such commonality, compare with existing DoD efforts, and recommend adoption or implementation of the necessary common language or languages. My office has informally discussed this in some detail with various Service Offices, primarily USACSC, NAVAIR-360 and AFSC/XRF. We have been working closely with OASD(Comp) and OASD(I&L) who will also participate in the study. Until the matter is resolved, we do not intend to support any further implementation of new higher order programming languages in R&D programs. As this may impact proposed program schedules, we regard the completion of this task as a matter of urgency and request you name working group representatives within one week of the date of this letter. You may have your representatives contact Lieutenant Colonel William A. Whitaker, OX7-4197. Malcolm R. Currie

Figure 1

[All memos and figures have been retyped]

The organization and procedures of the HOLWG were up to the chairman - anything I could make work. The only reporting was to DDR&E and I made the reports. This sounds dictatorial, and to a large degree it was, but it only worked as long as I held it together. In fact, it was a consensus operation. Every formal vote that the HOLWG ever took was unanimous! That is not to say that there were not many lively discussions and opposing views, but I waited until everybody agreed on a course of action before posing a formal vote. The question was usually not "which of these is your favorite?", but "which should be the HOLWG choice?" Under those conditions, the HOLWG functioned smoothly.

The HOLWG was not a committee of language designers. It was a group representing the users. It eventually contracted for language designers, but design was not its only function. The exact working membership of the HOLWG was never a fixed list. I was the only name mentioned in the DDR&E memo, as Chairman. After that the HOLWG was constituted from members nominated by the Services. There is a list in the Charter of November 1976, but it is pro forma and does not necessarily represent the workings of the group.

Each of the Services has its own personality and that was reflected in the personnel assigned to the HOLWG. The Army is very formal and works on orders, often from the Adjutant General (TAG). Major Brehault from Army Computer Systems Command (USACSC) was the first representative, replaced on his reassignment by Major Ben Blood. Dr. Serafino Amoroso from Ft. Monmouth was brought in as a technical representative of the Electronics Command (USAECOM then CORADCOM).

For the Air Force, whoever is in the office responsible that is the representative. Lt. Col. John H. Manley from the Air Force Systems Command (AFSC) was their first representative, shortly followed by Major Thomas H. Jarrell. Samuel A. Di Nitto of Rome Air Development Center (RADC/ISIS) gave technical support. Col Robert Ziernicki and Lt Col John Marciniak provided headquarters (AFSC/XR) support. Eventually Major Al Kopp represented the Air Force to Ada, and Ada to the Air Force.

The Navy is much more complex, because it is organized along the lines of major platform types (air, surface, and land). Bernard Zempolich, then with the Naval Air Systems Command (NAVAIR), was an original member, as was Robert Kahane. Lt Col Joseph G. Schamber represented the Marine Corps during the entire life of the HOLWG. CDR Jack D. Cooper was subsequently designated representative by the Naval Material Command (NAVMAT). LCDR David C. Rummler from ONR-London facilitated our early European contacts and meetings. Warren Loper of Naval Ocean Systems Center (NOSC) was brought in as technical expert, and no one worked harder or contributed more than he.

The Agencies were represented by William Carlson (DARPA), Paul Cohen (Defense Communication Engineering Center of the Defense Communications Agency - DCA), and Steve Squires followed by Terry Ireland (National Security Agency - NSA).

Dave Fisher (IDA) was the technical secretariat of the HOLWG and ran all aspects of the technical operation.

This project was conceived of as an effort in international cooperation and a number of Europeans were involved, in the meetings, working full-time in Washington, or coordinating and supporting from Europe:

For the United Kingdom Ministry of Defence (UK MOD), the Royal Signals and Radar Establishment (RSRE - Malvern) contributed the efforts of Nick Neve in the United Kingdom and Philip Wetherall who spent a year in the United States working within the DoD structure on the Ada effort.

For the Federal Republic of Germany (FRG), Dr. Horst Clausen (Industrieanlagen-Betriebsgesellschaft mbH - IABG) was in close contact with the project and attended HOLWG meetings. Dr. Eberhard Wegner (Gesellschaft fur Mathematic und Datenverarbeitung) provided governmental coordination. Dipl. Phys. Peter Elzer (Physics Instiutut, Erlangen) spent a year in the United States working on the program. His representation was particularly gracious since he was responsible for PEARL, the language that the Germans had proposed for an International Standard with which the HOLWG product would be in direct competition.

For France, Nicholos Malagardis (Bureau d'Orientation de la Normalization en Informatique) and Jean Robert (CAP-Sogeti Logiciel) were especially helpful, and P. A. Parayre representing the Ministre de Marine made many trips to attend HOLWG meetings.

Each of these countries was fully consulted and a voting member of the HOLWG. (At this time there was an initiative called the "Two Way Street", which was to promote Defense acquisition cooperation between the United States and its NATO allies. The DDR&E once told me that he thought that the HOLWG program was the only example that was working.)

Other Federal organizations were kept informed of the HOLWG progress but were not involved programmatically to any significant degree. By contrast, members of the standards community for COBOL, FORTRAN and PL/I were major contributors to the HOL investigations. The Navy COBOL Validation Facility had a major input for validation concepts.


The HOLWG was established to (a) formulate the requirements for common DoD high order languages, (b) compare those requirements with existing languages, and (c) recommend adoption or implementation of the necessary common languages. This was the original charge in the DDR&E HOLWG memo, that is, this was a direction taken before the formal organization of the HOLWG. There was work, and a number of memos to the Services, before the January 1975 founding of the HOLWG.

The first charge to the High Order Language Working Group was to establish requirements. In terms of reference, the working group was to consider general purpose computer programming languages. This was a limited goal and did not include either generalized requirements languages or very specific applications packages, which are formulated like languages but have only limited access to the capabilities of the computer. Such applications-specific languages include simulation programs, such as SIMSCRIPT or GPSS, and ATLAS, an automatic test equipment language which is for communications between the test engineer and the technician and is the DoD standard for maintenance test.

There were "requirements for requirements", part of the background of any engineering project, well known by those involved, but often unappreciated by those on the outside. In discussions, we often forget to state some of these because they seem so obvious, but I will mention a few that did not seem to be understood in the academic community.

The new language project was a DoD engineering development and had to live in the DoD environment. This project did not set out to break new ground nor invent new computer science, nor was its purpose to showcase particular ideas of language design, but it did have to push some ideas into concrete form. It had to produce a powerful and complete language, or it could not satisfy the requirement of being able to implement whole systems with machine independence (for portability), avoiding the extensive assembly language inserts that plagued then-current DoD HOL applications.

The character set discussion is a prime example of misunderstanding of the basic environment. For the DoD there was never any question. From 1955 to 1975 we had progressed from IBM 026 to 029 key punches, and there still were old ones in the field, and many machines used 6 bit characters! To be able to write programs in that environment, so there was a requirement for the language to work with a limited character set. The comments from the major Computer Science Departments universally condemned this "step back". They said we must have 256 characters. They all had local systems with many interesting properties, each incompatible with everything else in the world, which they assumed were available to everyone. From DARPA I had a chance to inspect a large number of such facilities and never could get much recognition that they did not represent the real world. (Note that the world never did go to APL, or even PL/I, keyboards.) (The ISO LATIN-1 proposal for Ada 9X has no relation to anything academically proposed for an 8-bit set in 1976. Even now, any extension beyond LATIN-1 is ambitious.) They would say that ANYBODY can do it, but for a common language the requirement is that EVERYBODY can do it. The purpose of HOLWG was a common DoD language. (This leads to a standard language, but the converse is not necessarily true. One may need a standard even for very limited use.) In the absence of such practical considerations, the reliability goal would have demanded that there be no distinction between upper and lower case in identifiers. Jean Robert of CAP, the largest software house in Europe, and LTPL-E, vetted the final 55-character set requirement for European acceptance.

Another requirement in this area was for fixed point arithmetic. While large scientific machines had provided floating point hardware for decades, such facilities had not reached military weapons computers. Many had difficulty understanding a fixed point requirement which was in the language, for purely practical, not mathematical, reasons, prompting a special study [Fisher, 1978a] in this area. (An extraordinary situation was generated when Headquarters Air Force, contrary to recommendations from the field, adopted, in 1976, a standard language for avionics software that provided only floating point arithmetic. At that time the Air Force had no avionics computer with floating point hardware! [Whitaker, 1990])

There were other common language meta-requirements. For example, the language must be an applications user language. This went against certain academic concepts of a mathematically minimalistic formulation, like ALGOL 68. The language must also be "complete" in the sense of the user being able to write all usual programs without having to resort to assembly language or local extensions. It had to have real-time capability and it had to be set up to produce programs for the bare machine in a missile, without support of an operating system. It also was required to support large Command and Control systems, so it had to have a file input/output system, however messy that might be.

The applications for this language were the large, long-lived, and lethal systems of the DoD. The users were the military and contractor personnel developing and maintaining these systems. These were professionals in a professional environment, not students or hobbyists. They would have various levels of talent and experience, but would be expected to have discipline, management, and adequate hardware and software support. The environment was one of large teams. The systems were compiled, so there was no requirement for the language to be interpretable on-the-fly, although there was nothing against that. Resources should be sufficient that one could support a compiler which could do extensive checking. The cost of compilers and the computer resources they demanded would be offset by the benefits of reliable systems and reduced maintenance.

Since the developed systems were to be long-lived, maintenance and modification of the software would cost several times as much as initial development. Readability was much more important than writability, a requirement contrary to those advocating the "economy of expression" that leads to incomprehensible C and APL code. Maintainability also argued for rigid interfaces and powerful compiler checking.

There were also certain "non-negotiable" demands of the users. The Navy insisted on a "goto" being written in as a basic requirement. There were, and may be still are, those in the Navy not enthusiastic about the project, so we paid that price for coordination.

The technical goals of such a high order language that were agreed upon at that time were the following:

o The language should facilitate the reduction of software costs. The costs must be reckoned on the total burden of the life cycle including maintenance, not just the cost of production or program writing.

o Transportability allows the reusing of major portions of software and tools from previous projects, and the flexibility for a system to change hardware while keeping the same software.

o The maintenance of very long lived software in an ever-changing threat situation requires responsiveness and timely flexibility.

o Reliability is an extremely severe requirement in many Defense systems and is often reflected in the high cost of extensive testing and verification procedures.

o The readability of programs produced for such long term systems use is clearly more important than coding speed, or writability.

o The general acceptability of high order languages is often determined by the efficiency and quality of the compiled code. While rapidly falling costs of hardware may make this difficult to substantiate in the abstract, each project manager will compare the efficiency of the object code produced against an absolute standard of the best possible machine language programming. Very little degradation is acceptable.

While these goals and "ilities" can be accepted, they do not lend themselves to a quantifiable or rational assessment of programming languages. We needed to establish criteria which were sufficiently explicit, determining the capability but not necessarily the form of the language. Rigorous definition of the exact level of requirement proved difficult. The method chosen for the preliminary requirements was to define this level by illustration. The HOLWG considered the problem from their experience of other developments and found that it was going to be difficult to do justice to the task, in fact, it was hard to even get started. Finally a group from the HOLWG just sat down and proposed a set of requirements. There was no claim that they were self-consistent or agreed to by all. But there had to be a start and this was done by February 1975, so the program was under way.

David Fisher acted as the Secretariat for the HOLWG, and so became the one who assembled, sifted, correlated, and integrated the requirements, since during the first couple of years, this was the primary action and output of the HOLWG. Fisher had designed machines at Burroughs and taught at Vanderbilt University, before joining IDA. His position was that of the technical heart of the project. It would be improper to say that he "wrote" the requirements, since this was an integration effort of Service needs with worldwide technical input. However, he that produced the final requirements documents; these were his offspring.

The resulting document, entitled STRAWMAN [HOLWG, 1975a], was forwarded to the Military Departments, other government agencies, the academic community, and industry. Additionally, a number of technical experts outside the United States were solicited for comments. The European community was especially responsive, particularly valuable since language research had been more active there than in the United States over the previous decade. ONR London paid several academics (Dijkstra, Hoare, Wirth, ...) to provide inputs, but we got more valuable aid from European industry.

A May 1975 DDR&E memo [Currie, 1975b] (Figure 2) reaffirmed the HOLWG goals to define and implement the minimum number of HOLs to satisfy the needs of the DoD and spelled out a program to evaluate candidates and prove the feasibility of meeting requirements, followed by implementation. The Military Departments were tasked to fund these efforts.

2 MAY 1975 MEMORANDUM FOR Assistant Secretary of Defense (Comptroller) Assistant Secretary of Defense (I&L) Assistant Secretaries of the Military Departments (R&D) Director, Telecommunications and Command and Control Systems SUBJECT: DoD Higher Order Programming Language Working Group This is to update you on the progress of the DoD Working Group on Higher Order Programming Languages. This group, composed of OSD members and designated representatives of the Services, was established pursuant to my memo of 28 January 1975. Their goal is to establish a minimal number of common higher order programming languages for utilization throughout the DoD. In the past, the multitude of pertinent DoD applications has caused a proliferation of special languages and, with them, excessive and extensive software costs. The first step in attaining the goal of the Working Group is to firmly establish the requirements for higher order languages from all possible users, even those for applications which are believed to have programming requirements not satisfied by any existing higher order language. Detailed requirements from those programs which use the existing common languages, COBOL and FORTRAN, are also desired, although there is no intent to supersede these languages. To initiate this process, the Working Group has drawn up a requirements "strawman", i.e., a list of possible requirements which, while indicative of the thinking of the committee, are primarily illustrative of the level of information needed. This strawman provides the Service representatives on the Working Group with a definitive example to use in their subsequent inquiries with users. A number of the requirements in the strawman have been selected to be provocative in order to stimulate comment. An additional purpose of the strawman is to elucidate the differences between objectives (economy and readability), requirements (the minimum primitive operators or capabilities for parallel processing), and features (which distinguish individual languages, but are not necessarily fundamental requirements). The Working Group intends to distribute a request to all possible users for inputs so that the eventual common language/languages resulting from this effort will be directly keyed to foreseeable programs. I request that you give all possible assistance to the Service representatives of the Working Group when they solicit such inputs. It is expected that these inputs will be informal initially, but eventually, a consolidated and coordinated official input will be required from each Service. Malcolm R. Currie Attachment DoD HOL Strawman

Figure 2

As a result of the widespread review of the STRAWMAN, the HOLWG received input and commentary from individuals and organizations representing many different areas of application within the DoD. There were mixed reviews. Some said it was too specific, others that it was too vague. So we knew we were on the right trail. The input and comments received by the HOLWG were codified and merged into a more complete, but still tentative set of language requirements. This document was entitled the WOODENMAN [HOLWG, 1975b], and it, in turn, was widely distributed for comment. Note that the thrust of the project at this time was to measure and compare language candidates. WOODENMAN was 88 typed pages and contained considerable description of project goals, as well as the desired characteristics of languages to support these goals. The following text example from WOODENMAN show the level of the document. Figure 3 illustrates a discussion of conflicts between goals and the proposed weighting and resolution. Figure 4 gives a few examples of the required characteristics.


There is a clear tradeoff between programming ease and safety. The more tolerant the programming language and the less it requires in specifications of the intent and assumptions of the programmer, the easier the coding task. A language which does not require declaration of variables, permits any type of structure of data to be used anywhere without specification, allows short cryptic identifiers, has large numbers of default conventions and coercion rules to permit the use of any operator with any operand, and is capable of assigning meaning to most strings of characters presented as a program will be very easy to use, but also easy to abuse. Safety from errors is enhanced by redundant specifications, by including not only what the program is to do, but what are the author's intentions. and under what assumptions. If everything is made explicit in programs with the language providing few defaults and implicit data conversions, then translator can automatically detect not only syntax errors but a wide variety of semantic and logic errors. Considering that coding is less than one sixth the total programming effort and that there are major software reliability and maintenance problems, this tradeoff should be resolved in favor of error avoidance and against programming ease.


Two apparently opposing views have been suggested. One, that a simple analysis of either development or life cycle costs shows that reliability, modifiability and maintainability are the most important factors and consequently clarity and correctness of programs must be given consideration over efficiency of the object code which only increases the cost of computer hardware (which is relatively cheap compared to software). In fact, if programs need not work correctly they can easily be implemented with zero cost. The other view points out real problems and applications within DOD software in which the machine capability is fixed and in which object code efficiency is of utmost importance and must be given preference over other considerations.

These views are not inconsistent with regard to the effort on programming language selection. In the vast majority of cases clarity and correctness is more important that is object code efficiency and the programming language should do the utmost to aid the programmer in developing correct and understandable programs within constraints of reasonable object efficiency. In most cases language features which improve clarity do not adversely affect efficiency. In many cases additional information supplied to clarify a program may permit the compiler to use optimizations not applicable in more general cases. There remain, however, special situations in which efficiency is critical. The language should not prohibit access to machine features necessary to accomplish those optimizations when the need arises. Thus, the major criteria in selecting a programming language should be clarity and correctness of programs within the constraint of allowing generation of extremely efficient object code when necessary.

Figure 3. Example from WOODENMAN - Conflicts in Criteria


1. The source language should be free format, should allow the use of mnemonically significant identifiers, should be based on conventional forms, should be simple uniform and probably LR(1), should not provide unique notations for special cases, and should not permit abbreviation of identifiers or keywords.

Clarity and readability of programs should be the primary criteria for selecting a syntax. Each of the above points can contribute to program clarity. The use of free format, mnemonic identifiers and conventional forms allows the programmer to use notations which have their familiar meanings, to put down his ideas and intentions in order and form that humans think about them, and to transfer skill she already has to the solution of the problem at hand. A simple uniform language reduces the number of cases which must be dealt with by anyone using the language. If programs are difficult for the translator to parse, they will be difficult for people. Similar things should use the same notations with the special case processing reserved for the translator and object machine. The purpose of mnemonic identifiers and key words is to be informative and increase the distance between lexical units of programs. The use of abbreviations eliminates these advantages for a questionable increase in coding ease.

2. The user should not be able to modify the source language syntax. Specifically, he should not be able to modify operator hierarchies, introduce new precedence rules, define new word forms of define new infix operators.

If the user can change the syntax of the language then he can change the basic character and understanding of the language. The distinction between semantic extensions and syntactic extensions is similar to that between being able to coin new words in English or being able to move to another natural language. Coining words requires learning those new meanings before they can be used but at the same time increases the power of the language for some application area. Changing the grammar (e.g., using French) however, undermines the basic understanding of the language itself, changes the mode of expression, and removes the commonalities which obtain between various specializations of the language. Growth of a language through definition of new data and operations and the introduction of new words and symbols to identify them is desirable but there should be no provision for changing the structure of the language. The language should, of course, provide sufficiently general forms that they can be adopted to new possibly unforeseen situations. Neither does this preclude associating new meanings with existing infix operators.

3. The syntax of source language programs should be composable from a character set suitable for publication purposes, but no feature of the language should be inaccessible using the 64 character ASCII subset.

A common language should use notations and a character set convenient for communicating algorithms, programs, and programming techniques among its users. On the other hand, the language should not require special equipment (e.g., card readers and printers) for its use. The use of the 64 character ASCII subset will make the language compatible with the Federal information processing standard 64 character set, FIPS-1, which has been adopted by the U.S.A. Standard Code for Information Interchange (USASCII).

4. The language definition should provide the formation rules for identifiers and literals. These should include a language defined break character for use internal to identifiers and literals.

. . .

Figure 4. Example from WOODENMAN - Needed Characteristics

A third generation set of requirements was subsequently produced, the TINMAN [HOLWG, 1976] of January 1976. TINMAN was synthesized from the formally stated requirements of the Military Departments, submitted to DDR&E by the respective Service Assistant Secretaries for Research and Development and worldwide technical input. It was formally blessed by the Services. The stated characteristics provided a design philosophy, indicated general structure, and constrained certain detailed properties of the common language; but they did not identify specific language features, consider the tradeoffs among various design and implementation mechanisms, nor demonstrate the feasibility of achieving all the characteristics simultaneously. TINMAN retained some discussion of goals, and Figure 5 provides and example. The format for the needed characteristics is illustrated in Figure 6, which is closer to a requirement specification, but with discussion. At this point we had a fairly firm grip on the problem, further versions were to be refinements.


The other major advantage initially claimed for high order languages was that they were easier to read and write, being closer to natural language than is machine code. Claims in this direction were sometimes carried to an extreme and some were promoted so highly that their advocates would have you believe that the coder need not know anything about the machine, simply write out the requirements in English. History does not always support these claims. Many such languages advocated on this basis now are the ones who have the most specialized programmers as their users. The DoD environment is sufficiently large and specialized that the allocation of personnel specifically for software is the rule anyway and there is no strong requirement to eliminate other specialists in this area. This is in contradistinction to a very small commercial firm which may have insufficient demands to justify a full-time programming staff.

Our requirement for readability and writability is therefore primarily among specialists. The desire to communicate with a computer system in natural language is an entirely different one in the DoD and involves query languages or applications programs outside the scope of this high order language effort.

Readability is clearly more important to the DoD than writability. The program is written once, but may have to be read dozens of times over over a period of years !or verification, modification, etc. This is certainly true all weapons systems applications and even most of our scientific and simulation programs are very long lived. This requirement is very much different from one which might be generated, for instance, in a university environment when a program may have a life of only a few months and a single person working on it.

Ease of writing is not an inconsiderable goal but one which may be promoted through intelligent terminals, preprocessors, interactive systems, etc. The language evaluation should favor readability where conflict arises.

Figure 5. Example from TINMAN - General Goals


1. General Characteristics 2. No Syntax Extensions 3. Source Character Set 4. Identifiers and Literals 5. Lexical Units and Lines 6. Key Words 7. Comment Conventions 8. Unmatched Parentheses 9. Uniform Referent Notation 10. Consistency of Meaning

H1. The source language will be free format with an explicit statement delimiter, will allow the use of mnemonically significant identifiers, will be based on conventional forms, will have a simple uniform and easily parsed grammar, will not provide unique notations for special cases, will not permit abbreviation of identifiers or key words, and will be syntactically unambiguous.
Clarity and readability of programs will be the primary criteria for selecting a syntax. Each of the above points can contribute to program clarity. The use of free format, mnemonic identifiers and conventional forms allows the programmer to use notations which have their familiar meanings to put down his ideas and intentions in the order and form that humans think about them, and to transfer skills he already has to the solution of the problem at hand. A simple uniform language reduces the number of cases which must be dealt with by anyone using the language. If programs are difficult for the translator to parse they will be difficult for people. Similar things should use the same notations with the special case processing reserved for the translator and object machine. The purpose of mnemonic identifiers and key words is to be informative and increase the distance between lexical units of programs. This does not prevent the use of short identifiers and short key words.

H2. The user will not be able to modify the source language syntax. Specifically, he will not be able to modify operator hierarchies, introduce new precedence rules, define new key word forms or define new infix operator precedences.
If the user can change the syntax of the language, then he can change the basic character and understanding of the language. The distinction between semantic extensions and syntactic extensions is similar to that between being able to coin new words in English or being able to move to another natural language. Coining words requires learning those new meanings before they can be used, but at the same time increases the power the language for some application areas. Changing the grammar, (e.g., Franglais, the use of French grammar with interspersed English words) however, undermines the basic understanding of the language itself, changes the mode of expression, and removes the commonalities which obtain between various specializations of the language. Growth of a language through definition of new data and operations and the introduction of new words and symbols to identify them is desirable, but there should be no provision for changing the grammatical rules of the language. This requirement does not conflict with E4 and does not preclude associating new meanings with existing infix operators.

H3. The syntax of source language programs will be composable from a character set suitable for publication purposes, but no feature of the language will be inaccessible using the 64 character ASCII subset.
A common language should use notations and a character set convenient for communicating algorithms, programs, and programming techniques among its users. On the other hand, the language should not require special equipment (e.g., card readers and printers) for its use. The use of the 64 character ASCII subset will make the language compatible with the federal information processing standard 64 character set, FIPS-1, which has been adopted by the U.S.A. Standard code for Information Interchange (USASCII). The language definition will specify the translation from the publication language into the restricted character set.

H4. The language definition will provide the formation rules for identifiers and literals. These will include literals for numbers and character strings and a break character far use internal to identifiers and literals.
. . .

Figure 6. Example from TINMAN - Needed Characteristics

One significant point agreed to was that the requirements for all Services and applications addressed were consistent with a single language. Up to this point there had been an argument about "the minimum number of languages". There was a general concern that, while a single common language was a goal, it was not technically feasible. The requirements exercise addressed this as a major consideration. We had been faced with the universal, and very strongly stated, opinions of the Services that different user communities had fundamentally different requirements with insufficient overlap to permit a common language among them. Such communities included avionics, weapons guidance, command and control, communications, training simulators, etc. In addition to the embedded computer applications, even the scientific and the financial management communities were solicited for requirements for the sake of completeness. The surprising result was that the requirements so generated were identical. It was impossible to single out different sets of requirements for different communities. All users needed input/output, real-time capability, strong data typing for compiler checking, modularity, etc. Upon reflection, the reason for this was clear; the surprise was historical, stemming from the observation that previously the different communities had adopted different language approaches. Further investigation showed that the origin of this disparity was primarily administrative rather than technical. The Navy was organized into branches for the employment of airplanes, surface ships, and submarines. The Air Force had ground electronics systems (ESD), aircraft systems (ASD), and space systems (SAMSO). Each thought it had to have its own special language. Upon this discovery, the result that a single set of requirements would satisfy a broad set of users became less of a surprise. This did not, however, establish that a single language could meet all the stated requirements, only that a language meeting all of the requirements would satisfy the users' needs.

Also for TINMAN we properly began computer automation. This and all subsequent documents were machine processed and printed on a "laser printer" (Xerox XGP), high tech in 1975. DARPA had the hardware to handle this. Also through DARPA, as the OSD agent, HOLWG was officially authorized mail franking privileges. The combination of these conveniences made it possible for the HOLWG to rapidly disseminate information and documents.

During 1976, the TINMAN was subjected to a thorough review for consistency and technical feasibility. The document was circulated to more than 1,000 individuals in the industrial and academic communities. An international workshop was held at Cornell University in the fall of 1976 [Williams, 1977] to illuminate the current state-of-the-art of programming language design and implementation. In January, 1977, a new version was issued called the IRONMAN [HOLWG, 1977b]. This was much the same set of requirements as the TINMAN, modified slightly for consistency, feasibility, and clarity, but presented in an entirely different format. The TINMAN was discursive and organized around general areas of discussion. The IRONMAN, on the other hand, was very brief and organized like a language manual. It was essentially a specification with which to initiate the design of a language, still sufficiently general so as not to constrain a particular structure of the language, but to define its capabilities. The IRONMAN was revised in July, 1977 [HOLWG, 1977d], mainly to clarify the intent, but also to correct the few errors and inconsistencies that had been identified.

The requirements documents can be viewed as an evolving series. The early ones have a great deal of explanation about the program, motivation and explanation. Those that were following the program presumably followed the evolving arguments, and the versions might be considered cumulative in that sense. There was a rationale for each requirement; early on the documents concentrated on the goals, whereas later the rationales were primarily technical discussions expanding on the implications of the specific requirements.

Requirements decisions made in 1975 proved essentially correct, and remained valid for more than a decade. Fixed point, goto, and the selected character set were requirements that were questioned outside the DoD, but supported inside. Fixed point may now be obsolescent as a result of the cheap hardware implementing the IEEE floating point standard [IEEE, 1985]. The goto is essentially never used, but causes no harm. A more extensive standard character set is only now becoming a possibility.


This project from the beginning was considered to be international in scope. It was recognized that Europe had much to contribute technically, and that successful outcome to the effort would be as useful to European military and industrial computing as it would to that of the United States. LTC Philip H. Enslow of the Army Research Office in London set up an Army Programming Conference in April 1975 attended by European computer scientists, including C. A. R. Hoare, Jacob Palme, David Parnas, Ian Pyle, John Webb, and Brian Wichmann, to provide input to the HOLWG effort.

LCDR David C. Rummler from the European branch of the Office of Naval Research facilitated our early European contacts and meetings and eventually returned to the United States to serve on the HOLWG.

The most successful national common language effort to date was that of the British Ministry of Defence (MOD) in specifying the language CORAL 66 for all MOD real-time applications. From extensive interchanges with the MOD, the HOLWG received invaluable technical and managerial insight into a major national language standardization effort. Furthermore, the MOD assigned Philip Wetherall, a senior technical expert, to be resident in Washington providing both technical input to the HOLWG and liaison with the MOD. Wetherall's contribution was particularly important since he was there during the critical period in the evolution of the requirements.

The MOD also provided a two week course in Washington on the CORAL 66 language and its implementations to members of the HOLWG and its contractors, giving valuable insight into a particularly successful program. As part of this cooperative effort, MOD made available CORAL compilers resident on a computer located at the Royal Signals and Radar Establishment (RSRE, Malvern) in the United Kingdom, but accessible through the ARPANET for the use of US evaluation teams. The ARPANET connection was inaugurated during a visit to RSRE by Queen Elizabeth II. Her Majesty sent a message of greetings to the members of the HOLWG from her net account, EIIR, by pressing a red velvet Royal carriage return. Since the address list was long, it took about 45 seconds for the confirmation to come back, 45 seconds of dead air. Prince Philip remarked, joking respectfully, that it looked like she broke it.

The International Purdue Workshops (IPW) on Industrial Computer Systems, chaired by Professor Ted Williams, was another group that was working in the same area. It is interesting to note how many independent efforts we found, once we had established the program. I believe that the wide publicity of the DoD program enabled us to bring together the talents of those who were working in the various independent communities, to the benefit of all. We contacted Williams on the commendation of a Navy official, who had been his roommate in college. Their subgroup, Long-Term Procedural Language, especially the European branch, LTPL-E, had as a goal the generation of a language much like the proposed DoD HOL. The Commission of the European Communities (CEC) had adopted the concept of a common international industrial language for the European Economic Community (EEC). There was an active relationship between the LTPL-E and the EEC and the HOLWG. LTPL-E was closely analogous to the HOLWG in trying to satisfy the requirements of a number of sovereign countries with diverse application areas. It was at a EEC sponsored LTPL-E meeting that I first met Dr. Jean Ichbiah. He became interested and involved in the program, and the eventual winner of the design competition. In October 1977, the International Purdue Workshops resolved to cooperate fully with the HOLWG program. In November 1977, Christopher Layton, Director, Science and Technology Directorate, CEC, announced at an international conference that the CEC would evaluate the HOLWG efforts for adoption.

The International Standards Organization (ISO) set up a Working Group (Programming Languages for Industrial Processes - TC 97/SC 5/WG 1) on real-time languages at about this time. The early thrust was to establish a standard for real-time FORTRAN, but the Group included an international group of experts in the area, who were invited to participate in the HOLWG effort. They made enormous contributions to the program. The technical body representing the American National Standards Institute (ANSI) in forming WG 1 was the US portion of IPW.

The German and French governments initiated procedures to standardize on existing high order languages, PEARL and LTR respectively, in a move similar to DoD's establishment of approved HOLs in 5000.31. HOLWG involved the people responsible for these languages and they supported us unselfishly, in spite of the prospect of our program competing with theirs.

The Japanese government, through its Ministry of Information Technology and Industry, subsidized a consortium of the computer industry to produce a software production environment, central to which was to be a common programming language, CTL-B. The Comite Consultatif International Telegraphique et Telephonique (CCITT) developed a common high order language for international use in communications. This was done at the same time as the HOLWG effort, and I was told off-line by members of the developing committee that they made a policy not to communicate with the competition. In any case they never answered any of my letters. CHILL was the product of that development.

Just to keep things legal, the US State Department was consulted on all of the HOLWG international contacts and advised on the progress of the program. One has to proceed with due care in Washington. We made it clear that this was an open effort and responded to all correspondence. Several on our mailing list were from behind the Iron Curtain, although we did not get any official queries from the USSR at that time.


The scope of the project went beyond the technical aspects of languages and included direction to the Services and the follow-on of language control and implementation. To start with, we had to lay the groundwork leading to the adoption of a common language for the DoD. First we established the principle that the use of high order language was advantageous and technically feasible (not a trivial selling job in itself since the vast majority of weapons system code was being done in assembly language, or a covering HOL with most of the code in embedded assembly language), and that standardizing on a minimum number of DoD HOLs was a reasonable goal. Given this premise and the several Service language programs, it was prudent to stop all other language work to concentrate on the one program. This is the sort of position that has an overwhelming force of logic and to which everyone must acquiesce. However, this does not mean that they will go out of their way to support it, or indeed that they will not oppose it.

The first administrative action was the issuing of DoD Directive 5000.29 (April 26, 1976) [DoD, 1976b] which specified that "DoD approved high order programming languages will be used to develop Defense systems software unless it is demonstrated that none of the approved HOLs are cost effective or technically practical over the system life cycle...Each DoD approved HOL will be assigned to a designated control agent ...". Thus, the use of high order languages was established and indeed very strongly mandated, since life cycle costs are usually dominated by maintenance where the high order languages have considerable advantage over assembly language. Only approved high order languages were to be used, thereby reducing the proliferation; and further, these languages were to be controlled by central facilities.

DoD Instruction 5000.31 (November 1976) [DoD, 1976c], "Interim List of DoD Approved High Order Programming Languages", designated the "approved" languages called for by 5000.29 and assigned control responsibility. (Note that this was the "interim" list. The declared intention was to reduce to the DoD common language(s).) COBOL and FORTRAN would be controlled by the Office of the Assistant Secretary of Defense (Comptroller) acting with the National Bureau of Standards and the American National Standards Institute, TACPOL by the Army, CMS-2 and SPL/1 by the Navy, and JOVIAL J3 and J73 by the Air Force. All these languages were exactly those nominated by the Services. This is an example of how things work. We wanted to reduce the number of languages from several hundred to a handful. The only way to not argue forever and lose the moment was to let the Services have their way on their own selections unrestrained. The resulting list may have been flawed [Whitaker, 1990], but you go along to get along.

Formalization of these languages was a major step forward and recognized for the first time the corporate commitment of the Department of Defense to provide support for languages in the long term. It stopped the proliferation of languages in that all new systems were to be programmed in one of these languages, but there was no intent that already existing programs be redone or that the projects change if already committed to a language. There were limitations. The languages themselves were selected from the then-present Service inventories and were not modern powerful languages. They were generally deficient in the areas of tools and in availability of compilers. Further, only the seeds of control were established here. It would be some time before we reached the goal a of well-supported and controlled language. The direction of the program was reported to the Military Departments in a 10 May 1976 memo from DDR&E [Currie, 1976] (Figure 7), which also authorized and requested funds for the next phase.

10 MAY 1976 MEMORANDUM FOR THE ASSISTANT SECRETARIES OF THE MILITARY DEPARTMENTS (RESEARCH AND DEVELOPMENT) SUBJECT: DoD High Order Language Program References: a. My memos on Software and DoD Higher Order Programming Language, dated 3 December 1974, 28 January 1975, 2 May 1975 b. DoD Directive "Management of Computer Resources in Major Defense Systems" To reduce the high and rising costs of software programs in weapon systems, the referenced memoranda (a) formed a Software Steering Com- mittee to study the problem; (b) established a High Order Language (HOL) Working Group to provide maximum DoD software commonality; (c) stopped implementation of new high order programming languages; and (d) estab- lished a program to delineate software requirements. The following guidance is provided to clarify the present goals and status of the program, and to indicate appropriate directions for the continuation of this program. o The present goal is to define and implement the minimum number of high order languages that will satisfy the needs of the various DoD communities. o Other work in progress to improve present high order languages can continue, in contrast to work on implementing new high order languages, which is to be discontinued. o The first phase of this program has now been completed with the merging of Service requirements, as provided by your memoranda, into a consolidated DoD set. This document is attached. o The second phase of the program will consist of evaluating (1) various candidate language approaches against these requirements, and (2) the feasibility of modifying the language forms to meet these requirements. o The third phase of this program will consist of a six month effort of $1.8 million to present preliminary specifications for common language selection. o The final phase will involve the implementation of these selections. I request that $300,000 of FY 76/7T funds be made available by each Military Department to address the second phase of this program. This phase consists of a program of four month's duration in which at least two programs will be issued by each Military Department to perform this work. A dozen existing languages, selected by the Services, will be included, and each contractor will study several languages such that each language will be covered by at least two contractors. At the com- pletion of this phase, I request that the Working group and technical representatives of the Military Departments evaluate and recommend, via the Management Steering Committee for Embedded Computer Resources, the minimum language approaches that will satisfy the Defense requirements. Until a set of new high order languages are developed under this pro- gram, language proliferation should be avoided. Accordingly, a set of existing languages will be approved in the interim for new weapon systems as prescribed in DoD Directive. I request that the Military Departments nominate by 1 July 1976 existing high order computer pro- gramming languages for interim approval. Such nomination should include the detailed formal specification of the language, a list of several major current users and a suggested facility for control of the language and its tools. I believe this project is of vital importance in alleviating the current DoD software problem and making possible the management initiatives, technology advances, and fiscal savings which we are looking for in this area. I again call upon your help in keeping this program moving. signed Malcolm R. Currie Attachment: DoD Requirements for High Order Computer Programming Languages cc: DARPA DTACCS ASD(I) ASD(C) ASD(I&L)

Figure 7


The next step, beginning in June 1976, was the evaluation of existing languages against the integrated set of requirements. Ideally, it was expected that the language requirements should be met through selection or modification of existing languages. A number of languages were proposed as potential candidates to meet the common language requirements as stated in the then current Department of Defense Requirements for High Order Computer Programming Languages "TINMAN" [HOLWG,1976]. Subsequently each of these candidate languages was evaluated to determine the degree of compliance with the TINMAN requirements. In addition, a number of other languages, although not full candidates, were examined because they contained special features and technological innovations.

The languages chosen were:

o Widely used, standard languages such as COBOL, FORTRAN, and PL/I.

o Languages specifically designed for DoD embedded computer systems applications such as those which were later chosen for the interim standard list (example: TACPOL, CMS-2, J-73), and those widely used elsewhere for similar applications such as HAL/S and CORAL 66.

o Those languages which best represented modern computer science techniques such as Pascal, ALGOL 68, and SIMULA 67.

o Other languages were also evaluated but in a less formal fashion. They were nominated as "interest items" during the progress of this work, for example, LIS, EUCLID, and RTL-2.

The following languages received formal evaluations: ALGOL 60, ALGOL 68, CMS-2, COBOL, CORAL 66, CS-4, ECL, EUCLID, FORTRAN, HAL/S, JOVIAL J-3B, JOVIAL J-73, LIS, LTR, MORAL, RTL/2, Pascal, PDL/2, PEARL, PL/I, SIMULA 67, SPL/1, TACPOL.

Evaluations were conducted under contracts funded and administered by the Military Departments or by other interested parties such as the British MOD. All candidate languages were evaluated by more than one contractor, and each contractor evaluated several languages, thereby providing a technical crosscheck on the individual evaluations. The general statement of work for all contractors was drawn up by the HOLWG. It specified that for each language requirement, the contractor was to determine the degree of compliance of each of the candidate languages, to comment on the feasibility of modifying the language to bring it into compliance, and to identify features in excess of the requirements. In addition, the statement of work contained a provision for the contractors to comment in detail on the technical feasibility and strength of each requirement, based on their examination of the languages as well as their own corporate experience, to be input for revising the TINMAN. This led to the update of requirements to IRONMAN [HOLWG, 1977b] in January 1977, but the differences between the TINMAN and the IRONMAN were so minor as not to affect the conclusions of the evaluation.

There were also a number of separate formal evaluations made of individual languages by other organizations having unique experience with a particular language, or its designers ("fathers"). In addition, other less formal input included evaluations of requirements different from the TINMAN, examination of special features in certain languages, and briefings and exchange of reports.

Other languages were considered for formal evaluation, but were not included because preliminary examination led one to believe that they would not meet the requirements so were not viable candidates for the purposes of the DoD. One such language was C. At that time DARPA was working with Western Electric/Bell Labs on UNIX, contractually supporting some DARPA contractors and other government facilities using UNIX. It was the evaluation policy to have the owners provide assessments of their own languages, in addition to the contracted evaluations, so HOLWG took advantage of this connection between DARPA and Bell Labs to request their cooperation. When Bell Labs were invited to evaluate C against the DoD requirements, they said that there was no chance of C meeting the requirements of readability, safety, etc., for which we were striving, and that it should not even be on the list of evaluated languages. We recognized the truth in their observation and honored their request.

In January 1977 a report on the consolidation of evaluations was prepared by a subcommittee chaired by Serafino Amorosa, using in-house personnel, the contractors participating in the evaluation, and special consultants [HOLWG, 1977a]. This publication included the complete text of each evaluation report and a resolution of any conflicting reports from contractors evaluating the same language. It provided a summary of the technical evaluations and an assessment of the applicability of each language to the requirements. There was a determination whether any existing candidate so nearly met the requirements as to have it chosen intact, or with simple modifications, and thereby forego a major design phase in the program. The results from the Evaluation Subcommittee were:

o Among all the languages considered, none was found that satisfied the requirements so well that it could be adopted as the common language.

o All evaluators felt that the development of a single language satisfying the requirements was a desirable goal.

o The consensus of the evaluators was that it would be possible to produce a language within the current state-of-the-art meeting essentially all the requirements.

o Almost all the evaluators felt that the process of designing a language to satisfy all the requirements should start from some carefully chosen base language.

o Without exception, the following languages were found by the evaluators to be inappropriate to serve as base languages for a development of the common language: FORTRAN, COBOL, TACPOL, CMS-2, JOVIAL J-73, JOVIAL J-3B, SIMULA 67, ALGOL 60, and CORAL 66.

o Proposals should be solicited from appropriate language designers for modification efforts using any of the languages, Pascal, PL/I, or ALGOL 68 as a base language from which to start. These efforts should be directed toward the production of a language that satisfied the DoD set of language requirements for embedded computer applications.

o At some appropriate time, a choice should be made among these design efforts to determine which are most worthy of being continued to completion.

The definition of a base language which evolved during this procedure called for one which was familiar to the community so that a number of contractors could use it as a starting point and provide an audit trail, which could be used by government personnel to compare between contractors. For instance, PEARL or HAL/S could be considered modifications in the PL/I family towards the desired real-time language. This definition did not imply that those deemed inappropriate as a base language were not perfectly adequate for their operational use at the time. Indeed, the presence of COBOL and FORTRAN, to which the DoD has been committed on a long term basis, belied that implication. Nevertheless, these languages would not have been good starting points for a new language since they had basic inconsistencies with the requirements, or had been superseded by more appropriate starting points.

"Base" must be distinguished from languages influencing Ada. There was impact not just in language design but in the requirements:

FORTRAN was significant because that was the successful language - we are still apologizing for FORTRAN features not in Ada (intrinsic math functions (e.g., SQRT, SIN, etc.), interpretive I/O (i.e., with dynamic formatting)), no matter how proper the exclusion;

COBOL pioneered validation - made sure we did not allow the subsets that in 1976 made COBOL systems difficult to validate and compare (may be right for COBOL but not for the purposes of Ada) - data handling, and readability;

JOVIAL and CORAL were languages of major military users whose experiences made considerable contribution to the requirements;

Pascal contributed mostly its syntactic form.

The unanimous recommendations of the evaluation committee, adopted unanimously by the HOLWG were:

o That none of the evaluated languages met the requirements to such an extent as to be selected with little or no modifications for a DoD-wide standard;

o That it appeared feasible within the state-of-the-art to construct a single language to meet essentially all of the requirements;

o That the construction of such a language would most likely be done by modification (albeit substantial) of an existing language. The approaches recommended as a basis for further development were the language families of PL/I, Pascal, and ALGOL-68.

A sidelight on the evaluation was the form of the distributed report. The data consisted of 2600 pages of individual and group reports. They were typed and handwritten, many were on metric sized paper. I felt a responsibility to make sure that everybody involved had a complete record; that was the way the program was run. Conventional methods were impossible; we had no staff or secretarial help for a normal retyping and publication. I took what I know to be an innovative step (since I had to continue to fight for this two years later). I had the whole report put directly on microfiche. (While this may not be the favorite medium in some homes, it is now the media used for most secondary distribution of Government technical documentation. Fiche was the only feasible medium at the time. After 1979, essentially everything was electronic.) I reproduced a sufficient number of copies for the HOLWG distribution and the masters went to the Defense Documentation Center (DDC, now DTIC) for outside requests as [HOLWG, 1977a]. This was bending the system and it took some talking to bring it off, but I thought it was a real breakthrough. The later Phase I and Phase II design evaluations, up to 5600 pages, were also produced only in fiche. There was never what one could call a hard copy document.

After formal adoption of the Program Management Plan by the Management Steering Committee for Embedded Computer Resources, the recommendations of the evaluation committee, the IRONMAN requirements, and the Statement of Work for the language design were forwarded to the MSC-ECS for coordination. This coordination was signed at an MSC-ECS meeting on 31 January 1977.


The next phase of the program was the award of contracts for the "language modification and preliminary design". Alternatively this might be considered an elaborate feasibility proof. The design was to be informal but fairly complete, and to consider the cost and nature of implementations. Although we realized that the product was to be a new language, we got in the habit of using the term "language modification", referring to the plan to start from an existing base. This preliminary design was done from the IRONMAN Revised requirements and was to draw upon the previous work done on evaluations. The syntax was to be fully specified with complete, but informal, semantics. An analysis of the feasibility and cost of implementation were to be produced.

The driving concern of the HOLWG was to assure that the design was guided by a responsible principle investigator, and to preclude "design by committee". On the other hand, picking a single contractor to do the job and trusting to luck would have been imprudent. The procurement was through multiple competitive contracts, with the best products to be selected for continuation to full rigorous definition and developmental implementation. These were contracts with three phases and options to down select (drop competitors) at each break after evaluation and public review. This procurement technique was advocated by Bill Carlson, modeled on an architectural competition.

Monies for these contracts were only from funds of the Services. It is important to make the point that this was a joint program of the Services, not a DARPA program. Although I was working at DARPA and was strongly supported by the Director, George Heilmeier, we were working for DDR&E on this project. DARPA was represented on the HOLWG as a DoD Agency, but there was no DARPA contract money involved during the time I was there. However, DARPA did provide personnel and the major support of the ARPANET. This project was run almost entirely over the net, perhaps the first independent project to do so.

DARPA served as a funnel to collect the monies provided by the Services for these contracts into one pot for administrative convenience. Service funds were transferred on Military Interagency Purchase Requests (MIPRed) to DARPA which issued ARPA Order 3341 to the Defense Supply Service-Washington (DSS-W), the procuring agent, which actually signed contracts and dispersed payments. The individual at DARPA who was actually in charge of all further HOLWG contractual activities was Bill Carlson of the Information Processing Technology Office (IPTO). He was formerly an officer in the Air Force computing center in the Pentagon, so had wide experience with military computing. At this time, he was responsible for a large DARPA university research program, giving him unequaled access to the academic computing community. He was responsible for most of the innovation in the contracting process and for the daily management of the contracts. He particularly represented the computer science and non-military communities to the HOLWG, and his public relations efforts made sure that they were welcomed in the process.

The Statement of Work (SOW) was approved in March, 1977, and a Request for Proposal (RFP), Solicitation No. MDA903 77 R 0082, was released in April, 1977. The DSS-W buyer was Stephan R. Bachhuber. This effort was unusual in that foreign bidders were actively encouraged, and there were several. The quality of these bids was exceptional. I have evaluated thousands in my career, and these had the highest quality, as a group, of any that I have experienced. In fact, I was approached by several well-known firms that told me that in the normal course of business they would have bid, but that this procurement was too important and that others could do a better job. I had never, before or since, heard of such a recommendation for a government program.

The proposals were evaluated by government technical teams, and in August 1977 four contracts were awarded to produce competitive prototypes of the common high order language. There were fourteen bids (some teaming), both U.S. and foreign. The four successful contractors were Cii-Honeywell Bull, Intermetrics, SofTech, and SRI-International.

While different approaches were offered, all four winning contractors proposed to start from Pascal as a base. This restricted the products in form, but would make it easier to compare the results. Any of the three different base languages was acceptable, so the outcome was coincidental. It should be noted that the requirements against which the language was being designed were not those driving Pascal and the result was not be expected to be a superset of Pascal.

The contracts had the normal time constraints. While the project had no hard deadlines, contract administration demands certain adherence to schedules when they are laid out. The philosophy was that we had to do the job right; there was no timetable imposed from above. We did feel an urgency to get the job done while the time was right. We set our own internal schedule and this came out to be very accurate. We scheduled the date of completion of competition and selection of the winning design two years in advance, before the design contracts were let, and met it to with in two days.

During this phase, an advisory committee of military users was established. This advisory committee, with experience from their particular applications areas, helped evaluate those difficult to quantify, but tangible, attributes such as readability, writability, and acceptability by the military users.

The products of Phase I, the preliminary designs, were received in February 1978. The considerable interest that this project generated in the outside community made it possible to seek technical input for the evaluation of these designs from the industrial and academic communities worldwide. Eighty volunteer analysis teams were formed and produced extensive technical analysis of the designs. These teams represented not only language expertise but also the eventual users of the language. In order to make the evaluations as fair as possible, each report was given a color designation; green for Cii, red for Intermetrics, blue for SofTech, and yellow for SRI. There was no other significance to the colors. Of course, this was no guarantee of anonymity and there was no legal requirement to hide the sources, but it seemed like a good idea at the time. This technique has been used elsewhere since. If one were very familiar with the style of a design group, their work would be detectable; however, the sources were concealed from most of the evaluators.

The period available for design was short, but the designs were only preliminary and the purpose of the analyses was to determine which should be continued to completion. On the basis of these analyses, Cii-Honeywell Bull, and Intermetrics were selected to continue and resume work in April 1978, and a Memo [Perry, 1978] (Figure 8) continuing the program was issued by DDR&E. All the evaluation materials were again microfiched and distributed to all participants [HOLWG, 1978a].

As a result of both the designs and the analyses, the requirements were updated in June 1978 to a STEELMAN version [HOLWG, 1978b]. Since this was logically expected to be the final set of requirements, some care was taken to clean it up, and particularly to remove apparent misunderstandings and discrepancies which surfaced as the result of the actual design of the four languages. The rigorous review of the languages by the analysis teams in the context of the requirements was a further exceptional test. It was the specific goal of this revision to assure that the level of the requirements was properly functional, neither too specific nor too general. Some portions of the requirements were deleted or modified as a result of these reviews, and the parallel processing requirements were generalized. The document remains a set of realistic requirements for large-scale systems. As befits the maturity of the project, this version is more direct. Although much of the discussion of previous versions is still valid, it is not repeated here. STEELMAN reads much more like a specification, but it still allows significant flexibility in design decisions. It states specific criteria for a language, but does not describe a language. Figure 9 reproduces the section on syntax requirements.

RESEARCH AND ENGINEERING April 11, 1978 MEMORANDUM FOR ASSISTANT SECRETARY OF THE ARMY (RESEARCH, DEVELOPMENT AND ACQUISITION) ASSISTANT SECRETARY OF THE NAVY (RESEARCH, ENGINEERING AND SYSTEMS) ASSISTANT SECRETARY OF THE AIR FORCE (RESEARCH, DEVELOPMENT AND LOGISTICS) DIRECTOR, DEFENSE ADVANCED RESEARCH PROJECTS AGENCY DIRECTOR, DEFENSE COMMUNICATIONS AGENCY SUBJECT: DoD High Order Language Commonality Program The DoD program to produce a common high order computer programming language has passed a major milestone. Four competitive prototype designs were delivered to the government on February 15, 1978. Detailed analysis and comparisons of these designs were performed by 80 defense and civil organizations. On the basis of these analyses and data, and with the technical representatives of the United Kingdom, France, and the Federal Republic of Germany, the High Order Language Working Group (HOLWG) selected two designs to be continued to full language defi- nition. While either of these could result in a successful common language design, the continued competition was regarded as a very impor- tant factor in the program. The two designs exhibit significantly different approaches and act so as to reduce the criticality of undis- covered technical risk. In expectation of success of the final design phase, the High Order Language Working Group is preparing a detailed plan for the introduction and support of the language, the rigorous control of the language both inside and outside the DoD, and the implications of its use in the NATO environment. I commend to your attention the drafting and coordination of this plan. Several independent economic analyses have promised large benefit from the adoption of this modern common language. I solicit your support to make this a reality. William J. Perry

Figure 8

2.  General Syntax

2A. Character Set. The full set of character graphics that may be used in source problems shall be given in the language definition. Every source program shall also have a representation that uses only the following 55 character subset of the ASClI graphics:

%&'()*+,-./:;<=>? 0123456789 ABCDEFGHIJKLMNOPQRSTUVWXYZ

Each additional graphic (i.e., one in the full set but not in the 55 character set) may be replaced by a sequence of (one or more) characters from the 55 character set without altering the semantics of the program. The replacement sequence shall be specified in the language definition.

2S. Grammar. The language should have a simple, uniform, and easily parsed grammar and lexical structure. The language shall have free form syntax and should use familiar notations where such use does not conflict with other goals.

2C. Syntactic Extensions. The user shall not be able to modify the source language syntax. In particular the user shall not be able to introduce new precedence rules or to define new syntactic forms.

2D. Other Syntactic Issues. Multiple occurrences of a language defined symbol appearing in the same context shall not have essentially different meanings. Lexical units (i.e., identifiers, reserved words, single and multicharacter symbols, numeric and string literals, and comments) may not cross line boundaries of a source program. All key word forms that contain declarations or statements shall be bracketed (i.e., shall have a closing as well as an opening key word). Programs may not contain unmatched brackets of any kind.

2E. Mnemonic identifiers. Mnemonically significant identifiers shall be allowed. There shall be a break character for use within identifiers. The language and its translators shall not permit identifiers or reserved words to be abbreviated. [Note that this does not preclude reserved words that are abbreviations of natural language words.]

2F. Reserved Words. The only reserved words shall be those that introduce special syntactic forms (such as control structures and declarations) or that are otherwise used as delimiters. Words that may be replaced by identifiers, shall not be reserved (e.g., names of functions, types, constants, and variables shall not be reserved). All reserved words shall be listed in the language definition.

2G. Numeric Literals. There shall be built-in decimal literals. There shall be no implicit truncation or rounding of integer and fixed point literals.

2H. String Literals. There shall be a built-in facility for fixed length string literals. String literals shall be interpreted as one-dimensional character arrays.

2I. Comments. The language shall permit comments that are introduced by a special (one or two character) symbol and terminated by the next line boundary of the source program.

Figure 9. Example from STEELMAN - Technical Requirements

STEELMAN criteria were not for an abstract, ideal language, but one dealing with operational realities. Restrictions on character sets reflect the distribution of input devices across all communities at that time. The goto remained, although restricted, to ensure acceptability in those communities where it was still widely used. (In fact, an argument could be made that there are situations in which the goto is the preferred solution, albeit, very few. It is powerful and it can be easily detected and controlled by management, thereby reducing the dangers of misuse. Fortunately, the user demand relieved us of having to make a decision in this one case.)

Not as part of the competition, but for general technical input, there were two other submissions around this time. A group at Carnegie-Mellon University which had long been supported by DARPA in the compiler field submitted a conceptual design they named "TARTAN" [Shaw, 1978] (another color?). A group from IBM provided a study of what would be the result of cutting and filling PL/I to meet the DoD requirements. Their approach was to reduce the base PL/I by 75% and supplement it by 15%.


Two language designs, those of Cii and Intermetrics (Green and Red), were continued through the second phase of the contract. A full language specification was derived from the informal specification delivered by each in Phase I. In addition to the specification, the contractor produced a "Rationale" and programs of solutions to several applications programming problems. Finally, the contractors were to produce a test translator to test and evaluate the language in actual use. In the end the translator products were insufficiently complete, and perhaps too slow, to provide any input to the evaluation process, contrary to our early expectations.

An elaborate evaluation of the products, which the two contenders delivered on 15 March 1979, was more exhaustive that the earlier semi-final shoot out, since the products were more complete. Again, a number of teams representing various interests, applications, and organizations, analyzed reports from many reviewers. (This raw data was documented on microfiche produced at Eglin AFB after I was transferred there [HOLWG, 1980a].) This time there was an opportunity to question the design teams personally in great depth at a large evaluation meeting held in April 1979 in the Washington, DC area.

On 2 May 1979, a meeting of the HOLWG, including the representatives of the United Kingdom, France, and Germany, selected the design of Cii-Honeywell Bull, code-named "Green" during the competition. Before the last mail that afternoon I reproduced and sent 3000 green postcards announcing "Green is Ada!" The formal announcement to the world was the Duncan letter of 14 May 1979 [Duncan, 1978a] (Figure 10). Within a month I was reassigned to be Technical Director for Digital Applications at the Air Force Armament Laboratory at Eglin AFB, Florida. David Fisher became a government employee and took over my previous job with DDR&E, chairing the HOLWG until he and Carlson left in November 1980, and the HOLWG was superseded by the Ada Joint Program Office.

MAY 14 1979 The Department of Defense High Order Language Commonality program began in 1975 with the goal of establishing a single high order computer programming language appropriate for DoD embedded computer systems. This effort has been characterized by extensive coopera- tion with the European Community and NATO countries have been involved in every aspect of the work. The requirements have been distributed worldwide for comment through the military and civil communities, producing successively more refined versions. Formal evaluations were performed on dozens of existing languages conclud- ing that a single language meeting these requirements was both feasible and desirable. Such a language has now been developed. I wish to encourage your support and participation in this effort, and I submit the design of this language for your review and comment. Such comments and detailed justified change proposals should be for- warded to HOLWG, DARPA, 1400 Wilson Boulevard, Arlington, VA 22209 by 30 November 1979. The language, as amended by such response, will become a Defense standard in early 1980. Before that, changes will be made; after that, we expect that change will be minimal. Beginning in May 1979, the effort will concentrate on the technical test and evaluation of the language, development of compilers and programming tools, and a capability for controlling the language and validating compilers. The requirements and expectations for the environment and the control of the language are being addressed in a series of documents already available to which comment is also invited. We intend that Government-funded compilers and tools will be widely and cheaply available to help promote use of the language. Ada has been chosen as the name for the common language, honoring Ada Augusta, Lady Lovelace, the daughter of the poet, Lord Byron, and Babbage's programmer. C W Duncan Jr DEPUTY

Figure 10

The Reference Manual and the Rationale were published as the June 1979 issue of ACM SIGPLAN Notices (Volume 14, Number 6, June 1979, Parts A & B) [Ada, 1979a; 1979b], in order to get wide exposure for public comment during the early months of testing. This version was known as "Preliminary Ada", to be refined as the result of comments and testing. SIGPLAN had been kept informed during the project [Whitaker, 1977] and Paul Abrahams of SIGPLAN suggested that the Manual be published by SIGPLAN, as had been done for other developments. I contracted with their printer for 3000 additional copies for the HOLWG distribution. I was fairly proud of this connection since not only did we get very wide distribution in the computer science community, but I was able to get the additional copies from the printer at just over $1 a copy. This resulted in an enormous saving over their being printed by the government. I took the precaution of obtaining proper permission to bypass use of the Government Printing Office, as required by Congress for such actions.


"Ada" was chosen as the name for the common language. This honors Ada Augusta, the Countess of Lovelace, the daughter of the poet Lord Byron, and Babbage's "programmer".

In spite of rumor, DOD-1 was never a candidate for the name, and was never used by the HOLWG in any formal context. It was immediately recognized that we were looking for something that could have wide acceptance and that the name should not have a parochial flavor. However, we did sometimes jokingly refer to the whole project as DOD-1, and we used that as the password of the common HOLWG computer account, until we picked "Ada".

It has been reported that Jack Cooper suggested the name "Ada" while sitting with other members of the HOLWG in a sidewalk cafe in Paris in the summer of 1978. I cannot testify to the accuracy of the milieu since I was not in Paris at the time. I do remember that we had long struggled with the question of an appropriate name. A number of suggestions were brought up with no result. This indecision became embarrassing since the selection of a name was a scheduled milestone in the program, and the only one that we missed by more than a few days - we missed this one by over a year!

After the suggestion was made by Cooper at a HOLWG meeting, there was still a fair amount of divergence. Amorosa brought up the book "Faster than Thought" [Bowden, 1953] from which we all learned about Lady Lovelace. (Other biographies [Moore, 1977; Morrison, 1961; Stein, 1985] dwell more on personal aspects, and Baroness Wentworth's own words [Wentworth, 1938] correct Bowden's misrepresentations of her.) Eventually there was a general consensus. Still, it seemed presumptuous to appropriate somebody's name; and even the dead should have some rights. So we took what might be a unique turn. We wrote to the heir of Lady Lovelace and asked permission to use the name "Ada". Phil Wetherall, our UK representative, wrote the letter and there followed this exchange which authorized use of the name [Wetherall, 1978; Lytton, 1978; Duncan, 1978b] (Figures 11-13):

          Procurement Executive, Ministry of Defence


          St. Andrews Road GREAT MALVERN WORCS WR14 3PS
          Telex 339747-8 Telephone MALVERN (06845) 2733 ext

                                                      10th October 1978

The Earl of Lytton

Dear Lord Lytton

For some years now, the United States Department of Defense has been engaged
in a project to define a new computer programming language for use in weapon
systems, as opposed to scientific or business and commercial applications.
This effort will shortly reach its climax with the publication of the language
design in April 1979.  Until now, the language has not had a distinctive name,
and the steering committee of the project has been open to suggestions for such
a name.  The only serious contender, and one the committee would like to adopt,
is Ada - in honour of Countess Lovelace.  She had the distinction of being
amongst the first to appreciate the significance of Charles Babbage's work on
the Analytic Engine (ie the forerunner of modern computers) and she was a great
presenter of Babbage's ideas.  Indeed, she could be called the first programmer.

As the representative from the Ministry of Defence to the project, I have been
tasked with seeking the concurrence of Lady Lovelace's family to this
suggestion.  We gather that your mother, 16th Baroness Wentworth, was
extremely interested in her grandmother, and so I am writing to you in the
first instance to seek your approval of this suggestion.  If you believe that
other members of the family, for example Lord Lovelace, should also be
approached, I will do so with alacrity, but it has been suggested that your
branch of the family are the "heirs" to the computing influence of Lady
Lovelace as a result of Lady Wentworth's interest.

In the book "Faster than Thought" by Dr Bowden (Pitman 1953) Lady Wentworth
is recorded as possessing many of Lady Lovelace's letters.  This new
programming language is likely to have a considerable impact on the
community of those concerned with computing, and could well sponsor a
revival of interest in Lady Lovelace if the name Ada is chosen.  I have been
asked to discover whether these letters are still in your family's possession
and, if not, where they could be located.

If you would like more information on the project, I shall be only too happy
to oblige.  Fortunately this is not an area in which secrecy is a matter of

Yours sincerely

P R Wetherall
Principal Scientific Officer
Computer Applications Division

Figure 11


18 October 1978
                                               Keeper Knight's
                                                   Pound Hill
                                                       -Sussex RH10 3PB

Dear Mr. Wetherall,

          Your letter of 10 October comes to the right person and this is
now my address.
Ada was Byron's daughter.
She married William King, the first Earl of Lovelace as his first wife.
William and Ada begat  (Ralph - 2nd Earl
                       (Anne - married W. S. Blunt.  (Wilfrid)
Ralph's line died out but he made a will trust in favor of his sister
Anne's daughter and her descendants.  He wrote a book called "Astarte" and
made a collection of papers called the "Lovelace Papers".  He also
resuscitated the older title of Wentworth which can be taken by daughters
in the absence of sons.  At his death his title of Lovelace went to the son
of his father out of a second wife: the title of Wentworth went to his
daughter who died childless: on her death the Wentworth Barony went to his
sister Anne for a few weeks before her death.

Anne & Wilfrid begat Judith who married Neville Lytton later 3rd Earl of
Lytton and became 16 Baroness Wentworth on the death of her mother Anne.
Neville became 3rd Earl after the dissolution of his first marriage to
Judith.  Judith & Neville begat Anthony (myself) and 2 girls (both childless).
On the death of Neville, Anthony became 4th Earl of Lytton;
On the death of Judith Anthony became 17th Baron Wentworth.  Anthony
married Clare Palmar and begat
                     John (Viscount Knebworth)
                     Roland (The Hon. R. Lytton)    -  all young
                     Caroline Lytton                   all unmarried as yet
                     Lucy Lytton
                     Sarah Lytton

From this you will see that I am directly descended from Ada and the present
Earl of Lovelace is not.  We have a common ancestor in William but he is out
of the 2nd wife, I am out of the first.
Doris Langley Moore has written a book on Ada.  Professor Bowden's book
"Faster Than Thought" pays a fair tribute to Ada but suggests something like
an acclaim on the part of Judith whose mathematical acumen certainly
did not enable her to breed Arabian horses that won races in world
record times from 1/2 mile to 300 miles.  I do not think you will find
an Arabian horse among the names in any Epson Derby and its equivalent
The Science Museum gave prominence to Ada in their Babbage
Exhibit - several years ago.  I inherited the Lovelace papers (including
some Ada letters) and they are now deposited at the Bodlean Oxford
for students to consult - The deposit is in the name of my son John.
I think we shall all be happy if you name your Radar Language "Ada"
in honour of Ada Lovelace.  By chance the name already lies at the
heart of RADAR.

                                  Yours Sincerely,


Figure 12

The Earl of Lytton Keeper Knight's Pound Hill Crawley Sussex RH10 3PB England Dear Lord Lytton: The United States Department of Defense would like to express its thanks to you and your family for permission to use the name of your ancestor in connection with a new common computer programming language for military systems. Ada Augusta Byron, Lady Lovelace, was a woman of exceptional ability and wit. Her pioneering work in describing the procedures through which a computer solves a useful problem, a discipline we now call programming, is still fresh after more than a century. We believe that she would have appreciated this new language for computer programmers designed specifically for precision and clarity. The US DoD and the British Ministry of Defence have been cooperating in producing the language for programming military computer systems. After an extensive requirements and study phase, several candidate designs were produced and, on 2 May 1979, a selection was made between competing definitions. We now have a language which we can designate "Ada". The next few months will be a period of testing and polishing of the definition. In 1980 we will begin to use Ada in the development of large military systems. There appears to be a pressing need for such an advanced programming language outside the Defense community, and this project has received a great deal of attention from industry. It is our expectation that Ada and the associated programming facilities will see very widespread international use. We hope that it will serve as a fitting reminder of a lady of great talent and foresight. Sincerely, C. W. Duncan, Jr. DEPUTY

Figure 13


The next step in the process was an evaluation of the definition with public comment and actual experience in coding with it. Languages can take many years to mature because they are exercised by different users serially. The HOLWG attempted to speed up this process for Ada. This Test and Evaluation phase was intended to get many different organizations rewriting their particular applications [HOLWG, 1979b], which both exercised the language and exposed it to potential users. Note that this was a test of the language, not of implementations, which is more often the case in language evaluations for project use.

This exercise was conducted in the HOLWG tradition; a wide request for coding input, a large public meeting to present results, and solicitation (by the Deputy Secretary of Defense) of public comments on the Preliminary Ada document. An interpreter was made available over the ARPANET to anyone requesting access. The goal was to let users reprogram their applications in Ada to verify that the language was sufficiently powerful and usable. (I did a missile inertial guidance program at Eglin.) Since we were serious about exercising the language knowledgeably, training was provided for the participants. In June and July 1979, five one-week courses were held at Service institutions, Georgia Tech, and at the National Physical Laboratory in England. The instructors were from the language design team, and included: Jean Ichbiah, Robert Firth, and John Barnes.

The experiences and code results were reported at a meeting, 23-26 October 1979, in Boston at the Museum of Science [HOLWG, 1979c]. This open location was arranged by Carlson to encourage people other than just DoD contractors to attend.


The third scheduled phase of the language design was a polishing of the definition as a result of the test and evaluation. Cii Honeywell-Bull was funded to revise "Preliminary Ada" and provide a final Language Reference Manual to be a military standard (MIL-STD). The process was supported by a group of technical experts known as the "Distinguished Reviewers", established and chaired by Carlson. Formal comments were solicited and processed electronically. Hundreds of papers were prepared on individual questions. On 24 July 1980 Cii delivered the revised design. On 25 August, the HOLWG voted to accept the product [Cohen, 1981].

Was it really as open a program as we said? The process seemed to be enormous and commenters sometimes felt overwhelmed. I myself submitted a number of revision comments from afar, as a simple user no longer involved in the contract. I thought to myself, as people will, that my insightful suggestions had mostly been rejected. I then did a quantitative audit and found that more than 80% of my suggestions had been incorporated in the final product.

In December 1980 there was an ACM SIGPLAN Conference on Ada in Boston [ACM, 1980]. This was the first technical conference on Ada not organized nor run by the DoD. While the meeting was taking place, Mark Grove, Chairman of the MSC-ECR, was in Washington settling final details on the MIL-STD. He managed to arrange that the MIL-STD be given the number 1815, the year of Ada's birth, and to get it approved on 10 December, the day of her birth. He could also announce the formation of the Ada Joint Program Office (AJPO) to supersede the HOLWG and maintain the language. Here ended the initial language development part of the project.


There is a very large payoff to the DoD for being able to update hardware without having to rewrite the software. Further, there is a large payoff for being able to take modules of code generated on one project for use on another. Further, one would like to be able to use a common software base over a variety of machines and architectures within a single system. An identical functional capability may be required in a number of physical implementations of various sizes, speeds, and powers. These may require running the same code on a large scientific computer or a distributed system of microprocessors. The effort therefore emphasized two key factors of transportability: technical capability and control of implementations.

The technical capability for transportability and reuse requires that the source code be as machine independent as possible in items such as word length, the precision of variables, etc., and be able to specify representations and hardware dependencies in an encapsulated form. This was the requirement and Ada satisfied it. The effort was keyed to a hard definition of the language and validation of compilers to assure that a program written for one project or machine would be transportable in a realistic fashion. Control of the language was one of the most important aspects of this program and was planned for early on. Primarily, it meant maintenance of the final language specification including answering questions, making necessary decisions, distributing information as required, etc., and the certification of compilers. No compiler can be validated that does not respond appropriately to all legal programs, within our ability to test. Further, compilers must be checked to assure that they do not exceed the scope of the language. This idea of checking for features beyond the language was radical when first proposed, but it was vital to the overall purpose of the project. In some sense, it is not a matter of the language, but use of the language. Herein lies the difference between a "standard" and a "common" language. Standards are sometimes taken as a starting point from which deviations and "enhancements" proceed. If it is to be common, transportability and reuse depend on the language being the same everywhere. Here also is the origin of the controversial "no subsets/no supersets" rule.

I made it a principle that there were to be no subset and no supersets compilers for Ada. This was really not much of a problem in selling to the Services and the users. However, it was a continuous battle with the implementers, primarily academic. The argument was that they could make a cheap subset compiler to get started. This usually meant minor syntactic modifications to a Pascal compiler. Few of these subset advocates ever intended to go to a complete compiler. Some more serious proposals were made to define a standard subset of the language, in the manner of FORTRAN or COBOL. Those serious discussions failed to produce a proposal since everyone had a different idea of what features to suspend. Attacks on this policy continued long after I left the HOLWG and I periodically had to strengthen the resolve of my successors.

At the other end, there were those who insisted that there should be only one compiler, mandated by the government for all Ada users, or one per Service. There were those who demanded that all compilers use a common database for compiler syntax and semantics, or have a common intermediate language or internal interface. We had to confront this monolithic stance through a technical capability to assure that compilers from different sources would not generate dialects.

In October 1979, soon after the language was selected, a contract was let to SofTech to provide a suite of validation test programs. SofTech was a Phase I contender (Blue) and, while they were unsuccessful, their work showed an attention to detail that was ideal for this effort. John Goodenough led this program, for which he was required to distance himself from any SofTech Ada compiler contracts. The testers could not be developers.

The product of the contract was the Ada Compiler Validation Capability (ACVC) [Goodenough, 1980], a set of test programs, now numbering several thousand, which try the limits of the language. To validate, a compiler must not fail any applicable test. Standards facilities in the United States and abroad have been authorized to certify with this set of tests. It was recognized during the language development that testing, although never complete, was the only technically feasible method to assure compliance to the full and exact Ada standard. The test suite has grown through the years and since the purpose is to make sure a compiler is Ada, there was no leniency towards compilers that may have passed a previous version. When new tests are approved, compilers must revalidate, otherwise the validations expire. This is a significant burden on suppliers, but it is necessary to maintain the transportability and reuse goals, and is a consequence of the expectation that Ada must support high-integrity systems.

The idea of trademarking the name as a control on implementations was initiated while I was there, but not carried through until later. The use of the trademarked name, "Ada", was restricted to validated implementations. This gave very powerful psychological protection during the start-up when the concept of strict control was still vulnerable. In 1987, when the community had matured, AJPO relinquished the trademark protection.

While we set out to make a DoD common language, not necessarily a civil standard, we did work closely with the ISO PLIP Working Group (WG 1) so as to prepare for standardization as a method of control. I presented the HOLWG program to ISO SC 5 at the Turin meeting in the fall of 1978 to help prepare the way. The thought was to raise the control of the language to the highest level possible, out of the DoD, out of the United States, in order to make it harder for even a very large project to undermine the stability of the definition by propagating dialects, as had been the case with previous military languages.

In this connection, we needed to assure the world that this was truly an available commercial reality, and not something that the DoD was going to keep to itself. The openness during development contributed to this, but there were other pitfalls. Coincidentally, I was the US technical representative for computers in the export control arena where I sold the policy that there could be no control on languages that were subject to International Standardization, like FORTRAN, COBOL, or Ada; this cut off one possible disastrous scenario. Of course, this did not cover programs written in those languages.


Upon the completion of the development project in late 1980, Fisher and Carlson left, and the loose organization of the HOLWG was superseded by a DoD Ada Joint Program Office (AJPO), chartered 12 December 1980. Mark Grove was Chairman of the MSC-ECR and shepherded this through, along with Larry Druffel, who became the initial Director of the AJPO. This office managed the standardization processes with ANSI and ISO. One consequence of the transition was that this new organization was exclusively involved in the control and support of Ada, not in the overall DoD software problem. While initially proposed and budgeted to generate tools and applications libraries, the AJPO abandoned that role and concerned itself mainly with the control and with DoD policies.

The chief task was to continue to polish the language definition in connection with an ANSI canvass process leading to ANSI, and eventually ISO, standardization. A major challenge was to maintain close international involvement in the development and assure that national and international standards did not differ (a real possibility in the standards world of that time, but much less likely today). Through the usual Ada open process, the definition was refined to MIL-STD 1815A, and this was endorsed by ANSI in February 1983 [Ada, 1983], with updated Rationale [Ichbiah, 1987]. Ada was endorsed as ISO Standard 8652 in 1987.

A vital consideration in language control is that there must be some place to address questions and resolve ambiguities. A normal ANSI committee development has the possibility of using the committee itself as the ultimate judge. A process had to be devised for Ada. Ada is the responsibility of ANSI through an Ada Board advising AJPO, and of ISO through a Working Group, now designated TC 97/SC 22/WG 9. In the initial organization both of these groups were chaired by the then Director of the AJPO, Robert F. Mathis. At the time, this was a vital necessity for smooth coordination, forestalling possible divergences between the national and international standard. (When a later Director of the AJPO abdicated as WG 9 Convener, Mathis picked it up again and preserved this vital continuity.) There were elaborate organizational minutia and formal reporting and approval, but in essence, comments and questions on the language were resolved in summary papers, called Ada Commentaries, by the Ada Rapporteur Group (formally the Language Maintenance Committee), chaired by John Goodenough. All queries are recorded and considered. The resolution of issues are available from a number of sources and were a starting point for the language update.

Another possible path to control involved a formal definition of Ada. There are those in the computer science community who advocate a formal definition as the only way to specify a language. While this position is contested, formal definitions have been valuable in resolving difficult questions of interpretation. During the language development, the French (INRIA) began a formal definition based on denotational semantics [Donzeau-Gouge, 1979, 1980]. This effort was particularly noteworthy in that it used Ada as the metalanguage which made it much more readable than most formal definitions. In 1979, RADC redirected an effort that had been supporting to an operational definition of Preliminary Ada based on SEMANOL [Berning, 1980]. The NYU Ada/Ed interpreter was also advocated as an operational definition [Dewar, 1983]. Some Europeans were particularly interested in pushing a formal definition and proposed that such be the only basis for an ISO standard. The EEC supported research efforts in this area, beginning with the Danish work [Bjorner, 1980], and culminating in a large project completed in 1987 [Botta, 1987; Nielsen, 1987; Giovini, 1987]. While these efforts have illuminated a number of aspects of the language and have led to clarifications, the authoritative definition remains the natural language text of the Language Reference Manual.

Periodic review is required by ANSI and ISO for standards. Every five years a language standard must be revised or reaffirmed. Historically this has meant a revision every ten years. In 1988 the Ada Board reaffirmed 1815A to ANSI and began a revision process, working on an update for about 1993, prudently called Ada 9X. My only connection is that Christine Anderson, who is running the revision project, was at the Air Force Armament Lab at Eglin AFB at the time. While she did not join the Lab until after I left, I would like to think that my being there started a chain of events that led to her selection for 9X.


Since the purpose of the program was the improvement of DoD software, there were things beyond the language to be done, still within the scope of the HOLWG. Aspects of the development environment were studied with procedures similar to that for the language requirements. A document was prepared addressing those features of controlled support which would be required for the optimal utilization of the language. These were requirements in a different sense from the rigorous complete set of the STEELMAN, but the iteration methodology was also used here. An initial version, SANDMAN, drafted in January 1978, turned out to be entirely unsatisfactory and was never distributed. It did serve to show us that this problem might be more difficult than the language requirements, since languages were well known and environments were essentially non-existent.

In July 1978 a more appropriate document was issued, PEBBLEMAN [HOLWG, 1978c], replaced in January 1979 by PEBBLEMAN Revised [HOLWG, 1979a]. Peter Elzer did most of the work on this. Comment was solicited from the software development community, a somewhat different group than the language experts who addressed the language requirements. A meeting was held at the University of California (Irvine) in June 1978 [Standish, 1978] discussing all aspects of the requirements. In September 1978, a meeting at Eglin AFB, Florida, discussed primarily the technology of retargetable compilers [AFATL, 1978]. PEBBLEMAN covered such topics as the language configuration control board, whose responsibility is to maintain the definition and resolve any possible questions. A language control facility would provide validation and certification of compilers to assure that they conformed to the official definition within the limits of the current ability to test. The bulk of the document was concerned with defining those tools which could be provided in common to the use of language and outlining the methodology for producing and inter-relating those tools.

A further iteration, STONEMAN [HOLWG, 1980b], primarily the work of John Buxton from the University of Warwick, England, was concerned with the integration of a set of Ada tools. A meeting in San Diego in November 1979 reviewed the thrusts of software development technology and discussed a Draft of a STONEMAN. The STONEMAN was issued in February 1980. It formalized the layers or levels of the Ada Program Support Environment (APSE), with the supporting Kernel (KAPSE) and Minimal (MAPSE) levels.


It was never the intent that the HOLWG program would implement compilers. This was the prerogative of the individual Services and of industry. It was hoped that settling on one language would make it attractive for the industry to produce compilers as commercial products, without government funding or control (as it has worked out). However, it was important that the Services show support for the standard by putting their money into some products. If no one thought the Services were interested (and money spells interest), then why should industry risk its own money? It was not actually necessary that the Service programs be successful, just that they exist. Indeed, there was a certain inhibitory factor; a company may not want to invest in a compiler for a particular machine if the government was doing the same and it might be available for free later. So we walked a fine line. I do not know how we could have proceeded differently. Tools and environments were also the province of the Services and industry.

There were several early implementations that should be noted. In connection with the language design there was an interpreter produced by Honeywell. This ran on the MULTICS system and fielded at MIT and Rome Air Development Center (RADC) for use in the Test and Evaluation phase. It let a large number of users get hands-on experience over the ARPANET very early, but it was incomplete and very slow. Because of these limitations, it was important to provide a more satisfactory support for those evaluating the language. Another interpreter was produced in 1980 by Intermetrics for the DEC-10. This was made available via the ECLB machine on the ARPANET. While certainly limited, it was much more useful than the previous system.

A complete interpreter, called Ada/Ed, was done by New York University. Although nominally for "educational use", this evolved to a complete, validatable system, which served to explore implementability during the polishing phase. It was considered by its developers to be an operational definition of the language. It was initially implemented in the set language SETL on a CDC Cybermachine.

The US Army (CORADCOM) contracted for the first large scale Service effort, the Ada Language System (ALS). This consisted of a complete environment along STONEMAN lines, including a production quality compiler. This development was contracted to SofTech in Waltham, MA. The implementation was done in a "Pascal-like" subset of Ada and was hosted and targeted for a DEC VAX. This effort was managed as a major system procurement, not a research effort. There was a competitive procurement, elaborate design documentation for every facility of the system, and a very large commitment of funds. The outcome was disappointing and the project was eventually shelved. Strangely enough, some time later the Navy chose this to be the basis of their major procurement, called ALS/N, although with another contractor. Cross compilers hosted on the VAX from this effort, called ADA/L (targeted for the AN/UYK-43) and ADA/M (AN/UYK-14 & 44), have been validated, but have not generated much general interest.

The Air Force (RADC/IS) initiated a similar procurement in 1980, called the Ada Integrated Environment (AIE). This was also a two-step competitive procurement. A design run-off was held among the first phase contractors: Computer Sciences Corp., Intermetrics, and Texas Instruments. The winner selected for the full-scale development was Intermetrics in Boston. The AIE was coded in a large subset of Ada and hosted/targeted to IBM 370 series machines. The contract included also both a compiler and STONEMAN environment. This project also fell on difficulties and the environment portion was deferred in favor of completing the compiler. Eventually the contractor completed the compiler after the expiration of the contract. Both the ALS and the AIE were embarrassing contractual failures for the sponsoring Service; however, they were necessary for the overall effort.

While I was at AFATL at Eglin, I proselytized for Ada and converted some people. Captain Jim Bladen did an early in-house compiler (hosted on a CDC Cyber, targeted to a Zilog Z8000 microprocessor) that is notable in that it led to what I believe was the first "operational" military use of Ada [Whitaker, 1983]. In early 1981, Jim Jones of AFATL programmed a briefcase Z8000 computer to checkout missile computers upon delivery. AFATL also contracted with Florida State University for a compiler. This was validated but found no users.

The British Government sponsored an effort at the University of York, subsequently York Software Engineering, that eventually validated. The German MoD contracted with University of Karlsruhe and GPP for an Ada compiler for the Siemens 7000 series machines.

The expectation of good, validated commercial compilers was fulfilled. Validation of 1815A implementations started shortly after ANSI approval. The first 1815A validation certificate was issued for the Ada/Ed interpreter on 11 April 1983, followed quickly by compilers from ROLM and Western Digital STC. There was an initial slow growth of implementations as companies mastered the language. By 1987 there were more than 100 validated compilers, and by 1992 this number had grown to about 400.

There were two sidelights of the compiler thrust, DIANA and CAIS.

By 1980 there were a number of large Ada compiler efforts underway. They were all facing the same problems with the same level of technology. In sharing experiences, it was noted that the projects used different, but technically similar, high level intermediate languages. The two main representations were TCOL-Ada from Carnegie-Mellon University (CMU) [Newcomer, 1979] and AIDA from the University of Karlsruhe [Dausmann, 1980]. By August 1980, there was a general feeling in the Ada community that these were close enough that there should be some effort at reaching common ground. Unfortunately, there never seemed to be time for the busy developers to get together, so nothing was happening. It appeared to me that a great opportunity was being missed, so I approached the government sponsors of the compiler developments at the December 1980 SIGPLAN Ada conference in Boston and convinced them to use the power of the purse to encourage the necessary coordination.

In January 1981, I hosted a two week parley in my office at Eglin AFB with representatives from Karlsruhe (G. Goos, G. Winterstein, M. Dausmann), CMU (W. Wulf, J. Nestor, D. Lamb), Softech (R. Simpson, L. Weissmann), and Intermetrics (B. Brosgol, M. Tighe). I supplied coffee, cookies, and fruit, and would not let them out until the matter was resolved. Agreement came much quicker than anyone had imagined, and DIANA (Descriptive Intermediate Attributed Notation for Ada) was born [DIANA, 1981]. DIANA, is a high-level tree-structured intermediate language for Ada and provides communication internal to compilers and other tools. It used the abstract syntax tree of the formal specification and had many attributes based on AIDA. From TCOL-Ada it inherited the symbol table attributes and some separate computation features. The meta-notation is the Interface Definition Language (IDL) of CMU. There were some differences between the formal definition and Diana. These were all resolved in early February at a meeting in Murnau, Germany.

DIANA was never supposed to be a standard to be enforced on all implementers. The purpose was simply to avoid duplication among those who were doing approximately the same thing anyway. There was some continued maintenance of DIANA [DIANA, 1983, 1986]. It is being used by a number of developers, although with some variations. Other implementers have opted for different representations.

Another Ada-related standardization initiative was the Common Ada Interface Set (CAIS). This started somewhat like DIANA. Since the ALS and the AIE were comparable Ada environments, it seemed a good idea to have a common interface definition to promote tools interoperability. In September 1982 a definition was begun by a DoD Kernel Ada Programming Support Environment (KAPSE) Interface Team (KIT) to foster compatibility between the ALS and AIE developers. Shortly the goals were expanded and volunteers were solicited (through a Commerce Business Daily announcement) to form a KAPSE Interface Team, Industry and Academia (KITIA). The CAIS Version 1.0 [CAIS, 1983; Oberndorf, 1983] was released for comment in September 1983. Eventually it developed into MIL-STD 1838 [CAIS, 1986]. This interface has not been generally adopted, having lost the impetus that might have been sustained if the ALS and AIE had been successful, but it is the US contribution to a cooperative effort with Europe.


An informal group known as the Ada Implementor's started meeting in May 1979 led by Gerald Fisher of New York University (NYU), which was developing Ada/Ed. This was the idea of Serafino Amoroso, a HOLWG representative of the Army, which was funding NYU. By August 1980 the group was issuing an Ada Implementor's Newsletter, edited by Mary Van Deusen of Prime Computer, Inc., which provided the financial backing. Wishing to establish a more formal organization, the group voted at the March 1981 meeting to seek recognition, and in a vote chose to affiliate with the ACM (vs. the IEEE). The name of the Newsletter was changed to Ada Letters [ACM, 1981]. On May 6, 1981, this group was chartered as AdaTEC, a technical committee under ACM SIGPLAN; Gerald Fisher was appointed Chairman. In 1984 the group was rechartered as SIGAda, the ACM Special Interest Group on Ada, and elected its first Chairman, Anthony Gargaro. This organization has provided the civil forum for Ada technical discussion and publication. It holds and sponsors frequent meetings that are the voice of the Ada community. By 1980 an Ada UK organization was established, and more than a dozen other national organizations are now active. Ada Europe provides a European forum much like SIGAda. There is an active, organized, worldwide community outside the DoD devoted to the use of Ada, as the HOLWG had hoped, and which did not exist for previous military embedded languages.


The purpose of the project was to reduce the cost of DoD software, not to build one more language. Reuse was the major thrust driving the imposition of a common language on the DoD. If only the technical features of the language were important, the DoD should have been as well served by 100 good languages. But commonality holds no profit unless it is put to advantage.

There are three aspects of the use of Ada, each important in its potential for cost reduction.
The first is the technical capability of the language:
capability to express the necessary functions,
easy to read, write, and understand,
support for reliable programming,
support for modularity and large program engineering.
The second is commonality:
based on technical capability,
supported by machine independence,
promotes the spread of tools,
sanctioned by standards bodies.
The third is reuse:
a product of machine independence and commonality,
requires facilities to reuse and a way to get to them.

Throughout the project there was the expectation, explicitly promised and budgeted for, that the government would develop, control, and provide certain basic tools and applications packages. These included the first level of software tools: compilers, editors, program analyzers, testing aids, etc. There was never the intent that all such capabilities were to be furnished by the government; as the above discussion on compilers points out, one expected that commercial offerings would eventually be superior to the basic level common set. Nevertheless, we viewed it as the responsibility of the project, or of the accompanying Service programs, to get things started. While still in the AJPO budget in late 1981, this never was accomplished. In addition, we had planned that libraries of reusable code specific for particular applications areas would be maintained by organizations knowledgeable in the area. (We use the term "library" or "toolbox" but that sends the wrong message. A library is a collection of things that are available. What we need is a concept of a bunch of parts that are necessary and sufficient and are put together and polished and improved over the years.)

As far as I know, there was no single decision to abandon these goals, but I have my suspicions as to the how it happened. The DoD management had found that single point promises of universal capabilities were unreliable, be it the capability a single aircraft design for all Services, or a single compiler; competition was the solution. The validity of this position had certainly been established by experience, the latest being the discouraging results of the highly touted ALS and AIE compiler/environment contracts. These had each been sold by the sponsoring Service as a complete capability efficiently produced. The results could have only reinforced the distrust of the Deputy Secretary of Defense, William Howard Taft IV, for such a solution, and his favor towards letting industry handle the situation, unfettered by government interference. I sense this as the prevailing philosophy. Although there was no explicit hindrance to the follow-on programs, indeed they were approved, it turned out that they could be accomplished only with extraordinary support at the OSD level. The language development had this support and succeeded; the tools effort did not, and languished.

I do not mean this speculation as a criticism of the OSD philosophy, in fact, I support it and agree with it in detail, as my vindicated expectations for the Ada compiler industry show. But I wanted to make a small exception in this case. The idea was that the government should sponsor a starter set of tools, which would not be exclusive, to show the way, and then stand aside and let industry refine and continue. The thought was that the government had sufficient experience to know what was immediately required, but should not expect to dictate future developments. This is a concept that one could sell at an instant, but one which did not have staying power in the face of other demands.

Nevertheless, while recognizing the predilection against this mode, I pursued the dream. I got involved with two other joint programs, in 1982 and in 1986, both run by Colonel Joseph S. Greene, with whom I had worked at Kirtland AFB. The World Wide Military Command and Control System (WWMCCS) Information System (WIS) was a joint project to modernize the nation's strategic command and control capability. Greene and I were responsible for advanced technology on this program and believed that the right software technology for the extraordinary demands of this system was Ada, a bold position in 1982. Supported by a number of investigations and demonstrations, the WIS Joint Program Management Office selected Ada as its implementation language in May 1983. In June, perhaps influenced by this commitment, Richard DeLauer, then Under Secretary of Defense for Research and Engineering, sent out a memo [DeLauer, 1983] to all Services and Agencies mandating Ada for future DoD mission critical systems, directing that

"The Ada programming language shall become the single common programming language for Defense mission-critical applications. Effective 1 January 1984 for programs entering Advanced Development and 1 July 1984 for programs entering Full-Scale Engineering Development, Ada shall be the programming language."

In support of this view, WIS let 54 Ada contracts, known as the NOSC tools, since procurement was done by the Naval Ocean Systems Center. The purpose of these was to prove that the state-of-the-practice would support Ada systems developments. These contracts exercised the state-of-the-practice among DoD contractors and evaluated available compilers, training, management capabilities, all that goes into a system development. The large number of contracts meant that one could determine if Ada was ready, not just whether a single contractor was capable. It was quite permissible for some contracts to fail, they often do even with mature technologies. The success of a large number was sufficient to establish the viability of Ada. Along the way, a number of tools were developed and made publicly available, for WIS and for any other Ada development, primarily by being submitted to an Ada repository. Rick Conn of General Electric was chiefly responsible for promoting this pioneering component library of Ada source code set up on a machine (SIMTEL20) at White Sands Missile Range, NM, accessible over the ARPANET. WIS was also concerned with, and funded, the bindings of Ada programs to exterior standards, such as the Graphical Kernel System (GKS) and database systems, without which systems could not port, even with portable code.

We expected that the technology work would be continued by the WIS prime contractor, the tools would be refined, and a machine independent environment set of high quality components would ensue. Machine independence was to be the key to settling the hardware predicament of this system. Managerial and contractual circumstances negated this plan and little additional component work was forthcoming.

In 1986 Col. Greene became the Director of the DoD Software Technology for Adaptable Reliable Systems (STARS). I had served my 30 years and was retired from the Air Force so could only participate as a supporter from the sidelines, but maintained a keen interest. STARS was part of a three pronged "Software Initiative", the other two being the AJPO and the Software Engineering Institute (SEI) in Pittsburgh. Again, contractual constraints shaped the program. Initially there were a number of "STARS Foundations" contracts, in the line of the NOSC Tools, this time chiefly through the Naval Research Laboratory (NRL). The main program consisted of three prime contractors who were supposed to integrate and exercise environment technologies. The contracts specifically required 60% of the effort to be done by subcontractors, in order to stimulate innovation. Again development of a repository was a major feature of the program. Once again, managerial and budgetary constraints conspired against our expectations.

Another early try was the Common Ada Missile Packages (CAMP) program at AFATL, which was the first large government effort to develop a specific applications library. This was managed by Christine Anderson, who became the director of the Ada 9X program. CAMP was contracted for in the normal government fashion, from a single contractor. It might have been more Ada-like if it were open and funded for continued polishing and extension. The moral of all these efforts is that it is vital that components be supported and polished, and subject to continual peer review.


Ada, the project and the language, was driven by the goal of encouraging good software design and programming practice. The modularity provided by packages and the separation of specifications and bodies is exceptionally useful in this regard. Properly managed, it is applicable to all levels of the design process, as well as to the programming task. Ada itself is used as a program design language [IEEE, 1987], and its use has spawned general interest in design languages. Used in design, Ada allows designs to be compiled, and even mock executed, rigorously verifying critical interfaces at a point in the process where adjustments are convenient. Ada facilitates the effective direction of a development effort involving hundreds of people, even in different organizations, and the controlled maintenance and modification of software over many years. It does the technical job that was required.

Ada was designed to support and encourage "object-oriented design", and it does. Ada packages can be used to create "objects". In the 70's there were some very vocal objections that Ada did not have "abstract data types" (the buzzword of the day), since a package was not limited to someone's notion of what that meant. During the 80's the use of the "object-oriented" buzzword has changed; one now implies "object-oriented programming" features such as "inheritance", which even be dangerous in high-integrity systems. Ada 9X will provide this support in order to promote programmer acceptance, but this addition neither enhances the system engineering capability of Ada nor disparages the original design.

Ada has achieved a level of acceptance beyond what was required, a level that we had hoped for. It is an ANSI and ISO standard, as well as a military standard. It is mandated, not only by the DoD, but by the Congress. It is used by many other large organizations. This was the goal of the project and it succeeded.

Ada had to satisfy a large set of requirements. One of the dangers was that a poor design would result in a language that was too large or too complicated to be useful for the DoD. There is no agreed to quantitative measure for computer languages, but I could argue that Ada is smaller than COBOL, and not enormously larger than FORTRAN. The text of a good Ada program is extremely readable. These properties combine to make Ada very teachable to DoD programmers.

The educational aspects of Ada are the most bewildering. It is being taught in a fairly large number of institutions, from high schools on up, but, while growing, it has certainly not become the principal language of choice. I have had excellent results teaching Ada to brand new Airmen with a high school diploma and 11 weeks in the Air Force [Whitaker, 1983]. But there are institutions where it has been proclaimed too difficult to introduce below graduate Computer Science. It might be fair to say that Ada is a language for software engineering, rather than just "programming", and that discipline is very young.


Tools for and in Ada are now widely available, but it is my greatest disappointment that there are not more and better tools publicly available for Ada than for all other languages combined. There was much effort and many opinions on how to integrate tools but few new ideas for tools beyond those in general use. I had expected that Ada would have lots of facilities because we could now have them machine independent. I tried to do a bit, pick up the slack, prime the pump and get people interested, but not very successfully. WIS made starts on such simple things as math packages, a copy of the UNIX tools, an I/O generalization (from simple terminal to windows), communications capabilities, graphics, etc. We could exert influence, but it was administratively impossible to actually command a bunch of programmers to do such tools. Beyond Ada programming tools, I wanted to use Ada to introduce and support other standards efforts for the DoD, such as the Standard Generalized Markup Language (SGML) and the Computer Graphics Metafile (CGM) which are now being used by the DoD Computer Aided Logistics System (CALS). Maybe I was wrong and the world would not have been better off, but I doubt it. 9X reiterates the promises to release tools into the public domain. I hope this finally takes off.

There are a lot of things that one can do differently because there is a truly common language. Ada provides a lingua franca for communication beyond programming. Pure Ada is used as a design language, a command language, database entry and checking, and for message format definition, resulting in enormous benefits in development time and system reliability. But much of the applications are of conventional design and have not exploited the full range of novel Ada techniques.

Educationally, Ada has been beset with two unique obstacles, neither technical. There is a feeling that Ada facilitates all those aspects of good design and management that one puts under the umbrella term of "software engineering", and it certainly does. Some managers have taken this to the extreme and decided that there is no point in using Ada unless they can train their personnel to a total "software engineering" capability. While admirable, this is difficult, and possibly undefined, so the result is delay, intentional or not.

The other obstacle, which affects especially the academic world, is that good Ada compilers were initially expensive relative to some other languages. While the academic price of Ada compilers is now competitive and the computer resources required are available in present desktop computers, the requirements may exceed (mostly in memory) those purchased some time ago. It is certainly true that such constraints are not limited to the academic community, but I note the example of the US Air Force Academy teaching ALGOL for years to cadets because Burroughs gave them a machine effectively supporting only ALGOL, in spite of the fact that ALGOL was not used elsewhere by the Air Force. I protested this at the time. In 1992 the Military Academies still do not teach Ada as their primary language!

Both the tools and the compiler availability situations illustrate the limits on a US Government program, because it is a government program. The absolute amount of money that could be involved in producing all the tools one could imagine and providing a free compiler for every computer in the country is trivial compared to what the DoD spends on software every month. (In the past, large corporations have had much more freedom for such initiatives, but are facing stricter controls.) However, any such direct government program would be contrary to law and the US economic system, and I would not wish it otherwise. Perhaps the question is whether the government should provide a competitive environment for its internal use.

Ada planned for training, and the expected commercial courses and books became available. A large Ada training problem was instructors that had to show off by making it seem as difficult as possible in order to snow the students. There were even groups that did not want to make the transition to Ada and used training as a delaying tactic. Some suggested that programmers have to know every feature in order to begin (but this is not the way anyone approached any other language), and that they had to have a 3-month training course before they could proceed (although they had no training program for their present languages). Furthermore, they could not use Ada without lots of training in software engineering (although they were accepting the government's billions without apparently any knowledge of, and certainly no training in, software engineering). While all of these preparations are important, they should be important for software development in any language, but they have been used as disingenuous excuses not to use Ada.


The development was extraordinarily open. Not only were thousands kept informed, they had a chance to participate, and did. During my chairmanship, I had a mailing list of over 3000 who had contacted me, and many were the contacts for their lab or company. The project was extraordinarily well documented and the documentation was a fundamental working tool, not an after the fact exercise. The requirements were extensively circulated externally, certainly far more so than has any other language effort, before or since. The evolution of the requirements is explicitly revealed in this series of documents. The language comparisons and contract evaluations were published in excruciating detail and are available to the public. These documents have the complete text of all designs and evaluations submitted to the HOLWG. During the polishing process, there were numerous Language Study Notes written and made available to a large community over the ARPANET. Since standardization, there have been hundreds of questions processed by the Ada Rapporteur Group. These range from trivial questions that are answered in the Language Reference Manual (LRM) to complex issues which require a significant binding interpretation. All issues submitted have been addressed, and results were available on the ARPANET, and have been published commercially.

The project was a continuous fight. The Service bureaucracies had to be reminded continuously about the program. Everyone was demanding several languages; they could not imagine Air Force and Navy F-4s being programmed in the same language. There were those who just objected to OSD doing anything technical. The project was under continuous scrutiny and pressure. It survived and prevailed.

My figures through FY 78 for the total funds expended by the program from the beginning through final language selection (FY 76-78 funds - although selection was in FY 79, funding must be allocated at the beginning of a contractual period) and the beginning of the validation effort was $3.550 million, with another $550,000 in related Service programs. I do not offer this as an audited value, but the best number I can find in my records.

Was the project a success? It was prudently run. The language product was on time and within budget, and of very high quality. The public requirements development was a unique success, thanks to the technical leadership of David Fisher. The procurement went smoothly, thanks to Bill Carlson who averted lurking bureaucratic delays. When we started there were more than 450 languages in use in the DoD, each with its a compiler, in almost all cases limited to one machine and weapons system. There is now a single language with more than 450 compilers. Other aspects have come about more slowly than we had hoped. When we started we were worried about a $3 billion a year DoD problem, today it is a $30 billion expense to the DoD. It is hard to make a prima facie case that we stemmed the "high cost of software". However, the growth of total software costs reflects the growth of hardware capabilities permitting (or demanding) more software. I believe that as a result of the HOLWG program, software productivity and quality is improving steadily. It may be taking longer than we had hoped.

I expected a certain natural conservative reluctance on the part of military System Program Offices to adopt a new language in the early days, and even some diehard opposition to be subdued only slowly through direction. However, upon adoption of the common language, I had envisioned a rapid growth of components and tools within a cooperating community, an Ada Culture. It did not happen as quickly as I had hoped. "Repository" is now a universal buzzword, but DoD contracting limits (and the mindset that these have built up) long strangled the vision for cooperation and growth. I mistakenly thought that with the influence of the DoD we could pull it off. The thrust of cooperative development struggled and faded, several times. But there are other achievements that exceeded our original expectations. The language itself is better than we could have hoped. There is a lot more structure in the community, much of which this project injected. Reuse is happening.

In summary I think we did a good job. I think the project was run well and is an example for the world. For Ada, acceptance is not what the computer science community thinks of it, or whether it is popular on home computers, the question is what does DoD, NATO, NASA, FAA, etc. think. Ada is a success. For evaluating a common language, the users are projects, not programmers, and such users are conservative. They will use what they have used previously because they know it, or use whatever the contractor wants. It takes time to bring the community over, even with direction from above. Most projects in DoD started with it because it was mandated; however, many commercial and foreign firms have adopted it without such influence. For large systems, there is no comparable capability. After experience with Ada, managers and programmers are enthusiastic.

Our goal was to create a common language for DoD software. On November 5, 1990, the President signed the 1991 Appropriation Bill (Public Law 101-511), which reads in Section 8092:

"Notwithstanding any other provisions of law, after June 1, 1991, where cost effective, all Department of Defense software shall be written in the programming language Ada, in the absence of special exemption by an official designated by the Secretary of Defense."


This history would not have been possible without the help of John Walker of the IIT Research Institute at the AJPO. He found the source documents that were needed to assure the accuracy of the paper. I also received invaluable comments and help from Jean E. Sammet and Anthony Gargaro, and from the anonymous reviewers who made suggestions resulting in enormous improvements in the paper.


Formation of HOLWG--JAN 75
TINMAN Issued--JAN 76
DoDD 5000.29--APR 76
DDR&E Directs Service Funding--MAY 76
DoDI 5000.31--NOV 76
Languages Evaluation Completed--DEC 76
Program Management Plan--JAN 77
Report of Evaluation--JAN 77
IRONMAN Issued--JAN 77
Final SOW for Design--MAR 77
RFP Issued--APR 77
Revised IRONMAN Issued--JUL 77
Design Contracts Awarded--AUG 77
Economic Analyses--JAN 77 - NOV 77
Language Design - Phase I--SEP 77 - FEB 78
Language Design Evaluation--MAR 78 - APR 78.
Select contractors to Continue--APR 78
Program Decision Date--APR 78
Language Design - Phase II--MAY 78 - FEB 79
PEBBLEMAN Revised Issued--JAN 79
Final Selection--MAY 79
Test & Evaluation--MAY 79 - SEP 79
Preliminary Ada published--JUN 79
MIL-STD 1815--DEC 80
First 1815A validation--APR 83
DeLauer mandate for Ada--JUN 83
ISO Standard 8652--JUN 87
Ada 9X Revision process initiated--SEP 88

Figure 14


Documents with AD number are available from the Defense Technical Information Center or the National Technical Information Service.

[ACM, 1980]
Proceedings - ACM SIGPLAN Symposium on the Ada Programming Language, Boston. MA, December 9-11, 1980, ACM SIGPLAN Notices, Vol. 15, No. 11, November 1980.
[ACM, 1981]
ACM Ada Letters, (1981 and continuing), previously Ada Implementor's Newsletter (from 1979).

[Ada, 1979a]
Preliminary Ada Reference Manual, SIGPLAN Notices, Vol. 14, No. 6A, June 1979,AD-A071 761.

[Ada, 1979b]
Rationale for the Design of the Ada Programming Language, SIGPLAN Notices, Vol. 14, No. 6B, June 1979, AD-A073 854.

[Ada, 1983]
ANSI/MIL-STD-1815A-1983, Reference Manual for the Ada Programming Language, 1983, AD-A131 511.

[AFATL, 1978]
Report of the Eglin Workshop on Common Compiler Technology, AFTAL, 28 September 1978

[Berning, 1980]
Berning, Paul. T. Formal SEMANOL Specification of Ada, Rome Air Development Center Report RADC-TR-80-293, September 1980, AD-A091 682.

[Bjorner, 1980]
Bjorner, D., Oest, O. N., Towards a formal definition of Ada, Lecture Notes in Computer Science, Vol. 98, Springer-Verlag, 1980

[Botta, 1987]
Botta, N., Pertersen, J. Storbank, The Draft Formal Definition of Ada, The Static Semantics Definition, Vol 1-4 Jan 87, Dansk Datamatik Center, Lyngby, Denmark

[Bowden, 1953]
Bowden, B. V., Faster Than Thought, London: Pitman, 1953.

[CAIS, 1983]
Draft Specification of the Common APSE Interface Set (CAIS), Version 1.0, prepared by KIT/KITIA Working Group for Ada JPO, 26 August 1983.

[CAIS, 1986]
DOD-STD-1838 Common APSE Interface Set (CAIS), October, 1986.

[Carlson, 1980]
Carlson, W. E., Druffel, L. E., Fisher, D. A., Whitaker, W. A., Introducing Ada, in Proceedings of the 1980 ACM Annual Conference, ACM, pp. 27-29, October 1980.

[Clapp, 1977]
Clapp, Judy A., Loebenstein, E., Rhymer, P., A Cost/Benefit Analysis of High Order Language Standardization, M78-206, The MITRE Corporation, September 1977.

[Cohen, 1981]
Cohen, Paul M., From HOLWG to AJPO -- Ada in Transition, Ada Joint Program Office, (internal document), 1981.

[Currie, 1975a]
Currie, Malcolm R., DoD Higher Order Programming Language, Memorandum from Director of Defense Research and Engineering, Washington, DC, 28 January 1975. Figure1 of this paper.

[Currie, 1975b]
Currie, Malcolm R., DoD Higher Order Programming Language Working Group, Memorandum from Director of Defense Research and Engineering, Washington, DC, 2 May 1975. Figure 2 of this paper.

[Currie, 1976]
Currie, Malcolm R., DoD High Order Language Program, Memorandum from Director of Defense Research and Engineering, Washington, DC, 10 May 1976. Figure 3 of this paper.

[Dausmann, 1980]
Dausmann, M., Drossopoulou, S., Goos, G., Persch, G., and Winterstein, G., AIDA Reference Manual (Preliminary Draft), Institut fur Informatick II, University of Karlsruhe, Report 2/80, 4 February 1980.

[DeLauer, 1983]
DeLauer, Richard D., Interim DoD Policy on Computer Programming Languages, Memorandum from Undersecretary of Defense (Research and Engineering), Washington, DC, 10 June 1983.

[Dewar, 1983]
Dewar, R., Froelich, R. M., Fisher, G. A., Kruchten, P., An Executable Semantic Model for Ada, Ada/Ed Interpreter, Ada Project, Courant Institute New York University, 1983

[DIANA, 1981]
Diana Reference Manual, Institut fur Informatik II, Universitat Karlsruhe and Department of Computer Science, Carnegie-Mellon University; Report 1/81, March 1981.

[DIANA, 1983]
Evans, Jr., Arthur, Butler, Kenneth J., DIANA (Descriptive Intermediate Attribute Notation for Ada) Reference Manual, Revision 3, 1983, AD-A128 232.

[DIANA, 1986]
McKinley, Kathryn L., and Schaefer, Carl F., DIANA Reference Manual, Revision 4, Intermetrics, Inc, IR-MD-078, May 1986.

[DoD, 1976b]
Department of Defense Directive 5000.29, Management of Computer Resources in Major Defense Systems, 26 April 1976.

[DoD, 1976c]
Department of Defense Instruction 5000.31, Interim List of DoD High Order Programming Languages (HOL), 24 November 1976.

[Donzeau-Gouge, 1979]
Donzeau-Gouge, Veronoque, Kahn, G., Lang, B., Green Language, A Formal Definition, Honeywell, Cii Honeywell Bull, INRIA, 1979, ADA058 047.

[Donzeau-Gouge, 1980]
Donzeau-Gouge, Veronoque, Kahn, G., Lang, B., Formal Definition of the Ada Programming Language, Honeywell, Cii Honeywell Bull, INRIA, 1980.

[Duncan, 1979a]
Ducan, C. W. Jr., Letter from Deputy Secretary of Defense, Washington, DC, 14 May 1979. Figure 5 of this paper.

[Duncan, 1979b]
Ducan, C. W. Jr., Letter from Deputy Secretary of Defense to The Earl of Lytton, Washington, DC, 14 May 1979. Figure 8 of this paper.

[Fisher, 1974]
Fisher, David A., Automatic Data Processing Costs in the Defense Department, Paper P-1046, Institute for Defense Analyses, October 1974, AD-A004 841.

[Fisher, 1978a]
Fisher, D. A. and Wetherall, P. R., Rationale for Fixed-Point and Floating-Point Computation Requirements for a Common Programming Language, Institute for Defense Analyses, Report IDA-P-1305, January 1978.

[Fox, 1978]
Fox, Joseph M., Benefit Model for High Order Language, Decisions and Designs Incorporated, TR78-2-72, March 1978.

[Giovini, 1987]
Giovini, Alessandro, Mazzanti, Franco, Reggio, Gianna, and Zucca, Elena, The Draft Formal Definition of Ada, The Dynamic Semantics Definition, Current Algebra, Vol 4 Dec 86, Dansk Datamatik Center, Lyngby, Denmark

[Goodenough, 1980]
Goodenough, John, The Ada compilation validation capability, in Proceedings - ACM SIGPLAN Symposium on the Ada Programming Language, Boston, MA, December 9-11, 1980, ACM SIGPLAN Notices, Vol. 15, No. 11, November 1980, pp. 1-8.

[HOLWG, 1975a]
"STRAWMAN" Requirements for a DoD High Order Programming Language, February 1975.

[HOLWG, 1975b]
"WOODENMAN" Set of Criteria and Needed Characteristics for a Common DoD Programming Language, David A. Fisher, IDA, 13 August 1975.

[HOLWG, 1976]
Department of Defense Requirements for High Order Computer Programming Languages "TINMAN", June 1976.

[HOLWG, 1977a]
Amoroso, S., Wegner, P., Morris, D., White, D., Loper, W., Cambell, W., Showalter, C., Language Evaluation Coordinating Committee Report to the High Order Language Working Group (HOLWG), 14 January 1977, AD-A037 634.

Department of Defense Requirements for High Order Computer Programming Languages "IRONMAN", January 1977.

[HOLWG, 1977c]
High Order Language Working Group, Studies of the Economic Implications of Alternatives in the DoD High Order Commonality Effort, Internal Study, 1977.

[HOLWG, 1977d]
Department of Defense Requirements for High Order Computer Programming Languages "IRONMAN" Revised, July 1977.

[HOLWG, 1978a]
HOLWG, DoD High Order Language Commonality Effort - Design, Phase I Report and Analyses, June 1978, AD-B950 587.

[HOLWG, 1978b]
Department of Defense Requirements for High Order Computer Programming Languages "STEELMAN", June 1978, AD-A059 444.

[HOLWG, 1978c]
Department of Defense Requirements for the Programming Environment for the Common High Order Language "PEBBLEMAN", July 1978.

[HOLWG, 1979a]
Department of Defense Requirements for the Programming Environment for the Common High Order Language "PEBBLEMAN" Revised, January 1979.

[HOLWG, 1979b]
Test and Evaluation Newsletter Number 1; 25 May 1979; also in SIGPLAN Notices September 1979, pp. 77-80.

[HOLWG, 1979c]
Ada Test and Evaluation Workshop (Proceedings), DARPA and MIT Laboratory for Computer Science; 23-26 October 1979.

[HOLWG, 1980a]
HOLWG, DoD High Order Language Commonality Effort - Ada Design, Phase II Reports and Analyses, January 1980, ADA-80-1-M or AD-A141 817 (available only from DTIC).

[HOLWG, 1980b]
DoD Requirements for Ada Programming Support Environments, "STONEMAN", February 1980, AD-A100 404.

[Ichbiah, 1987]
Ichbiah, Jean D., Barnes, John G. P., Firth, Robert J., Woodger, Mike, Rationale for the Design of the Ada Programming Language, Honeywell, 1987, AD-A187 106.

[IEEE, 1985]
ANSI/IEEE Std 754-1985, IEEE Standard for Binary Floating-Point Arithmetic, New York; IEEE, 1985 (Reaffirmed 1991).

[IEEE, 1987]
ANSI/IEEE Std 990-1987, IEEE Recommended Practice for Ada As a Program Design Language, New York: IEEE, 1987

[Lytton, 1978]
Lytton, Letter to Philip Wetherall from The Earl of Lytton, Keeper Knight's, Pound Hill, Crawley, Sussex, England, 18 October 1978. Figure 7 of this paper.

[Monterey, 1973]
Proceedings of a Symposium on the High Cost of Software Held at the Naval Postgraduate School, Monterey California on September 17-19, 1973, SRI Project 3272, Stanford Research Institute, Menlo Park, CA, September 1973.

[Moore, 1977]
Moore, Doris Langley-Levy, Ada, Countess of Lovelace: Byron's Legitimate Daughter, London: Murray, 1977.

[Morrison, 1961]
Morrison, P. and E., Charles Babbage and His Calculating Engines, New York: Dover, 1961.

[Nielsen, 1987]
Nielsen, C. Bendix, Karlsen, E. W., The Draft Formal Definition of Ada, The Dynamic Semantics Definition, Vol 1-3 Jan 87, Dansk Datamatik Center, Lyngby, Denmark

[Newcomer, 1979]
Newcomer, J. M., Lamb, D. A., Leverett, B. W., Levine, D., Reiner, A. H., Tighe, M., and Wulf, W. A., TCOL-Ada; Revised Report on an Intermediate Representation for the DoD Standard Programming Language, Department of Computer Science, Carnegie-Mellon University, Report CMU-CS-79-128, 20 June 1979.

[Oberndorf, 1983]
Oberndorf, Patricia, Kernel Ada Program Support Environment (KAPSE) Interface Team, Public Report, Report NOSC/TD-552, October 1983, Volume 1, AD-A115 590, Volume 2, AD-A123 136, Volume 3, AD-A141 576.

[Perry, 1978]
Perry, William J., DoD High Order Language Commonality Program, Memorandum from Director of Defense Research and Engineering, Washington, DC, 11 April 1978. Figure 4 of this paper.

[SAMSO, 1972]
Information Processing/Data Automation Implication of Air Force Command and Control Requirements in the 1980s (CCIP-85), Volume 4, Technology Trends: Software, SAMSO-TR-72-122- V-4, AD-919-267L.

[Shaw, 1978]
Shaw, M., Hilfinger, P., and Wulf, W. A., TARTAN--Language Design for the Ironman Requirement; Notes and Examples, Department of Computer Science, Carnegie-Mellon University, Report CMU-CS-78-133, June 1978, AD-A062 856/0.

[Standish, 1978]
Standish, Thomas, Proceedings of the Irvine Workshop on Alternatives for the Environment, Certification, and Control of the DoD Common High Order Language, Held at University of California, Irvine on 20-22 June 1978, Report UCI-ICS-78-83, AD-A089 090.

[Stein, 1985]
Stein, Dorothy, Ada: A Life and a Legacy, Cambridge MA: MIT Press, 1985, ISBN 0-262-19242-X.

[Wetherall, 1978]
Wetherall, Phillip R., Letter to The Earl of Lytton, Royal Signals and Radar Establishment, Great MAlvern, Worcs, England, 10 October 1978. Figure 6 of this paper.

[Wentworth, 1938]
Wentworth, Lady, Thoroughbred Racing Stock and its Ancestors: The Authentic Origin of Pure Blood, London: George Allen & Unwin Ltd., 1938 (has the real story on horses that Bowen mistook).

[Whitaker, 1977]
Whitaker, William A., The US Department of Defense Common High Order Language Effort, SIGPLAN Notices, February 1977.

[Whitaker, 1983]
Whitaker, William A., Three Ada Examples, in COMPCON 83, 26th IEEE Computer Society International Conference, 1983, p. 355-359.

[Whitaker, 1990]
Whitaker, William A., Programming Languages Overview, in Aerospace Software Engineering, Christine Anderson and Merlin Dorfman, ed., Washington; American Institute of Aeronautics and Astronautics, pp. 353-362, 1990, ISBN 1-56347-005-5.

[Williams, 1977]
Williams, John H., and Fisher, David A., ed., Design and Implementation of Programming Languages - Proceedings of a DoD Sponsored Workshop, Ithaca, October 1976, Lecture Notes in Computer Science, Vol. 54, Springer-Verlag, 1977.