COBOL: Everywhere and Nowhere | Hacker News Reader

COBOL: Everywhere and Nowhere

codinghorror.com

20 pointsbdfh4225 comments

I've never met a COBOL programmer. The only times I've seen actual COBOL code have been examples to show how inscrutable it can be (like the example in the article). I haven't seen any open source software written in COBOL, although I'm sure there has to be something. Yet, I know COBOLers are out there.

Given the fact that COBOL refuses to die and not for lack of other options, I've always assumed there's something that kept these guys going. I used to think it was just hard-headedness ("Haven't these guys heard of Python or Ruby or even like Java or .Net or something?!?!"), but age and experience have lead me to believe that it probably has something to do with the size of the paycheck.

So I'd really like to know:

Do COBOLers have a community of any sort?

Where do they go for help?

Do they read HN or proggit (or do they have their own portals that only run on green screens)?

What keeps them going (and do they actually despise their language but just suck it up)?

Are they locked away in the dungeons of enterprise IT departments (or are they more like the wizards in a tower)?

Is there some sort of annual conference where they all meet and dance in front of a bonfire (lit from the heat of their mainframes) and sacrifice young virginal (pure? dynamic?) OO or functional languages to keep their own alive?

I worked as a COBOL programmer for two years (well, technically I did 2 summer internships and two short winter stints) so I have a little insight into the "community."

I worked at a (successful) company that develops banking software and processes bank data. The majority of our data processing and operations codebase was written in COBOL, running on some Unisys mainframes. There is a growing population of .NET developers on the team, but for the most part the cube farm is full of COBOL programmers. In general they don't read HN, use StackOverflow, or any other online community that I'm aware of. For the most part, when they need support they ask one of the local dinosaurs. I have noticed that most of them don't use their career to define themselves like a lot of "modern" programmers (myself included) do. I think it's more of a 9-5 for them.

And they don't seem to hate COBOL, either. In fact, a lot of them like it. I think part of the reason is that it's one of the first languages they were exposed to, and one of the first mainframe-based languages that "made sense."

It really is everywhere (although 80% seems high), but you don't usually find it in any of the glamorized jobs. It's heavily used in the banking, healthcare, insurance, and payroll industries.

I'm still working for the same company, but I'm doing .NET stuff now.

In your opinion, why do you think they stay away from HN or Stack Overflow? Is it just that there's nothing there for them specifically or would you say that they're (on average) less interested in the wider programming ecosystem?

I'm not sure this kind of entrenchment is endemic of COBOL programmers specifically. I knew plenty of people in college who, once they knew Java, were perfectly content with their ability to program, and will probably be happily employed for the foreseeable future. I think it just boils down to the difference between the 9am-5pm'ers and the 5pm-9am'ers.

I think it's a combination of factors. The obvious factor is that there is no COBOL content there. These communities tend to be focused on new and developing technologies, which aren't really relevant to their work most of the time.

I think the less obvious factor is related to the COBOL mentality. In COBOL's heyday, they didn't have communities like this (yeah yeah, usenet, BBS, I know, I know) so they figured out how to live without them. The old whitehaired COBOL gurus passed these traditions down, and it just became a way of life. Any COBOL-related help you need can probably be provided by the lifer in the cube down the aisle. They are a fairly self-sufficient group.

That being said, I am interested to see how the COBOL community changes when people from my generation start taking these jobs. I didn't stop reading when I was hired, and I don't think that most of the others will, either.

Of course there are open source software written in COBOL! It's not the first time I have to post a link on Hacker News to COBOL's Ruby on Rail equivalent, COBOL ON COGS: http://www.coboloncogs.org/INDEX.HTM

It is a great framework built around the new super-awesome REPORT-HOST-TERMINAL pattern!

> What keeps them going

Switching costs.

Perhaps long time readers find my recommendations for this book tedious, but 'Information Rules' is a great read and explains why lots of things like this work the way they do:

http://www.amazon.com/dp/087584863X?tag=dedasys-20

I think Jeff answers his own question when he refers to my entire so-called "professional" programming career.

The fact is, there are a lot of professional programmers doing a lot of work that don't mix in the same circles as Jeff. The fact that they don't read his blog, or post to StackOverflow doesn't mean they aren't out there.

The sentence after that one says: "That probably says more about my isolation as a programmer than anything else".

The point is valid, if only to speak of an interesting separation and the generally low-visibility of COBOL in parts of the programming industry.

I can't say I've met anyone who is still actively writing or maintaining COBOL code either. I know a few people who wrote COBOL at the start of their careers, but who have since transitioned into other things.

