Talk:COBOL

English like?

It's hard to reconcile the description of COBOL as English like with, e.g., the use of the magic numbers 77 and 88. Shmuel (Seymour J.) Metz Username:Chatul (talk) 02:13, 4 January 2021 (UTC)

That was just a naive guiding line in its design. A very bad decision based by the stupid idea that managers can't understand a formulas like "TAX = TOTAL * TAX-RATE" so they had to use "MULTIPLY TOTAL BY TAX-RATE GIVING TAX". I don't understand why they had such belief about business managers. Any manager does a lot of computations for the accounting system, financial projections, etc. But the COBOL designers believed that people working in business management could never understand elementary arithmetic notation. That resulted in one of the worse programming languages ever designed. It is closer to assembly language with MOVE X, Y and ADD X Z and so on, instead to really be a higher level (of abstraction) language.

Today there is a huge amount of legacy code not just written in COBOL, but ill structured, and there are very few COBOL programmers. COBOL programs can be translated to other languages, that is a relatively easy thing to do, but that does not improve the readability of programs and is more likely to introduce "bugs". — Preceding unsigned comment added by 201.137.173.23 (talk) 22:33, 2 July 2021 (UTC)

PERFORM does not promote modular programming

PERFORM is like GOSUB in BASIC, that does not promote modular programming. It promotes to divide de program in sections like additions, deletions and changes, very common in batch processing. That is not modularity. The lack of modular programming is the main problem of COBOL, it has PROCEDURE DIVISION USING to declare subroutines, but its verbose style, even using COPY files (similar to #include in C) is not easy to use. For that reason the statement "which promoted modular programming" may be changed to "which promoted to divide the program in sections" could a be better choice, but that can be confusing because SECTION is a keyword in COBOL which refers to a subdivision of DIVISION. Maybe "which promoted to divide the program in parts" could be better.

"GO TOs were largely replaced by the PERFORM statement and procedures, which promoted modular programming[154] and gave easy access to powerful looping facilities. However, PERFORM could only be used with procedures so loop bodies were not located where they were used, making programs harder to understand.[155]"

66 RENAMES were not forbidden as said citing McCracken book

The article say:

"A level-number of 66 is used to declare a re-grouping of previously defined items, irrespective of how those items are structured. This data level, also referred to by the associated RENAMES clause, is rarely used[127] and, circa 1988, was usually found in old programs. Its ability to ignore the hierarchical and logical structure data meant its use was not recommended and many installations forbade its use.[128]"

That seem wrong to me, because the level 66 RENAMES corresponds to union in C and Pascal's variant records. It was used very often in old COBOL programs because data files were usually pouched in 80 column cards. Records larger than 80 chars where stored in several cards, using a record id and one column to mark which part of the record it has. Even today many programmers ignore how to use unions, but that is not a dangerous feature of any language that ought to be forbidden as is attributed to the book by McCracken.

I don't have that book to corroborate that. Other book by McCracken about numerical methods in Fortran was very popular in that time, I don't have it neither, maybe those books were written before structured programming became a standard. By 1988 it was broadly accepted to write structured programs and OOP started to gain popularity, but many programmers were still using data flow diagrams which incentive undisciplined use of GOTOs, and were reluctant to use structured pseudocode, particularly by programmers out of academy.

GA concerns

After reviewing this article, I am concerned that it no longer meets the GA criteria. My concerns are listed below:

• The lede is several paragraphs long with lots of information added since it passed GAN in 2015. Can this be formatted to better conform to WP:LEDE?
• The "COBOL 60" section is quite bloated: while it was large when it passed GAN in 2015, it seems to have gotten larger since then and contains many short paragraphs. Is anyone interested in reducing and/or removing information?
• There is some uncited information.

Anyone interested in fixing up this article? If not it might be nominated to WP:GAR. Pinging the GAN nominator @EdwardH:. Z1720 (talk) 01:23, 26 May 2024 (UTC)