Inventor, Mother, Creator: Grace Hopper

Grace Hopper is often touted as the inventor of COBOL, and for good reason. In 1955, she created the definition of a data-processing compiler and many of the rules that still govern COBOL today. She also created the first working data-processing compiler, FLOW-MATIC.

FLOW-MATIC was the first programming language to express operations using English-like statements instead of symbols without meaning. Getting to an English-based language was a hard-fought battle, however. In a speech later in her career, Hopper described the challenges:

“The entire Establishment was firmly convinced that the only way to write an efficient
The program was in octal…Then, the Establishment promptly told us—at least they told me quite frequently—that a computer could not write a program; it was totally impossible… Sometime in the middle of 1952, I flatly made the alarming statement that I could make a computer do anything that I could completely define.” 

And indeed, she did.

A Short Term Solution

In April 1959, a small group of computer professionals met at the University of Pennsylvania Computing Center. Attendees included Jean E. Sammett, Edward Block, Ben Cheydleur, Saul Gorn, Grace Hopper, Robert Rossheim, and Albert E. Smith.

Their charge was to plan a meeting with users and manufacturers “to develop the specifications for a common business language (CBL) for automatic digital computers.” The intention was to create a short-term, interim language within two years, and then take a decade or so to develop a longer-term solution. They became the “Short Range Committee.”

At the time, three business compilers were already in use – FLOWMATIC, AIMACO, and COMTRAN – but all had flaws. A common language would benefit the private and public sectors by producing the same answers on all computers.

“A language isn’t very useful if you get different answers on different computers,” Grace Harper pointed out. “At least it isn’t to an organization like the Navy, which at any given moment has at least one of every kind of computer.“

One of the most important outcomes of that 1959 meeting was a list of the desired characteristics for the new common business computing language. According to Jean E. Sammet, the group agreed that the language should:

• Maximize the use of simple English language
• Steer away from mathematical problem-oriented language
• Be an easier-to-use programming language, even if that meant it was somewhat less powerful.
• Broaden the base of who could pose problems to – and work with – computers. 
• Be politically and organizationally neutral, unbiased by the existing compiler programs of the time.

At a subsequent meeting in September 1959, the Short Range Committee coined the name “COBOL,” short for Common Business-Oriented Language. COBOL quickly established itself as the backbone of business and financial systems globally. It remains the most widely deployed language for enterprise and government data processing.

Reflecting on that first meeting, Jean E. Sammet said, “I am certainly convinced in my own mind that had the Short Term Committee realized at the outset that the language it created (i.e., COBOL) was going to be in use for such a long period of time, it would have gone about the task quite differently and produced a rather different result.”

Is it Time to Replace COBOL? 

The evolving nature of computer processing and exponential data growth inevitably requires attention and updates.

“Customers come to us to modernise their business-critical applications—not rip them out,” offers Scott McGill, former CTO of MicroFocus. “Clients’ business-critical applications hold deep business intelligence and continue to deliver value every single day. The vast majority of these applications have been written in mature languages, such as COBOL.”

This advice to modernize, not replace, is echoed frequently. As Integrative Systems put it,  “The question here is not COBOL vs modern programming languages, but the strategic utilization of COBOL’s capabilities on your IBM applications. You don’t need to abandon legacy code. Through API enablement and interface decoupling, COBOL applications developers can help build sleek, modern UIs while preserving back-end stability.”

And what about translating COBOL into something more modern, like JAVA? “Translating COBOL [into another language] isn’t necessarily an advantage,” suggests Derek Britton, “A million lines of code in any language is intimidating.”

New in 2025 – IBM COBOL 6.5

In June 2025, IBM released Enterprise COBOL for z/OS 6.5, citing 10 new and improved features. While case studies and real-world results for this fresh version are slim, the benefits of COBOL modernization are well documented. (See Table 1).

Whether Hopper would approve of today’s COBOL is anyone’s guess. But she undoubtedly would recognize its value: a language that works as intended, across all computers, for all types of computer users, bringing value for more than 65 years.