COBOL Leads Us Back to the Future (2015)
informationweek.com
COBOL Leads Us Back to the Future (2015)
1–10 of 25 posts
Re: COBOL Leads Us Back to the Future (2015)
#2It's funny and actually quite important that the title actually says that this is a current article!
Re: COBOL Leads Us Back to the Future (2015)
#31 of 7 pages am I reading this right?
Re: COBOL Leads Us Back to the Future (2015)
#4A discussion I've often had, that old technologies never disappear altogether, there's always an interest, revivals inevitably occur especially among the younger generations to whom the old stuff is new.
Not too long ago I overheard a conversation among a group of college-age artists chattering about the merits of silver-based vs. digital photography. Basically, in their eyes digital was old hat, the familiar way to make images while film photography was intriguing, exotic by comparison.
Of course as a genuine old guy I found their view amusing but refreshing. Having used film, and spending way too many hours in stuffy darkrooms I knew all about the subject. It was fun to talk a bit with a few of the students, but I understood they wouldn't hear it from me. No, they'll have to learn for themselves about the merits and tradeoffs of the old ways vs. the contemporary.
In programming as in all other arts, it's good once in a while to revisit the trails our forbears traversed. We should all travel there as part of an education, it gives us a greater appreciation of what we have now. And sometimes even us old hands will have the urge to revisit the dusty past, though likely choose not to linger there.
Once in a while we should touch ancestral ground, it's a worthy ritual to honor our ancient heritage, lest we forget how far we've come.
Re: COBOL Leads Us Back to the Future (2015)
#5>> 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.
Re: COBOL Leads Us Back to the Future (2015)
#6>> 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… I…
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.
Re: COBOL Leads Us Back to the Future (2015)
#71 of 7 pages am I reading this right?
Yep. There is even a page turn button, no doubt programmed in COBOL.
Re: COBOL Leads Us Back to the Future (2015)
#8What's the daily consulting fee range for COBOL? Would there be a monetary merit to learn it, relative to other "Enterprise Languages" such as Java or C#?
Re: COBOL Leads Us Back to the Future (2015)
#9Oh my, there's even COBOL for iOS! I might have to erect a shrine for the spirit of Grace Hopper after all.
I'm always looking out for an implementation of language X on iOS, and COBOL is not what I expected to materialise there :) Still, it might be fun to play around with — you can never know too much and I'm curious as to how compiler output looks like (though I probably won't see that on iOS).
Re: COBOL Leads Us Back to the Future (2015)
#10What's the daily consulting fee range for COBOL? Would there be a monetary merit to learn it, relative to other "Enterprise Languages" such as Java or C#?
Most production COBOL programs run on IBM compatible mainframes so you'd also need to get a handle on developing in MVS aka "z/OS" and how to hack JCL config scripts--the horror! That's difficult to do without getting hands-on experience.
As someone whose first job out of uni almost 20 years ago was in a mainframe environment, I have no desire whatsoever to go back to it and would strongly recommend against working in COBOL if you can make a living using tech that was developed in the last 40 years.