A 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.
Computing actually has a very chaotic evolution compared to other fields. Where most can be seen as linear progressions, computing is heavily prone to stasis and regressions.
Revisiting ancestral ground in programming actually makes you think how little we've come, not how far.
Although my self-teaching of programming began in Python it ended up veering through Racket and Smalltalk. I almost regret learning Smalltalk after experiencing what a joy it is to program in. Writing a webapp in Seaside, with all of its great features for live inspection and debugging, and then experiencing Django and Node was an eye opener.
>>>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.
Yeah. I really like the way you put this, and would add...
There are merits in the past ways of doing things. Here's a simple, non software related example:
Unfolding sheet metal parts. This basically is calculating the flat sheet shape needed to produce a bent part of the proper dimensions. Metal stretches when bent, meaning the flat shape is not a 1:1 representation of the 3D bent part.
Modern software does this with solid models. We make the part we want, and then the software produces a flat pattern for us. While this process is very simple, it does require one to have software, model in solids, and so forth...
What gets lost here is the actual dynamics of the metal.
Further, the analytic geometry methods go unused in most modern solutions, which actually makes unfolding more complex, organic shapes difficult and CPU intensive as they get broken down into polygons...
Don't get me wrong, much is gained too. Analysis, ability to work in context, and automation come with new methods. In the vast majority of use cases, these gains make the overall current path superior.
However, going back to analytic geometry and manual pencil and paper means to produce these parts allows for some extremely efficient workflows and it gives people the means to check their software work, debug problems, and in the case of just wanting to make something quickly, the ability to do so by hand with only basic tools.
The most interesting part about this transition for me, as I was there doing it old school and transitioned to new school, is the demand for the basic methods comes up time and time again, despite the software being capable. People just don't always know why, just what.
From time to time, I teach mechanical CAD design. When this topic comes up, I go to the white board and show them the classic methods and basically produce a complete part on a white board with no computer assist. Once they see the why, a whole lot of software use issues go away and trust / confidence in the tools goes way up.
For this particular discipline, it's not taught, but can be found in old books, or from manufacturing people who have learned it from others.
For most engineers, going through this grants them the ability to visualize the sheet, and or catch a lot of simple errors without having to employ verification software. "It just looks wrong" becomes part of their tool set, and we all know how valuable that basic intuition is.
The same can be said for most manufacturing techniques. Going back to the manual, hands on means and methods explains so much about what we do today, even though the methods themselves may not be viable in the context of modern automation and production.
We have come a long way indeed! And on a basic level, just experiencing that perspective is gratifying sometimes.
>> 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.
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.
*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.
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.
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.
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."
Oh 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).
Disappointingly fails to link to http://www.coboloncogs.org/INDEX.HTM which frankly is about as credible as the idea that COBOL might be "just hitting its prime". Nothing in the article or anything it links to offers any support for that.
Not that I don't think it sucks but use it myself judiciously when necessary, but where is PHP in IEEE's language popularity index? Is it really not in the top 20, less popular that COBOL and Processing? Or does IEEE just not consider PHP a programming language?
What'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.
Also, nobody calls it the "mainframe". It's the "host environment". It took me a couple of weeks on my current project to work out why my new colleagues were so reluctant to modify the customer re-contact batch process - "oh, that's on the host environment!".
A few years ago I landed my first programming job as a COBOL programmer, I had no professional(programming) experience or a college degree but the company offered an in-house training type deal. It was several weeks long and they had a trainer come in every day and teach us COBOL and it's accompanying technologies(SQL,JCL,REXX), the pay was 50,000 a year starting out and it wasn't a bad gig. Would I go back to it? Probably not, but you can certainly make a decent living getting into COBOL these days. The work was boring and nothing cool or cutting edge but at the time employment was employment to me. My resume is online and I certainly get my fair share of offers for COBOL work. So learning it could certainly have some merit if you're looking to make some money.
I know people that make a very good living at it. But, like anything, you have to find the 'nice' positions, and that comes from knowing something critical to a business that almost no one else knows. You can name your price then. But that usually means you spend 20 years grinding, industry and everyone moved along, and you stuck it out.
I don't think there is an advantage in general - the mean salary is probably going to be lower compared to enterprise Java, just the tails on the COBOL jobs can be lucrative. I don't think it is particularly satisfying intellectually, but that might be my bias (I don't enjoy digging through reams of code to try to figure out how to glue things together - it is a challenge).
I did my time on big iron and JCL - Do. Not. Want. Of course, these days a human is probably not walking your stack of tapes to the tape readers so you can find out you have something misconfigured .... Sometimes I'd get 2, maybe three runs a a day if the operator was really spritely!
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.