. navigate

Red Reference Manual

1986, pp.78-84

Available at used book sellers

Red Reference Manual


Though the phrase has come to mean practically all things to all programmers, essentially it describes a systematic, mathematical approach to the creation of software. ln particular, it calls for dividing programs into small, logically arranged tasks, as Pascal does. One specific aim of structured programming is to reduce the use of the so-called unconditional jump, or GOTO statement. Most major languages use the GOTO in order to transfer control of processing from one place in a program to another point perhaps several pages distant. Though a handy tool for the programmer, the GOTO statement almost always makes a program more difficult to read and thus increases the chance that errors will go undetected.

By stressing rigorous organization, advocates of structured programming hoped to limit the problems created by the ever-increasing complexity of software. Programs such as those required by systems that control air traffic - and later space satellites - were growing so large that they took years to complete; they had to be written in sections by teams of programmers, none of whom had a grasp of how everything fit together. Too often the result was software that cost millions of dollars, lagged months behind schedule and came on-line containing thousands of errors. The problem became so severe that computer scientists started referring to it as "the software crisis."

Nowhere was this mounting crisis more critical than in the U.S. military establishment, the world's largest consumer of computer hardware and software. By 1973, when officials began to pay serious attention to the problem, the Department of Defense was spending nearly half of its $7.5 billion computer budget to develop and maintain software. The cost of computer hardware, by contrast, was declining despite dramatic improvements in the computers' power and memory.

The software problem was most acute in weaponry and other so-called embedded computer systems. Such a system consists of a computer embedded in a weapon or machine - the tiny computer in a ballistic missile, for example, or the bigger ones controlling the communications on an airplane or ship. (Examples of embedded systems in nonmilitary applications include the microprocessors in automobiles or microwave ovens as well as the ones in robots on an industrial assembly line.)

Programs for embedded military systems often run to tens of thousands of lines of code. Expensive to write, such programs are even more costly to maintain. Over a typical lifetime of up to 20 years, they must undergo repeated modifications to keep up with the system's changing requirements. And program bugs in a system controlling a ballistic missile or an air-defense network could obviously have disastrous consequences.

No small part of the problem was the incredible hodgepodge of languages in which embedded-system software was written. Surveys during the early 1970s found no fewer than 450 high-level languages and dialects employed in coding such programs. (Some estimates, which also counted assembly languages, ran as high as 1,500.) Many were obscure languages developed for a single job because none of the major general-purpose languages could meet the job's special needs. These needs might include unusual input/output requirements and real-time control - the ability to monitor and respond to constantly changing conditions.

One result of the proliferation of languages in the military was massive duplication of effort. Each service had its own favorite languages, which were incompatible with those of the other services; a program written in an air force language, for example, had to be completely rewritten in a different language for use by the army or the navy. This, together with the related problems of training programmers to make them literate in more than one language, and of developing separate compilers for many applications, added up to runaway costs.

In january 1 975, the Pentagon set out to impose order on the linguistic chaos. It established a large committee known as the High Order Language Working Group (HOLWG), with representatives from all the military services as well as from three U.S. allies in the North Atlantic Treaty Organization - France, West Germany and the United Kingdom. HOLWG's mandate was to find languages - preferably only a few of them - suitable for programming every new embedded computer system that came on-line.


HOLWG's chairman, and the driving force behind the effort to straighten out the software mess, was Air Force Lieutenant Colonel William Whitaker. A brilliant student who dreamed of becoming a jet pilot, Whitaker had breezed through his undergraduate studies in physics at Tulane University in two years. He then achieved the highest academic grades in the history of his air force flight school, only to wash out as a pilot because he just could not get the hang of controlling an airplane. Despite this disappointment, Whitaker stayed in the air force and became thoroughly versed in computer science during a 16-year stint in nuclear weapons research at Kirtland Air Force Base, near Los Alamos, New Mexico. While rising to the post of chief scientist of the Air Force Weapons Laboratory there, he personally accounted for some 30,000 hours of computer processing time.

During that period, Whitaker came to know the frustrations of language incompatibility all too well. He remembered one program in particular that had to be rewritten five times as his computers again and again were replaced by newer models. Though HOLWG's mandate did not require the creation of a single common language, Whitaker had that in mind from the beginning. "He believed, when no one else believed, that there was a need for a common language," recalled one close observer, "and then he made it happen."

