References for the complexity of the COBOL language

Question

One thing that struck me about the design of COBOL was that it was surprisingly complex, particularly for the era. As in, if I were trying to squeeze a compiler into a few tens of kilobytes of memory, I would be unpleasantly surprised by the number and diversity of features that had to be implemented.

I never saw this remarked on until today, when I stumbled on 10 Most(ly dead) Influential Programming Languages:

COBOL was also enormously complex, even for today’s languages. This means that COBOL compilers lagged contemporaries on microcomputers and minicomputers...

And so they did; there was a generation of microcomputer business software, that would classically have been expected to be written in COBOL, that was actually written in BASIC instead. Now, there were a number of reasons for this, such as microcomputer programmers first learning BASIC because it came with the machines, but the above quoted reason seems likely to also have been a factor.

Are there any references for the complexity of COBOL? Either quantitative (e.g. measurements of the size of a COBOL compiler at a given time, compared to compilers implemented with the same technology for other languages), or firsthand accounts of the difficulty of implementation?

It might be helpful if you could specify what you mean by 'complex' ? To my knowledge (somewhat limited, as I usually converted COBOL to Assembler :)), COBOL isn't complex at all. in fact it's made in a way to allow rather straight forward translation on the go. That is, at least up to COBOL-74 maybe even C85 though that added real new ideas. Could it be that people get confused by the high number of keywords? Most of them are just syntactical sugar enabling readability by being a kind of narrow formalized English. — Raffzahn, Dec 27 '22 at 14:07
@Raffzahn In this context, by complex, I mean that a compiler for the language will tend to be large, i.e. consist of many kilobytes of code, thereby having difficulty running on small machines. Are you disagreeing with the above assessment and taking the view that though there are many keywords, the language translates straightforwardly to machine code, and a compiler for it should therefore be small? — rwallace, Dec 27 '22 at 15:35
The first thing that comes to mind (at least for me) with COBOL is not exactly complexity. Chattyness I would agree, yes, but complexity? — tofro, Dec 27 '22 at 17:18
@rwallace Exactly. Or as Tofro puts it 'Chatty'. Just look at a COBOL program .and not ... _well, this doesn't fit into a comment, let me put it into an Answer. — Raffzahn, Dec 27 '22 at 18:21
I programmed in Cobol for nearly 20 years so I am a bit jaded, but I don't consider the language all that complex. But it is probably very complex for a compiler writer to adhere to the extremely detailed definition of the Cobol standard, which came out of a committee with huge and varied interests, like government. Much complexity is not the language itself, but the runtime. A "READ" verb has to handle sequential, relative, and indexed files for example. I learned on a PDP-11 with 32k with 20 terminals, but realistically only one person at a time could compile a Cobol program. — mannaggia, Dec 27 '22 at 20:37
At least two companies - Micro Focus and Ryan-McFarland - produced COBOL compilers for micros starting with 8-bit CP/M systems. I supported an accounting package (Paxton Business Desk) written in COBOL for CP/M and DOS in the mid-1980s. — grahamj42, Dec 27 '22 at 22:10
@mannaggia "But it is probably very complex for a compiler writer to adhere to the extremely detailed definition". quite the other way, the very fine detail of definition simplifies compiler construction. COBOL relays on clear data definition which in turn allow straight code generation. There isn't much leeway to screw that. — Raffzahn, Dec 27 '22 at 23:43
I used MicroFocus Cobol at British Rail in the early 90s. The thing about the Cobol complier that I most recall is that it is single-pass and so you can't do recursion. (I used to say - "you may curse, but not recurse!") — kpollock, Dec 28 '22 at 08:22
@Raffzahn: I would also guess that although COBOL is verbose when written as text, programs would never be edited within RAM as text, but would instead be edited off-line using a keypunch. — supercat, Dec 28 '22 at 21:02

score 27 · Accepted Answer · edited Jan 08 '23 at 19:08

No, COBOL is not complex and didn't require complex compilers.

At least not for COBOL up to 74 (*1) which was the standard at the time of introduction of micros (mid 70s to late 80s). From the compiler's angle, it's straightforward, which should result in comparably small compilers. Though, it got some 'Chattiness' as Tofro calls it, by having many, sometimes even redundant keywords as well as high level features, which both may be mistaken as complexity.

It's also fundamental to keep in mind that COBOL wasn't created as some academic exercise, but to solve real world tasks with real world machines, in the late 50s this meant computers with usually less than 64 KiB and only the most basic OS

