6 ms·

>> The next reason is readability. COBOL is known as a "verbose" language, especially when it's compared to a very terse language like C++. From a debugging sta

>> The next reason is readability. COBOL is known as a "verbose" language, especially when it's compared to a very terse language like C++. From a debugging standpoint, COBOL can be like reading a novel: In fact, I'd almost bet that, with a few variables thrown in, you could get arbitrary chapters from Game of Thrones to compile. Of course, all your favorite functions would die depressing, lonely deaths, but still… In a way, this verbosity of which he speaks is the antithesis to the current 'Learn to Code' fad. And COBOL is a perfect example of a language that was intended to be so easy and intuitive to read and write, business people could do it (as it was promoted in the early years). COBOL has sections, paragraphs, and sentences, verbs and variables are nouns. Control flow is either via goto or 'perform'ing paragraphs or sections. Awesome in theory, for simple programs, the idea that anyone can write/read it may even be true. But the devil has always been in the details. Logic in the perform/goto world quickly spirals out of control/comprehension, and for any non trivial COBOL application, there are multitudes of programs, flat files, indexed files, etc. Not to mention the complexity of batch cobol (if you haven't lived the horror of mainframe JCL, I envy you) and wiring together green screens in the CICS environment are all very involved, the definition of platform specific. >>The first reason is employability. As noted, there are still plenty of companies running applications built on COBOL. And not all of those applications are archaic: Since 2002, COBOL has had an object-oriented framework. And most of them have off shored most or all of their development. One prominent local employer of COBOL programmers has a skeleton crew of COBOL developers after once employing thousands. Additionally, I'd have to see some stats that anyone has upgraded to the 2002 standard to believe anyone is actually using object oriented COBOL in production. Having said all that, COBOL was designed in a time of scarce resources and does make excellent use of system resources. COBOL is close to the metal in a way that C is not; COBOL is more like verbose assembler than C. In COBOL all storage is statically allocated (memory allocation is possible, but not typical), and there is no call stack. This mean COBOL programs never experience stack overflow exceptions, out of memory errors, buffer overflows. Characteristics that make it 'safe' from a security and multi tenancy perspective.

erikb 11y ago
I'd also say that the article actually shows why COBOL is not that big a thing anymore. Yes, there is still COBOL hardware and there is still COBOL software. But there are not really any signs of COBOL growing. It's more likely that it slowly gets replaced by Java. And one argument for that is shown there as well: There are already compilers that transfer your COBOL code to Java and people might use that in production to slowly transform to Java. I can agree that there will still be COBOL in 50 years, but the impact becomes smaller every day. Building a career is a thing of 25 years + 5-10 years of education. You can't build that around a technology that is dying already for a decade or two.
kyllo 11y ago
*I'd have to see some stats that anyone has upgraded to the 2002 standard to believe anyone is actually using object oriented COBOL in production. My employer actually still uses HP 3000 COBOL, even though the HP 3000 boxes are long gone. We now run on top of AMXW[1] and Ti2SQL[2] which are like mainframe emulator frameworks, so that we can execute 35 year-old COBOL code on UNIX hardware and a SQL database. No point in upgrading it to COBOL 2002. We're porting it to Java instead. [1] http://www.freschelegacy.com/en/data-sheets/amxw-one-stop-solution-automated-migration http://www.freschelegacy.com/en/data-sheets/amxw-one-stop-so... [2] http://www.ordat.com/en/solutions/tisql/ http://www.ordat.com/en/solutions/tisql/
Roboprog 11y ago
Good summary, particularly the last paragraph. Consequences of this include using flat files in place of "heap" storage, and using JCL to chain together individual programs where newer languages would likely just have subroutines, classes or other separately compiled-but-linked modules. Disclaimer: I worked for a company in the early 90s that made products to port (System/36 & AS/400) RPG + OCL to unix (and a few other) systems. We used C, rather than Java, as the target for cross compiling, but same sorts of ideas.
agumonkey 11y ago
From the few that I gathered working on it, COBOL seems a good fit for `awk` like logic. Simply linear structured work leveraging the record based FS. And quite often, people tried to add a transpilation layer to have some sort of SQL JOIN on top of COBOL files, in vain.
acheron 11y ago
I was in college when the object-oriented COBOL standard was released -- my software engineering professor at the time mentioned it in class one day and made the (obvious) joke that it should have been called "ADD 1 TO COBOL."
- Luyt 11y ago
  The next step is obviously 'functional COBOL'.

erikb 11y ago

I'd also say that the article actually shows why COBOL is not that big a thing anymore. Yes, there is still COBOL hardware and there is still COBOL software. But there are not really any signs of COBOL growing. It's more likely that it slowly gets replaced by Java. And one argument for that is shown there as well: There are already compilers that transfer your COBOL code to Java and people might use that in production to slowly transform to Java. I can agree that there will still be COBOL in 50 years, but the impact becomes smaller every day. Building a career is a thing of 25 years + 5-10 years of education. You can't build that around a technology that is dying already for a decade or two.

kyllo 11y ago

*I'd have to see some stats that anyone has upgraded to the 2002 standard to believe anyone is actually using object oriented COBOL in production. My employer actually still uses HP 3000 COBOL, even though the HP 3000 boxes are long gone. We now run on top of AMXW[1] and Ti2SQL[2] which are like mainframe emulator frameworks, so that we can execute 35 year-old COBOL code on UNIX hardware and a SQL database. No point in upgrading it to COBOL 2002. We're porting it to Java instead. [1] http://www.freschelegacy.com/en/data-sheets/amxw-one-stop-solution-automated-migration http://www.freschelegacy.com/en/data-sheets/amxw-one-stop-so... [2] http://www.ordat.com/en/solutions/tisql/ http://www.ordat.com/en/solutions/tisql/

Roboprog 11y ago

Good summary, particularly the last paragraph. Consequences of this include using flat files in place of "heap" storage, and using JCL to chain together individual programs where newer languages would likely just have subroutines, classes or other separately compiled-but-linked modules. Disclaimer: I worked for a company in the early 90s that made products to port (System/36 & AS/400) RPG + OCL to unix (and a few other) systems. We used C, rather than Java, as the target for cross compiling, but same sorts of ideas.

agumonkey 11y ago

From the few that I gathered working on it, COBOL seems a good fit for `awk` like logic. Simply linear structured work leveraging the record based FS. And quite often, people tried to add a transpilation layer to have some sort of SQL JOIN on top of COBOL files, in vain.

acheron 11y ago

I was in college when the object-oriented COBOL standard was released -- my software engineering professor at the time mentioned it in class one day and made the (obvious) joke that it should have been called "ADD 1 TO COBOL."

Luyt 11y ago
The next step is obviously 'functional COBOL'.