What did the DoD think Fortran lacked?

Question

According to https://en.wikipedia.org/wiki/COBOL the project to design COBOL began when

On 28 and 29 May 1959 (exactly one year after the Zürich ALGOL 58 meeting), a meeting was held at the Pentagon to discuss the creation of a common programming language for business. It was attended by 41 people and was chaired by Phillips.[20] The Department of Defense was concerned about whether it could run the same data processing programs on different computers. FORTRAN, the only mainstream language at the time, lacked the features needed to write such programs.

What features did FORTRAN lack, that the Department of Defense believed were necessary to write portable business software? The two I can think of are decimal arithmetic and records with named fields; were those what the DoD had in mind, or were they thinking of something else that hasn't occurred to me?

Answer 1

The meeting that defined the requirements of the new language took place on May 28–29, 1959. Charles Phillips prepared a memo several months later summarizing the decisions made at that meeting. Its listing of requirements is reprinted on page 201 of the ACM’s History of Programming Languages.

a. Majority of group supported maximum use of simple English language; even though some participants suggested there might be advantage from using mathematical symbolism.

b. A minority suggested we steer away from problem-oriented language because English is not a panacea as it cannot be manipulated as algebraic expressions can.

c. The need is for a programming language that is easier to use, even if somewhat less powerful.

d. We need to broaden the base of those who can state problems to computers.

e. The [Common Business Language] should not be biased by present compiler problems.

The committee did not consider FORTRAN as an alternative. According to Jean E. Sammet, who was chair (She describes herself as the “chairman”) of two of the committees that developed COBOL and served on a third, the major inspirations were FLOW-MATIC (developed by Grace Hopper and others for Remington-Rand Univac), AIMACO (developed by the Air Materiel Command based on Hopper’s work, and described by Sammet as “a minor modification of FLOW-MATIC”) and COMTRAN (Commercial Translator, which at that time existed as a manual at IBM, and had never been implemented). Sammet claims that FACT, developed at Honeywell, had far less influence on COBOL than some people believed.

The entire chapter I link to has extensive notes that Sammet took at the time from the committee that developed COBOL, and the decisions it made.

She makes the particularly interesting admission on page 221:

I felt there was a strong anti-IBM bias in this committee from me, and from some (but certainly not all) of the others. Since I was not working for IBM at the time, I can freely (although not with pride) admit that in some cases suggestions or decisions were made on the basis of doing things differently from how IBM did it. For example, we felt that the verb for loop control should not be called DO because that was how FORTRAN did it.

Sammet lists among the ideas COBOL took from FLOW-MATIC, “It used full data names rather than short symbolic names (as in FORTRAN)” e.g. SOCIAL-SECUR instead of SOCSEC, and used English words as commands. Less cosmetically, it allowed fields to be packed into a data word. She says, “Note that Fortran assumes that every number is in a single machine word.” It separated data definitions from instructions, which she says became so commonplace that it’s difficult to appreciate what a conceptual breakthrough it was.

Among the ideas she lists as coming from COMTRAN are nested data structures, expressions, and conditionals. It was controversial at that time to allow mathematical formulas and even Boolean expressions, as some committee members believed those were only needed in a few edge cases.

She also states that IAL, which developed into ALGOL, had a significant influence, by convincing the committee not to follow its example, and instead allow in its source code only characters that actually exist.

Answer 2

FORTRAN was, at the time(*1), lacking almost everything, from string handling to all I/O beside reading numbers from cards or tape. Heck, not even integer size was guaranteed across machines.

No real way of structuring or flow control beside GOTO — even subroutines/functions were only integrated a year before with FORTRAN II. For most parts, FORTRAN is a symbolic assembler with a focus on mathematics, that made it easy to write formulas, but not much else.

But real world computing is about data handling and I/O. This is especially true for a huge organization as the US military, represented by its bureaucratic arm, the DoD. Being able to easily write down some complex calculation is nice, but useless in an environment there it's about managing inventory, ordering supplies, calculating pay and have all of that delivered in time.

An army is like a huge corporation, not a scientific institute and the task at hand is data processing, not number crunching.

Data Processing is vastly different from number crunching — it's a completely different world. It's about the classic "read card, process item, write output" loop, the stuff that got automated with punch cards. It is the core reason why the /360 has survived until today as a successful architecture. Its instruction set is perfectly tailored to shovel data, being built to support these principles. The fact that IBM tried to make it an all around (360 degree) architecture by including FP and even trying to make it fit for process control didn't really matter on the long run — others were much better for either.

And the DoD did need data processing to fight the wars at the time (Korea just ended and Vietnam was coming up), and a language to support writing data processing programs in a machine independent way. That's why COBOL was developed as a result of the mentioned conference.

---

*1 - FORTRAN did improve a lot since back then, still, it didn't really change the basic nature.