Reasons to start a new project in COBOL

Question

• Are there any feasible reasons to start a new project in COBOL?

• What benefits of this language one would find convincing enough to start a new project in it?

  I'm thinking more about viewing the language in terms of Behavior Driven Development, something related to the steps involved in using a framework such as Cucumber, only that behavior description and step definition would be integrated into one unit by using tha language's features.

Answer 1

1. No. Unless you wish to provide deprecated programmers with some work.

2. No. Except for... COBOL programmers are rare and therefore can expect a higher pay. Whether it's good or bad depends on what side you are on.

Answer 2

From my understanding, COBOL is great for mainframe work and business reports. If you aren't doing both, then it's probably the wrong language.

There's probably a mainframe/report language that's significantly more modern, but I don't personally know of one.

Answer 3

I would suggest not using COBOL for the following reasons:

• COBOL is procedure oriented rather than object oriented (I don't think the 2002 standard with object orientation has been particularly well accepted - so stick with procedural COBOL). If you go procedural there is a bit of a mind shift to accomodate between what is essentially an object oriented methodology and a procedural implementation. Not impossible, but it is a bit of a twist.
• COBOL is generally used in large scale transaction based applications (think banks and government). It is not unusual for an application to contain several of million lines of code. No matter how you slice it, this represents a huge number of business rules and, more importantly, complex interaction among those rules. Furthermore, throughput is generally given more priority than architecture - because if you can't process a days worth of transactions in a day, your dead. I have yet to find a methodology that can adequately capture this kind of complexity (and anarchy). This may explain why COBOL programmers end up working on the same project for decades - it is their knowledge of the application that keeps them there, in essence, the programmers are the documentation!.
• If your first devotion is to a particular methodology, there are probably much better choices for implementation language than COBOL. COBOL developers generally come from an entirely different sort of culture so staffing and education will be huge challenges for you.

I took a quick look around the net for BDD and it looks to me that this methodology is best suited to application domains where UI is a larger component of complexity than data transformation (e.g. complex financial computations). If you are developing a COBOL type application, use methodologies more suited to that framework.

UPDATE

I have been rethinking some of my answer based on comments and the post by Ken. My original negative answer was prompted by a lack of conviction that COBOL culture and BDD would get along. There is nothing wrong with COBOL (I have been using it for about 25 years - and I'm happy). And there is nothing wrong with BDD either. I just don't see the two of them working together very well. This is more a cultural clash than a technical issue.

If you have serious transaction based processing to do, COBOL may be the way to get it done. And if that is you priority, then there may be better frameworks to build a COBOL application under. I have been using Netron/Cap (Bassett Frame Technology) for about 10 years and I'm really impressed. Another possibility would be XVCL. Appropriate use of these frameworks boost programmer productivity, code quality, compliance to standards, application maintainability and a whole lot more. Check them out, there is a good introduction here.

Answer 4

I can think of several reasons, which you may or may not find compelling. If you can't think of any, then you're not trying.

1. It's always valuable to learn a new language, and you can only learn a new language by using it for a real program. Cobol might not be the most mind-blowing one to choose, but it's better than watching TV. In fact, compared to the syntax- and structure-heavy languages popular today, it's simplicity could be quite a shock.

2. Historical interest: it's still around today, in some form, while contemporaries (like RPG) aren't. That makes it historically important, even if it wasn't technically good. For my computer science education, I had to learn barely any history, while it was a core part of the curriculum for my friends studying art or philosophy; maybe those fields are on to something.

   There are also more reasons to write a program than to be the next Google or Microsoft; if you said you wanted to practice archery, I would think it's awesome, but I get the feeling a lot of geeks here would tell you how much faster the rounds from their Glock 37 are (unless you wish to provide deprecated fletchers with some work?).

3. It looks fairly easy to write a compiler for it. Look how many times people come to forums like this looking for the reason why something didn't work. With Cobol, you can crack open the compiler yourself, or even write your own if you have special needs. I really don't want to do that with a modern language that tries to provide everything under the sun, at the mere cost of being insanely complex, like my C# compiler. I've been at the mercy of vendors, waiting for them to fix their compilers, and it ain't fun.

4. Looks comparable to some other popular scripting languages, like VB. Hey, we tease VB, too, but it gets used by an awful lot of people doing an awful lot of real work, while Emacs (despite thriving for over a quarter century) gets teased for having ... a real programming language. If your users aren't computer scientists, and you're not writing for a platform where VB is the standard extension language, then maybe Cobol (with a cool name so people don't realize it's Cobol) would make a decent extension language. I think some usability testing is called for in this area.

5. It's future-proof. 7 seconds of googling turned up Cobol for both the JVM and .NET. This not only means that you can run it on modern systems, but that people are still writing/porting Cobol to new platforms, so whatever's next will likely also have Cobol. (I'm not seeing any Algol compilers for JVM/.NET, even though it's a better language by almost any measure.) Will there be a Scala on the hot platform of tomorrow? Maybe, but it's too young to tell. Cobol is, like a cockroach, a proven survivor.

6. Long-term skills. Remember being able to learn a skill that moved on the order of years and decades, not weeks and months? It's hard to be an expert at a popular language for very long these days, since things move so fast. If you pick a mature and long-lived language, you can build language skills for years. I would bet the difference between an average Cobol programmer and a great Cobol programmer is even bigger than in other languages with shorter half-lives. You could be one of those people demanding higher pay for a rare skill!

7. It's not bad to type anymore. We didn't have Emacs abbrevs when Cobol was invented, so they actually had to type "PROCEDURE" and "ADD" and all that crap. (But you try and tell the young people today that ... and they won't believe ya'.)

With all that, would I start a new project in Cobol today? Not a chance. Though I might write a compiler for it and make it my extension language, if I was going to write something for a general audience.

Answer 5

COBOL is one of the most portable languages around. If you want your code to run on a variety of hardware (mainframes to PCs) then coding in a standard COBOL gets you onto all those platforms with minimal differences.

Answer 6

If you already have a mainframe, you have COBOL developers, and your COBOL and non-COBOL developers all agree it's best to do it in COBOL, then 100% yes, you should be doing it in COBOL.

If you don't already have COBOL developers, it's unlikely you're in the niche they suit, and "it's always good to learn a new language" is better spent on a niche you are in.