Next COBOL isn't one of many languages, but an early one, its concepts are not shaped by what we take as canon today. Today we tend to see programming languages as a primitive core providing certain, almost standardized constructs coming out of an ALGOL tradition (further simplified by C). COBOL wasn't created in that tradition. Like Will Hartung notes, COBOL has way more in common with application specific (4GL) languages. No surprise, it was designed as a language for data processing. Much the same way FORTRAN was done for computing.

A Language Made for Simple Compilers

Other than one may assume, COBOL is an extremely easy to translate language, not at least due its simple and straightforward structure. A program always has to be written in a specific order, easing translation. It runs a bit like this:

Identification Division

It essentially contains just the program name. Everything else is formalized documentation. Useful to have, nothing the compiler needs to care for (*2)
Environment Division

Configuring the compiler.

Essentially what today's compilers get handed via endless numbers of hard to decode command line options. COBOL has it nicely hedged up in a machine independent format. No need to invent anything, just parse it.

It contains basic items like compile with debug support (*3), target computer, disk space, character set, special character (like currency sign or separators) and so on in its Configuration Section.

The Input-Output Section, in turn, describes what files are to be used and how they are accessed - think of it like the definition of a database connector - which in fact it can as well contain.
Data Division

It defines, much like the name says, all data structures, as there are
- Record structures for
  - files,
  - databases and
  - communication
- Global data (which as well can be structured)
- Exchange structures between routines
- Report data
- Screen Data
Especially the latter two might be notable, as COBOL provides a nice, device independent way to describe printout and screen handling. No need to dig thru hundreds of lines of PRINT or write() to decode what is outputted when. COBOL takes care of all printer and screen handling much like file I/O. One simply fills all fields (usually with a single MOVE CORRESPONDING) of a print or screen definition, and COBOL does everything else. Including line counting, page control, etc.

Most other languages (4GL not so much) can do similar only with additional report generators which usually have extreme 'notable' structures, made to somehow fit. For COBOL it's built in with the very same syntax as any other structure.

For a compiler writer all so far is fast food easily swallowed. Each of these Divisions and Sections can be turned straight into memory tables to be later used to generate addresses, as well as reserve storage within the compiled program.

Only after all is said and defined, the code itself follow:

Procedure Division

COBOL code is extremely strict forward, not least as it doesn't know much of the flow control other (ALGOLic) languages offer. All statements are sequential and there is, except for nested IF, no need to keep track of any structure. Just label names. All program flow (*4) is handled by GO TO and PERFORM.
- Go to is just that, execution will be continued at the label given.
- Perform fills two function
  - calling of subroutines and
  - creating loops around subroutines.
That capability of PERFORM is exactly the clue for compiler design that takes away next to all complexity of code generation in other languages:
- In the case of a simple subroutine call, it records the return address and jumps ahead to that label.
- In case of a loop like PERFORM routine-1 n TIMES (*5), or any other variation, the same subroutine calling but now part of a looping code block is done. All can be turned straight into assembler or machine code, without looking at any structure level or noting to place the loop ending code after an unknown number of statements.

Long story short:

COBOL was designed with straight compilation in mind, something very basic and thus short compilers can deliver. But it comes with mighty tools, which have to be offered by the OS, or other runtime.

Why not on Micros?

Interesting question. COBOL was quite available on early micros, for professional systems, but also low end CP/M. E.g. as Micro Focus CIS COBOL. It also has been used quite a lot. So why are there so many BASIC applications? One may think of 3 reasons:

(Business) BASIC was already a force on low end machines - just think about HP or Olivetti and even more MAI and WANG. Especially the latter had a strong standing in low end business systems, offering BASIC at very high integration level.
Infrastructure. COBOL takes a lot of its abilities from integration with sophisticated file systems. Random access record access, variable length records, indexed access and databases are nothing systems like CP/M or other lowest end micros offered by default. So either the COBOL had to come with those access layers included (*6), or additional Packages were needed.
'The English Publisher issue' (*7): Micro Focus (et al.) requested premium prices for their compilers, resulting in comparably few sales. Their idea was that COBOL is something for companies porting their smaller and/or client applications down to minis/micros. They got the money to pay more for a compiler than a computer, so let's milk 'em.

Then again, in all fairness, already back then everyone was preaching COBOL as a dead end and gone even before the '80s could develop a style of their own. So a 4th reason was that no company really saw a need nor a motivation to spread COBOL knowledge and support to a new generation of programmers.

Some more details

Chattiness ...