So I think the validity of the observation stands. A quick straw poll of my colleagues within earshot (yes, I'm reading HN at work) suggests that none of them know any active COBOL programmers either. This is from a group of people from very junior to very senior, with a range of about 1 - 20 years of commercial programming experience.

So I think the validity of the observation stands

Which observation? That the COBOL-type programmers (and we can add in RPG, and other non-sexy languages as well) are isolated from the rest of the industry? Sure. But in-house developers of serious, back-end-heavy apps have always been isolated-- including from each other.

No, that the reported popularity of COBOL is at odds with the anecdotal evidence.

I think if you started calling around to banks, hospitals, transport companies, oil companies, old-school manufacturing facilities, etc., and started inquiring about their existing codebases, you'd get a whole other set of anecdotes.

And that would be an interesting thing to see a blog post about too!

Vernor Vinge's fiction introduced the concept of the "programmer archaeologist," which seems appropriate here. He predicted that in the distant future, the skill of programming will have entirely shifted from writing new code (everything you need has already been written) to reading and curating old code. We may be there with COBOL already. _Understanding_ COBOL might be more important than _writing_ COBOL, so the newest variants of COBOL (like .NET) are _less_ relevant than the old stuff.

Lots of COBOL still in existence.

If you use a credit/charge card, make an airline reservation, have an insurance claim adjudicated, pay a utility bill, etc.… odds are an old-school COBOL application (with a DB2 database or even more archaic IMS hierarchical system on the backend) is going to process that transaction. Sure, a snazzy web frontend might be in place now, but in the guts is buried business logic reduced and offshored staff no longer possess, and life lingers, only measured in half-life units now…

Most corporate COBOL (as this is the province of Fortune 500 firms) application support and development is handled by offshore vendors, primarily in Asian and Indian locales, with facilities here in the states to hold non-immigrant visa programmers.

COBOL knowledge (and a lot of the details are buried in the platform it runs on — in my experience, mostly IBM mainframes, though I started on Burroughs hardware) is still in a pre-internet age, and college textbooks and three ring bound together 8 1/2 by 11 pages serve as instructional aids, along with experience.

A lot of corporate outlets have engaged in boondoggles to replace the COBOL, but a good deal of these efforts have been epic fail:

* …lot less business knowledge handicaps

* …likely to whiz-bang consultant firms with their own lock-in proprietary systems that woefully underestimate effort to decompose and recompose legacy system…

* …the systems running have been optimized over the years, and they're tied to existing data center operations, which in many cases, are run by IBM. It may seem incredulous today, but even in the 90s, the mainframe systems ran circles around PC and web solutions, especially the "solutions" vendors were offering at the time.

I think 80% of active code being COBOL can not possibly be true. Computer use and "active code" have probably grown exponentially over the years, and the new stuff hasn't been in COBOL for a long time.

Thats a Gartner Group claim from 1997. I wonder what would the share be now according to them.

For 1997 I can believe it - thanks for the info!

Just the other week I wrote a couple of .NET classes to read 'native' COBOL Indexed Sequential files from a brand new package installation at one of my client's sites. This package is still in active development in COBOL because the code is just about unchanged across multiple platforms - (Open VMS and Windows are both very similar from a COBOL point of view)

Back during my year of unemployment after the first dot-com bubble burst, I met a woman who had been unemployed for two or three years, and she had COBOL experience. We got jobs within about a month of each other (she recommended me for a company that hired me, then I recommended her for a managerial opening at the same place), at a Java shop. So at least one of the following must be true:

* employers weren't all that desperate for COBOL programmers

* hiring managers in the COBOL world tended to be male chauvinist pigs

* this woman preferred unemployment to working in a COBOL shop

Wow - at times I have pondered learning COBOL for fun, as I assumed it to be an easy language. That code snippet killed that illusion good and proper.

If I was religious I would now pray that I will never, never, never ever have to deal with COBOL, ever.

Everybody goes through that. "COBOL? What's the big deal? I think I'll try learning it some weekend."

Then they actually try learning it.

Then they are enlightened.

COBOL has fixed point maths built-in, ergo it's popularity in accounting and business applications.

Most COBOL code is straightforward file "read-process-output". I could easily see a system that _generated_ COBOL code to do assigned tasks: the generator would maintain the database and a description of transformations. The developer would work at that level and never look at COBOL code.

But someone's probably written such a system in COBOL!-)

A grand total of 61 questions have been tagged on StackOverflow with 'cobol': http://stackoverflow.com/questions/tagged/cobol

For comparsion, the count for "C#" is over 30,000, ".net" is close to 20,000, and "java" is about 17,000.

#5 Phillips Screwdrivers: Everywhere and Nowhere

Just because you take your car to Pep Boys, call the landlord when something breaks, and use power tools in the garage doesn't mean that olders tools don't serve their purpose.

COBOL is just another tool in the hacker's toolbox. It does a great job at what it was meant to do (neatly laying out and processing business transactions) and continues to do so.

I have worked on many COBOL systems and choose not to any more. Why? Just too damn many lines of code to do the same thing as many other languages.

I wouldn't worry too much about the supply of programmers for aging COBOL systems. Supply and demand will take care of that. Which would you rather do, web work for $50K or COBOL maintenance for $100K? Many would choose the latter.

Reply on news.ycombinator.com