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?

  • 4
    DoD couldn't change Fortran easily, nor could they change Cobol so they invented Ada for programming and VHDL for FPGAs. If you take out the common features between Fortran and Ada, what you're left with is what the DoD wanted. – cup Aug 28 '20 at 5:41
  • 2
    Mainly FORTRAN lacked reliable fixed-decimal operations. – Hot Licks Aug 28 '20 at 19:33
  • 5
    The committee chair later said COBOL’s fixed-precision operations were intentionally designed to be equally disadvantageous to every computer in the late ’50s. – Davislor Aug 28 '20 at 23:23
  • 2
    My answer (Thanks for accepting it!) sticks to what people who were there said. It’s important, however, to understand why companies such as Burroughs, Raytheon and Honeywell were requesting that the DoD standardize on a common, portable business language. Those companies, who initiated the process, were all competitors of IBM. Their real motive was to ensure that they could compete on a level playing field. – Davislor Aug 28 '20 at 23:30
  • 3
    Having got round to (re-)reading Jean Sammet's contribution to HOPL (everyone needs this book), I am reminded that computers of the era were divided into 'scientific' and 'business' machines, which tended to mean binary versus decimal. Fortran was born on IBM scientific machines; Algol was implicitly a language for primarily numerical algorithms. – another-dave Aug 29 '20 at 21:29

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.

  • 8
    @DavidWaterworth I mean that the other language used characters in its specification that could not be typed on any keyboard or saved in any file (or even to punch cards). Any implementation had to invent its own mapping to the character set of whatever computer it was running on. The designers of COBOL saw that and said, nope. (The designers of APL ....) – Davislor Aug 29 '20 at 6:12
  • 2
    But what was the "existence" criterion? This predated ASCII, and most manufacturers had at least one 6-bit character set which in some cases chose characters to support ALGOL etc. (e.g. the left arrow and single-character inequalities). A few weeks ago I inadvertently attracted criticism since I failed to allow for the possibility that Cambridge's EDSAC computer had the ⊖ character in its character set (and used it as part of its instruction sequences) scifi.stackexchange.com/questions/233847/… – Mark Morgan Lloyd Aug 29 '20 at 9:36
  • 2
    @MarkMorganLloyd Sammet writes on page 218. that it had to be compatible with “existing entry hardware equipment, which at that time was primarily limited to a keypunch. However, we did not entirely have blinders on and recognized that the equivalent of typewriter characters could be used (particularly with paper tape) ....” – Davislor Aug 29 '20 at 12:04
  • 3
    @another-dave The committee had a big fight over whether + and - would be too confusing for business users. They compromised on adding COMPUTE statement that allowed formulas, along with the verbs ADD, SUBTRACT, MULTIPLY and DIVIDE in case those were too difficult to understand. – Davislor Aug 29 '20 at 13:33
  • 4
    Yeah, I knew that's true for COBOL. I was off-topically defending the Algol committee from accusations that they were entirely divorced from knowledge of real devices :-) – another-dave Aug 29 '20 at 13:42

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.