During that period, Whitaker came to know the frustrations of language incompatibility The way Whitaker made it happen was a sharp departure from all of the language-design procedures that had gone before, either in or out of the military. Instead of appointing a committee to haggle endlessly and then settle upon a language, HOLWG - at Whitaker's urging - sought the guidance of a long list of computer users within the military and programming experts outside. The users were asked to help define the necessary requirements for a common language. The task of drafting these general specifications fell to David Fisher, a civilian researcher at the Institute for Defense Analyses. Fisher brought to the job a solid background in the theory and practice of programming; he had taught at two universities and had designed military software at the Burroughs Corporation. He already had conducted studies of the Defense Department's software costs and understood its tangle of computer languages so thoroughly that he could usually pinpoint in an instant which department installation used which dialect of which language, and what the dialect's particular features were meant to achieve.


ln April 1975, three months after the formation of HOLWG, Fisher's first draft of requirements for a common language was circulated to reviewers in the military, industry and academia under the code name Strawman. The choice of name was significant, indicating that Fisher and Whitaker intended this document, as some- one put it, "to have the stuffing knocked out of it" by the reviewers, who would then suggest improvements.

The pounding was not long in coming, and Strawman was revised in response to the critical comments. This cycle of draft, review and revision continued through five additional sets of requirements over the following three years, eventually reflecting evaluations by more than 80 review teams in the U.S. and Europe. Each succeeding document bore a name that measured progress toward a hardening of the requirements: Woodenman, Tinman, Ironman, Revised lron- man and, the final standard, Steelman.

The list of requirements lengthened, reaching nearly 100 by the Tinman phase, until it became clear that no existing language could fill them all. The armed services issued an interim list of seven languages, including FORTRAN and COBOL, approved for programming embedded systems. But subsequent appraisals of these and a score of others made clear that none could satisfy more than 75 percent ofthe specified requirements.

Under Whitaker's prodding - "he ran the project with an iron fist," an observ- er noted, "in a velvet glove, of course" - HOLWG came to agree that the requirements could be met only by creating an entirely new language. To achieve this, the committee decided to stage an unprecedented international competition. ln May 1977, while the specifications were still evolving, the committee requested proposals from the world's top language designers, with the understanding that the proposals would be based on one of three languages: PL/I, ALGOL 68 or Pascal. Fifteen design teams responded, and most of their proposals were based on Pascal, demonstrating the dramatic impact of the new concept of structured programming.

HOLWG selected four of the proposals for funding during a six-month preliminary design phase. The contractors, all of whom proposed Pascal-based designs, were two Massachusetts companies, SofTech and lntermetrics; a California firm, SRI International; and Cii Honeywell Bull, the Paris-based subsidiary of an American company, Honeywell Corporation. Though each design team's entry received a color code name to preserve its anonymity during the review process, the predilections of the contractors were so familiar that astute reviewers were able to match the teams with their respective designs in a matter of minutes.

In 1978, after evaluation by nearly 400 reviewers, two of the four designs - Red (Intermetrics) and Green (Cii Honeywell Bull) were selected for a final showdown. The year-long phase of refinement that followed was unusually intense. A member of the Red team remembered falling asleep at night crying from fatigue. "Red was the more conservative language, Green the more briefly described, avant-garde |anguage," one of the competitors said. "But both languages changed during this final phase: Red becoming more avant-garde, Green becoming more conservative as it was fleshed out."

The winner, announced in May of 1979, was Cii Honeywell Bull. The Green team's victorious entry was christened Ada. The name honored Augusta Ada, Countess of Lovelace, the 19th-century mathematician and writer who is often credited with being the world's first programmer because of her interpretive writings about Charles Babbage's Analytical Engine in the predawn history of computing.