COBOL was meant to be readable, thus many of the keywords are redundant or have alternate spellings. A great example is the VALUE keyword used to define test values for fields.

Let's assume a stock record has a field containing a marker telling if that item is to be delivered virtual (delivered via e-Mail), as single mailing or can be collected with others - coded as V/S/P. In most languages, one would do some equates or defines and a series of IF to check. COBOL allows such to be nicely defined as part of data definition and checked in a quite readable fashion.

       01  delivery          PIC X(01).
           88  deliver-virtual  VALUE  "V".
           88  deliver-physical VALUES "P", "S".
           88  deliver-valid    VALUES "P", "S", "V".

VALUE and VALUES is exactly the same keyword and interchangeable. Neither implies that anything different. Just syntactical sugar for readability.

... or Not

In fact, 88 type Condition Names, as they are called, make a great example of COBOL being way less chatty and more high level than other languages:

   IF NOT deliver-valid THEN SET deliver-valid TO TRUE. (1,2)
   IF deliver-virtual THEN PERFORM delivery-per-mail. (3)

Quite readable, isn't it?

#1 checks if the record got a valid marker, so any of P/S/V. If not, #2 sets it to the default way of collecting packages (the first value given). #3 performs a virtual delivery if needed. Heck, I have a hard time describing the workings other than the COBOL code already does.

Instead of 'Chaty' it might rather call it sophisticated - or posh if one likes.

Now try the same in C.

Small Computers

While COBOL was from the beginning made with strong data I/O in mind, including high level access of streaming data as well as random and indexed, it was meant to run on small machines. Around 1960 a computer with 128 KiB was considered quite large. So any compiler had to be made in a way to fit in considerably less - plus leaving space for OS and I/O. Not much different from later micros, isn't it?

It's Not ALGOLic but Really Early

While officially presented a year after ALGOL (1960 vs. 1959), COBOL is in no way influenced by it. It doesn't know a stack, it doesn't need one, and, on top, some of its constructs simply won't work with a stack - at least not without issues. The non-availability of the stack idea and COBOL being built on programming styles before that can not be underestimated.

It's Not Minimalist

ALGOL, and all its decedents, are based on the idea of providing a rich structure with as few different components as possible and having them as uniform as possible. All with a goal to be as universal as possible offering all flexibility to have. COBOL is anything but minimalist.

COBOL means Serious Data Shoveling

In contrast, COBOL is a rich language made for data shovelling. Nothing else, but that really good. COBOL is perfect for example to write data driven applications. Things like

Application front end for a database,
Order booking,
Order fulfilment,
Part lists,
Receipts printing,
Bank statements,

or anything else in accounting and data management often needs only a few program lines. Well, that and a description of the data structures handled - which in turn was usually just included via COPY.

Real world COBOL sources are more often than not shorter than the same task coded in C or any other language (maybe except RPG). Such programs for the most part just say 'MOVE CORRESPONDING' between input and output, maybe add up a few values, multiply VAT and check for exception/ed condition. That's it (*8).

*1 - For most parts this includes COBOL-85, although 85 did also introduce (useless) new features that made compilers more complex, like inline perform (i.e. loop content no longer needed to be a dedicated routine) or scopes used for multi statement IF and nested subroutines. Bah. No one needs that!

*2 - Well, if a DATE COMPILED. sentence is present its comment will be replaced by the actual compile date in the listing.

*3 - Who doesn't remember endless #IFDEFs and debug macros in C? Well, COBOL got the same, except, more structured. By placing a D in column 7 any source line can be declared debug code. They get only compiled if debug mode is enabled in the Configuration Section of the Environment Division. All standardized. No need to learn whatever macros a programmer of a certain file invented for their debug strategy.

*4 - There are further variations, but none change the basic handling. Just adding more linear code blocks.

*5 - Again this plural variation like with VALUE, one can write TIME or TIMES, all to satisfy a more natural sounding source code.

*6 - Well machines that offered ISAM files and so on were exactly the ones by MAI and WANG which did run their Business BASIC variants - so why use COBOL for new developments?

