Live data from Hacker News

COBOL Leads Us Back to the Future (2015)

informationweek.com

11–20 of 25 posts

Re: COBOL Leads Us Back to the Future (2015)

#11

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#?

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!

Re: COBOL Leads Us Back to the Future (2015)

#14

>> 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 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-so... [2] http://www.ordat.com/en/solutions/tisql/

Re: COBOL Leads Us Back to the Future (2015)

#15

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#?

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.

Re: COBOL Leads Us Back to the Future (2015)

#16

>> 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…

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.

Re: COBOL Leads Us Back to the Future (2015)

#17
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?

Re: COBOL Leads Us Back to the Future (2015)

#18
post #4

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…

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.

Re: COBOL Leads Us Back to the Future (2015)

#19

>> 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…

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.

Re: COBOL Leads Us Back to the Future (2015)

#20
post #4

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…

>>>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.

Post reply on HN