The victory was a personal triumph for Jean Ichbiah, who headed the Green team. Born in Paris in 1940, Ichbiah trained as a civil engineer at the prestigious Ecole Polytechnique. Later, the French government awarded him afellowship for further study in the United States. He became so captivated by computer programming while taking his Ph.D. at M.I.T. that he had difficulty completing his thesis on the optimal arrangement of subway systems. Soon thereafter, Ichbiah ` joined Cii, a new French company that later merged into Cii Honeywell Bull, and in 1972 he designed his first programming language, LIS, for Langage d'Implementation de Systemes. LIS was strongly influenced by Pascal and was the seed from which Ada sprang.

During the design competition, Ichbiah, who spoke no fewer than five human languages and had a brown belt in judo, drove himself even harder than he drove his 10-person international team, which included members from the U.S., the United Kingdom and West Germany as well as France. He sometimes worked 100 hours a week perfecting the design. Often he let his intuition guide him in making a decision, relying on esthetic considerations, for example, before developing a logical rationale. The result, wrote an admiring member of the runner-up Red team, was not "a language designed by a committee" but one "designed by a small team with a strong leader".


Ada's most distinctive aspect was an extreme approach to structured pro- gramming. The language permitted programs to be written in packages - self-contained modules that can be produced by different programmers and then fitted together. A package can be designed, tested, debugged and then stored in a library for later use in a program as if it were a piece of off-the-shelf software. This modular scheme, Ada's advocates have argued, creates programs that are reliable, easy to read and easy to maintain, saving thousands of hours and hundreds of millions of dollars.

But Ada's fans concede that the language pays a price for its readability and other advantages. Ada has so many features, designed to meet the government's Steelman specifications, that it is exceedingly difficult to learn. In addition, an Ada compiler occupies many more times the memory space needed by compilers for its root language, Pascal. Ada's size and complexity bothered critics such as Pascal's author, Niklaus Wirth, and C.A.R. Hoare, his old colleague from the ALGOL 68 controversy. Hoare, who served with Wirth on the SRI International team that was eliminated in the semifinals of the design competition, worried aloud that "gadgets and glitter prevail over fundamental concerns of safety and economy." He even publicly raised the specter of missiles going awry because of an undetected flaw in an Ada compiler.

Wirth put his concern a different way. "It throws too many things at the programmer," he said. "I don't think you can just learn a third of Ada and be fine. There are places where you tread on one of these spots which you haven't learned about, and it backfires on you."

In defense of his language, Ada's chief architect, Jean Ichbiah, expressed his "admiration and respect" for Wirth but added: "There are times when Wirth believes in small solutions for big problems. I don't believe in that sort of miracle. Big problems need big solutions!"

Other advocates have contended that the only alternative to a large, complex language like Ada for writing big software projects is a proliferation of small, simple and incompatible languages - the very situation that Ada was meant to remedy.

Predictably, creating compilers that would allow Ada programs to run efficiently on the Defense Department's various machines was no easy task. The job was made even more difficult by the Pentagon's determination that Ada remain unadulterated by dialects, extensions or subsets. Under the department's Ada copyright, any proposed compiler must conform to uncommonly rigid standards: No one can call their product an Ada compiler unless it is first officially validated in a battery of some 2,000 tests.


Despite these hurdles, successful compilers eventually appeared, and Ada began to make its presence felt. In 1983, the Defense Department directed that all new "mission-critical" applications be written in Ada. "Mission-critical" refers to computerized communications and weapons systems, such as the enormous programs contemplated for the Strategic Defense Initiative anti-missile network. The Pentagon has predicted that by the end of the decade, 85 percent of new mission-critical software - five billion dollars' worth - will be written in Ada.

Beyond its military applications, which included adoption as NATO's standard programming language, Ada has made modest headway. One lifesaving program that takes advantage of Ada's real-time capabilities monitors the condition of hospital patients connected to kidney dialysis machines. And although critics of the language remain vocal, Ada's absolute uniformity makes it irresistible to many managers of large programs.

Other major languages have gone through the tedious process of standardization, under the auspices of the American National Standards Institute (ANSI), in an attempt to rein in their dialects. But no other recent language has been so vigorously standardized from the outset, before dialects could even begin to proliferate. Thus, Ada in the 1980s has come close to guaranteeing true portability: A program can be written for one computer with the near-certainty that it can be recompiled and run correctly on other machines. This alone makes Ada an important programming tool for big projects, bringing order to at least a portion of the turbulent world of computer languages.


RED Reference
RED Rationale

Types in RED
Time/Life Computer Languages

Site Index

Overview             Reference ToC             Rationale ToC             Site Index

Home   Favorites   Map

IME logo Copyright © 2009, Mary S. Van Deusen