*7 - Copyright in England of the 18th/19th century was about the major hurdle for readers and writers, as publishers used it to get highest possible profit per book sold, resulting in high sales price and quite small print runs. One of the reasons why the US (which didn't honour English laws) and Germany (whose states not even recognized each others) became a mecca for readers - cheap books resulting in widespread knowledge. In addition, a goal for English authors, who were more interested in getting a fast overseas publication with high volume and good returns than seeing their books nicely printed but no income.

*8 - Well, this that's it of course relies heavily on a good data definition first.

Davislor · Answer 2 · 2022-12-28T19:12:20.640

I would highly recommend Jean E. Sammet’s “Early History of Cobol” for this. She was the chair of two of the committees that developed COBOL, and served on a third.

(If I might take a moment here to debunk a very widespread urban legend: although many other women had a direct role in the development of COBOL, Grace Hopper did not. Sammet credits Hopper with having published the concept of “verbs” and “nouns” in computer programs in 1955, pointing the way toward a definition of a data structure separate from the program code. Hopper also served as one of the “advisors to the Executive Committee” of CODASYL, which voted to begin the project. Sammet describes this executive committee as “not directly involved with the technical creation of COBOL.” The committees doing that work submitted reports on their progress to the Executive Committee. Hopper did write FLOW-MATIC, one of the precursors to COBOL, and another, AIMACO, was based on her work.)

According to Sammet, people began complaining that the language was too complicated as soon as the committee on statement syntax had met, and gives the first documented example of this complaint:

During the August 17–19[, 1959] meeting, there was a great deal of discussion about the validity, usefulness, etc., of what the committee had done so far. Some people felt it showed much too much the result of a design by a committee and embodied too many compromises. Others felt it was better than the three main existing languages which had been considered [...] Some people felt the new language had gone too far, i.e. was too complex (e.g. subscripts) whereas others felt it was too simple (e.g. lack of formulas). Considerable discussion centered around the idea that each manufacturer might implement only a subset; this concept was discarded because of the recognition of what that would mean for portability (although that word was never used).

One reason Sammet gives for this was

While much technical work was going on, the politics were not buried. Because this was probably the first attempt by competitive computer manufacturers to work together for a common goal, the marketing considerations of all groups were extremely relevant. [...] All said in essence that they would implement this new language “but”—and then each manufacturer had some constraint to go along with the “but.”

One example of this comes to mind, because another answer claimed the differences between COBOL and Fortran were because of the differences between scientific and business computing. There’s some truth to that, but Semmet openly confesses that, no, they intentionally did everything differently from how IBM did it because of corporate politics. Most members of the committees were IBM’s smaller competitors, and they saw COBOL as their chance to catch up to IBM’s advantage in the marketplace. So, straight from the horse’s mouth:

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.

I love that COBOL was considered 'anti-IBM'. In the 80's, IBM was one of the biggest proponents of COBOL, with it on almost every platform and the backbone of CICS. — Jim, Dec 28 '22 at 15:45
@Jim The original idea was that the US government did not want to get locked into buying IBM forever, so they’d get “IBM and the Seven Dwarfs” to all use a single, portable language. But then those companies all failed anyway, so IBM ended up with a residual niche that it dominated, and new competitors that used completely different technologies. — Davislor, Dec 28 '22 at 19:11

score 15 · Answer 3 · answered Dec 27 '22 at 16:11

If you want to catch a glimpse of the implicit complexity of COBOL, I suggest taking a quick run through these GnuCOBOL syntax diagrams.

The reason that COBOL is complex is that COBOL is not simply a framework of basic computation, like modern languages are.

By that I mean that things like C and its ilk are designed to write programs for many tasks. C et al provided fundamental computing constructs (functions, data structures, iteration, etc.) upon which any program can be built.

COBOL, on the other hand, is much like what were termed "4GLs", "Fourth Generation Languages". A language designed to facilitate business computing. Specifically it was a language designed to process records of data, and then create reports. Later it embedded an ISAM database layer upon which to build applications.

These are "built in". In C, "nothing" is built in. Sure, these like "printf" are common, but, particularly early on, things like "printf" were simply part of a library. They were not part of the language per se.

Consider Java. Java is certainly not a simple language, but users don't struggle so much with the Java language itself. Rather they struggle with applying the enormous standard library, much less that vast 3rd party options.

COBOL has all of that built in, it's not just a framework that dumps all of the heavy lifting on to external libraries.

Informix 4GL had the common language constructs folks are used to, but also had syntax for screen forms, reporting, as well as the entirety of SQL. All of this makes the language much more complicated.

Good old Informix 4GL... I worked for a company that had a large base of Cobol code, and we went down a path of rewriting some of it in Informix 4GL. It didn't go well. We ended up staying with Cobol and ripping out most of the file I/O and replacing it with embedded SQL. That actually worked pretty well - Cobol then was like a 4GL - it was used to manipulate the data, almost like a stored proc language. Later on we used the FourGen code generation tools for Informix 4GL and wrote a few apps from scratch using that - it made it more tolerable. — mannaggia, Dec 27 '22 at 20:43
I did a lot of Informix and FourGen. I loved FourGen, it was an extraordinary tool. — Will Hartung, Dec 28 '22 at 15:54
FourGen really did make Informix 4GL much better. Some sketchy things went on with the company near the end of my time using it and I lost track of it. Interestingly, there are still remnants of both products around. After IBM acquired Informix, not much happened, then FourJ's came out with a source compatible product, then I think IBM acquired it, then orphaned it and it's back with FourJ's (http://4js.com). Another company Fitrix has the FourGen case tools that work with FourJ's. (https://fitrix.com/about-fitrix/case-tools) — mannaggia, Dec 28 '22 at 21:32

score 6 · Answer 4 · edited Dec 27 '22 at 19:41

6

Four major language developments of the 1950's were Fortran, COBOL, Lisp, and Algol. Comparing just Fortran and COBOL, one could say Fortran was adapted for scientific data processing while COBOL was adapted for business data processing.

Science tends to do very complex processing on very simple data. Business tends to do very simple processing on very complex data. This is why the languages have some of the features they have. The data definition tools built into COBOL allow for a wide variety of types of data, and that is what adds to the size of a COBOL compiler and of the run time system.

Fortran, by contrast, has very rich features for expressing arithmetic expressions, but fairly weak tools for expressing character strings. Even something as simple as 'Hello' would have initially required something like 5HHELLO in Fortran. The requirement that you count the characters becomes terribly onerous when you start to do a lot of string manipulation.

BASIC was a little weaker than Fortran in arithmetic expressions, and somewhat better than Fortran for string manipulation. It also shifted some of the computer load from the compiler to the run time system, making it more feasible to port it to microcomputers.

As far as the history of COBOL goes, look up the role played by Grace Hopper. She had more to do with the architecture of COBOL than anyone else. Part of her vision was that COBOL programs should be self-documenting. That is, for every programmer that could write COBOL programs, there would be about ten business analysts who could read those programs, and compare with business requirements.

edited Dec 27 '22 at 19:41

Tim Locke

4,811
21
36

answered Dec 27 '22 at 14:01

Walter Mitty

6,128
17
36

5

An important feature of COBOL, lacking in other languages, was the ability to have compile-time-parameterized fixed-point data types. If one writes a statement like a = b/c+d/e; and all objects are the same floating-point type, a compiler can simply use the same type for the intermediate value and hope it's good enough, but when doing fixed-point math that will often not be ideal. In business calculations, it's necessary to know precisely what rounding will be performed at every stage of a process. If one writes akin to "divide b by c. divide d by e. add b to d"... – supercat Dec 27 '22 at 18:28
1

...then each operation will be rounded according to the rules of the destination types involved. As for wordiness, many environments had 48-character keypunches whose range of symbols was far less than would be available in the 96-character ASCII set. – supercat Dec 27 '22 at 18:31
1

Thanks @supercat. The ability add and subract dollars and cents amounts without worrying about cumulative rounding errors was crucial to Cobol's useability. There has been more than one programmer initiated heist that involved stealing partial pennies enough times to make it worthwhile. – Walter Mitty Dec 28 '22 at 13:01
I find it interesting that some frameworks like .NET include floating-point decimal types like the Decimal, but fail to recognize that the problem with binary floating-point for financial applications isn't that it's binary, but that it's floating point. Moving to decimal floating-point makes things slower, but doesn't solve the fundamental problem. – supercat Dec 28 '22 at 13:14
@supercat Of course does it solve the problem - in the way that with decimal FP the number of valid digits is always the same, thus easy to incorporate, unlike binary. – Raffzahn Dec 28 '22 at 16:43
@WalterMitty I'd way it's rather due the /360 being offering decimal arithmetic with defined number of digits - and COBOL supporting this, not the other way around. – Raffzahn Dec 28 '22 at 16:45
@Raffzahn: With a fixed-point decimal type, adding and subtracting the same number to/from any other will either yield the original number or an overflow trap. With Decimal, it's possible for silent round-off to occur. For example, if x is 0.333333333333333333, x+1000000-1000000 would yield 0.333333333333. One might hope the round-off errors would be small enough not to matter, but if performing a computation perfectly would yield an odd number of half-cents, any rounding error, no matter how small, could cause an off-by-a-penny error. – supercat Dec 28 '22 at 17:24
1

@Raffzahn: Further, the design of COBOL helps avoid the need for any imprecise calculations by allowing e.g. DIVIDE TOTALBILL BY PEOPLE GIVING PERPERSON REMAINDER EXCESS. So if TOTALBILL is $20.00 and PEOPLE is 3, then PERPERSON would be $6.66 and REMAINDER would be $0.02, thus allowing every penny to be accounted for. – supercat Dec 28 '22 at 17:33
1

@Raffzahn: Even without any hardware support for decimal computations, reading many strings of digits and computing their total as a string of digits will be faster than converting each string of digits to a binary integer (or worse, floating-point value), adding up all the resulting binary values, and converting the result back to a string of digits. Unless machines included binary math support to facilitate format conversions, hardware support for COBOL-style math would have come after the language made such an approach to computation popular. – supercat Dec 28 '22 at 17:49

score 4 · Answer 5 · answered Dec 31 '22 at 03:01

TL;DR Early business computers were decimal-based reducing run time requirements. The structure of COBOL: division, section, paragraph, etc., allowed programs to be compiled in parts. COBOL source statements for subset implementations were kept as simple as possible (allowing pattern matching) to minimize resource requirements. Additional features and enhancements have greatly increased the complexity of the language, since.

Any discussion of the complexity of the earlier COBOL standards (68, 74 and 85) must take into account that the standards were described as 12 modules, each with two levels of implementation (except Report Writer, which had only one). Further, the standards allowed for full, intermediate and low implementations for meeting conformance requirements. The lower level of implementation for a module removed elements from the full standard in order to reduce complexity (and resources).

The minimal (or low) implementation used the lower level of just three modules: NUC, TBL, and SEQ (nucleus, table handling, and sequential input-output). Further, statements only needed pattern matching for parsing, there were no arithmetic expressions, for example. Also, the earliest computers, for which COBOL was implemented, were based on decimal, which simplified run time requirements.

As an implementor added modules and moved to the higher level for the modules, naturally, the complexity increased. For example, SEG (segmentation) and IPC (inter-program communications) would require the implementor to use demand paging at run time, even on computers without virtual memory.

When the 2002 standard was created, the first step was to incorporate all the separate modules, at the high level, into a single standard. Some obsolete features were removed from the 85 standard, but with the addition of object-orientation and some other features and enhancements, complexity rose a great deal. For SAME AS, TYPE, and TYPEDEF, multiple passes over the entire DATA DIVISION may be required to resolve all references. The 2002 standard was rarely implemented. With the 2014 standard, some of the features were made optional and resulted in greater acceptance.

Q: Are there any references for the complexity of COBOL?

I recall reading, after the release of the 2002 standard, but have been unable to find the reference, a claim that C++ had become as complex as COBOL. I don't know how much credence to give that statement, but it seems to suggest, by comparison, greater complexity in modern COBOL. I see no reason to disagree.

Note: When I was doing embedded programming in assembler on a Motorola 6800, I would sometimes use the subset language of COBOL 74 to structure the code. There was an almost direct translation from COBOL to assembler for the few places and instructions where I did so. These involved PERFORM, MOVE, and IF, mostly.

Even on a machine without special decimal hardware, I would expect that the amount of time many COBOL programs spend performing digit-at-a-time arithmetic is less than would be required to convert groups of digits into binary integer values, perform arithmetic upon those, and then convert the results back to decimal digits. — supercat, Jan 08 '23 at 19:56

score 3 · Answer 6 · answered Jan 05 '23 at 00:44

There was nothing very complex about COBOL and I taught it to many people from the business who had no mathematical or technical background. The original statement here is simply wrong; there were compilers for COBOL that ran on PCs right from the early 1980s when PCs became available.

COBOL eveloved in a different world than is currently the case and it used a different paradigm (sequential, procedural processing vs OO). It was ideal for batch processing and that was what it was developed for. COBOL was running BEFORE screens and disks were invented! The first IBM compiler I used was for COBOL 61 running under TOS (Tape Operating System) on an IBM mainframe. We used punched cards and paper tape for input and printed the results on green lineflo...

I don't believe you'll find a single COBOL programmer who would agree it is a "complex" language. It certainly was verbose, but that was touted as making maintenance of it easier (It didn't...).

I loved using it and made a living from it for nearly 30 years.

score 0 · Answer 7 · answered Jan 05 '23 at 10:09

COBOL had a lot of syntax, and some very powerful instructions and data types (particularly for string handling) that I still miss today, but by leaving out pointers, recursive functions, dynamic memory allocation, etc, a lot of the complexities of compiler writing were avoided. So it all depends what you mean by "complexity".