Slashdot Mirror

I don't really understand what you're trying to say here. I don't know COBOL. Are you saying that if you gave me an assignment to parse a data stream in COBOL, and I couldn't do it in COBOL because I don't know COBOL, but I could both demonstrate a solution in another language and learn COBOL at a later date, I would still FAIL?

Not the same guy but I think we are on the right wavelength.

Here. Now go parse that stream using Cobol.

I dont care if you have ever heard of Cobol or not. I have never used it myself, and I havent been a working programmer in decades. But if I needed a parser written in Cobol I expect I could search for the docs first thing in the morning, find a syntax reference, and have a working if rough parser done before lunch. If this sort of work was needed by me on a regular basis I expect I would become very familiar with Cobol and a week later I would re-implement that parser in less than an hour and do a much better job.

All a computer can do is math, or if you prefer to think of it as symbolic logic, fine. But it's still all the same stuff. Any high level language you use, no matter how strange the syntax, no matter how unfamiliar the vocabulary, is still the exact same thing at core. Logic. Arithmetic. Algorithms.

A particular language may be a pleasure to work with, or it may be a pain but end of the day if you understand logic you should be able to translate your logic into any language for which you can find useful reference documentation.

There are still plenty of FORTRAN shops out there, or at least legacy FORTRAN applications.

There is a ton of COBOL apps that need maintaining

If you are going to learn anything, it should be stuff that makes you more interesting as a FORTRAN and COBOL coder. For example, get comfortable making HTML/CSS pages. A lot of shops are trying to connect COBOL to the web and SOAP.

Find a web site or book to learn what relational databases are. Everything is relational these days. The NoSQL crowd think they're post-relational, but they still talk in the relational language.

That's the other thing you should learn: Oracle PL/SQL and Service Oriented Architecture (SOA). SOA these days means SOAP and message busses. At my place of work, we have a legacy COBOL application that needs to connect to the enterprise's Enterprise Service Bus (ESB). We are struggling to find anyone who can do it inside our company.

Your future is being the bridge between the past and the future. Learn how to make those old apps do new tricks, and you'll make lots of money.

Learn Perl. Because Perl is like the swiss-army knife for programmers. You may not write an application with it, but you might use it to make bulk changes to a hundred COBOL or FORTRAN source files.

I found this in about a minute: The COBOL Center. The IBM Bookshelf seems like it would be pretty good.

I'm not sure if they have physical books, though.

You'd think so wouldn't you? This page has links including COBOL XML parsers as well as CGI- and RPC- interfaces.

There's even funded university research (watch out for popunders) going on into COBOL - check out the research lab!

They have been predicting the demise of programmers since the invention of COBOL in the 60s. It was supposed to turn ordinary business users into programmers thanks to its easy, English-like syntax. We're still waiting. Now this writer is talking about running out of programmers capable of maintaining code that was presumably easy to write and maintain?

I think you mistake COBOL for ALGOL. The latter was indeed advertised for it's "ease of use" and it started a long line of (supposedly) user friendly languages, through it direct descendant - Basic - to contemporary Visual Basic and AppleScript. Cobol was rather advertised as being "business friendly" because it allowed ease separation of data and code and that - allegedly - suited it better for business/office data processing than its main competitor, Fortran. Noone could seriously predict "demise of programmers" in early 1960's. There were no personal computers in present meaning - even the so called minis of the PDP family, still required a separate room, had a price of a small airplane and were operated by dedicated staff wearing lab suits.

"I'm looking to get out of IT after being in it since 1977."
Young kids think they know everything. You don't see Sid leaving IT, do you? How many punch cards do you still have? Is writing FORTRAN code still second nature to you? (COBOL? What is that?)

Hey, I know COBOL, and I'm "only" 28.

Now, to be honest, I've never worked with COBOL professionally. The reason why I decided to learn COBOL is in fact pretty much related to the subject: At 26 I had just quit my job. As I browsed the job market, I realized that the jobs related to languages like COBOL and Fortran has sky-high salaries. That's why I sat down and read lots about COBOL.
Not just for the money, but also to help keeping a rare language alive.

And, well, you guessed it - I never got the COBOL job.

The reason most of the employers ask for COBOL programmers age 40+ is because they often have lots and lots of experience that a 26 year old never will have. Maybe I'll get one in 10 years, who knows. :)

Well, I'm 28 now, and I am currently learning C++, and I find it pretty hard to pick up. I started with BASIC at 9 and continued with assembler from 13 to 24, then I went on with Perl, Pascal and ANSI-C.

In fact I find it hard to learn C++ since I have the assembler "in my vains", to put it that way.
If I chose something else than asm back then, I'd probably pick up C++ easier today then what I do now. In contrast, I find it easier to pick up "functional" languages and other assembler variants.

By the way I'm the oldest guy where I work right now - the others are 18-25. :-o

Analyst firm Gartner estimates that applications managing about 85 percent of the world's business data are written in COBOL. Gartner further estimates that there are approximately 90,000 COBOL programmers in the U.S. and the annual growth of COBOL code over the next four years is 5 billion lines.