Lambda the Ultimate

At AOSD'05 there was a talk that started with the role of Cobol today, see the first slides at http://homepages.cwi.nl/~ralf/AspectCobol/slides.pdf

Design starts in Cobol (I believe nowadays the first-letter-only-capitalized spelling is considered more "correct") aren't very common. When Cobol is used in production; almost always it is because the project in question has to support/interface with legacy code that's written in Cobol.

Other than interfacing with existing Cobol deployments, I can't think of any reasons to choose it for a new project.

Nowadays you'll find some folks with Object COBOL compilers for sale, but they're only used for extending additional code. The problem with COBOL (besides the lack of brevity in the syntax) is that there's a lot that the language doesn't do without jumping through many hoops. I've written a heap manager, red-black trees, a virtual filesystem, etc. in COBOL, and it wasn't any fun at all. COBOL is cursed by the fact that it was designed to do one thing, and to do it very, very well: record processing. Back in the bad old days when everything that banks did happened in overnight batch processes, you'd upload a file containing a gazillion records to a server, and it would cruise through these records doing whatever needed to be done with them. The language treats record fields as native variables, so the record-processing programmer can just code up the calculations required (which often involved pumping out new records into other files for further processing). In the modern world of J2EE & .NET there is still call for big batch processes, but nowadays many of these are performed inside of relational databases instead of flat-files.

As Mr. Ostermann above says, it's not dead, but unless you're looking to do what COBOL was designed for, there are probably a lot of better tools for the job.

I think a fair number of telephony billing systems were written in COBOL too, btw, since 'call records' that are spooled from telephone switches tend to have fairly standard formats, but I don't know if a lot of these systems are still around or not.

Hope that helps!

As an ex-COBOL programmer, I feel the language should die a violent death. I've written about some of the problems with COBOL, but much of language design has stemmed from economics.

When COBOL first came out, computers were expensive relative to programmers, so the more work you pushed onto the programmer, the better. Today, you can buy high-end computers for less than a programmer's monthly salary. Thus, languages which decrease a programmer's productivity tend to be less success successful from a financial standpoint (of course, this is an oversimplification. There are many other factors involved.)

Part of the reason why we still have COBOL, though, is that large corporations have multi-million dollar systems which cannot fail. Thus, experimenting by migrating to a newer language is a dangerous proposition even though it's becoming more and more imperative.

Perversely, one of the reasons enterprise class systems written COBOL were so successful is because of how primitive the language is. Because it can't do much (you typically call up another job to do sorting, for example), COBOL programs tend to be small, discreet programs that do one thing and do it well. Then they're put together in pipelines by JCL (Job Control Language) which controls the flow of behavior. One program will read the data and write some files. The next program will sort one of the files. Another program will read the sorted file, add a couple of fields and shove the records in a database. Another program reads the database ...

Because no one piece does too much and because well-defined interfaces are mandatory, COBOL -- particularly in batch environments -- tends to be successful. With newer languages where you can do everything in one program, people often try to do everything in one language and fail miserably (which is where automated testing comes in, but I'll stop now.)

Thanks for the information guys,

Is COBOL still developing new lines of code? or is people just re-engineering legacy systems that was developped using COBOL?

Would a company use COBOL for a new system? why?

New COBOL is being written all the time. I've my fair share out there (I hate to admit). Most of this, I suspect, is to support new integration with legacy systems, but it's hard to say if that's really true without a comprehensive survey.

I'm not sure why any company would bother to use COBOL for a new system. Having programmed in "dinosaur" languages and graduated to Perl, Java and Prolog, (the latter possibly being a "dinosaur" language), I cannot imagine why anyone would start something in COBOL. While it was brilliant for its time, it's too primitive to be of use today. It has no scoping, it doesn't deal with free-form text and no namespaces. In fact, you don't even really have subroutines. You have sections and paragraphs, but they don't take arguments and they don't return values. In modern terms, they're little better than a GOTO statement (though I type most of this from memory and I idly wonder if some of my details are off.)

I was surprised to read that 15% of new applications are written in COBOL (Stop Bashing Cobol referenced earlier). Ralf Lämmel's home page has lots of info about COBOL and lots more about analyzing languages and extracting information from source code.

• fixed-length strings - memory efficient, fast and bugs are easily spotted,
• fixed-point math - ideal for accounting.

P.S. to Ovid: you make COBOL sound very much like UNIX processing with pipes: small programs with a single purpose, chained together with a job control language. That remains a successful paradigm today in both mainframe and UNIX worlds.

Andris:

Both the classic green-screens and HTML pages are text messages with control filler. Why surprise that a mainframe could serve HTML? Developers use (among other things) screen generators to generate procs/subroutines that encapsulate COBOL I/O. Vendors added HTML to the output formats. The addition of TCP/IP (achieved years earlier) was necessary first.

Ovid:

Among the reasons for lack of "hot new COBOL app hitting your desktop":

• the desktop metaphor is dead - Servers rule!,
• Interactive COBOL apps have always been server-centered; the only change is that today they're web servers. So you won't see the hot COBOL apps on your "desktop" - they'll be on the WWW.
  

The most off-putting thing about COBOL for me is its syntax, which I would call indefensibly verbose if it weren't for the likelihood that this would provoke some COBOL programmer somewhere into trying to defend it. I tried to learn COBOL a while back and gave up pretty early on, concluding that if I ever needed COBOL code that badly I could probably knock together a Python script to write it for me. (To paraphrase Harrison Ford's complaint to George Lucas about the script of Star Wars: you can type that stuff, but you sure can't think in it.)

Still, syntax is only skin deep, and from what others have said about the similarities between COBOL flow control and the piping-together of Unix processes, it seems that there is after all a COBOL way of thinking. The longevity of COBOL applications written before COBOL expanded its horizons with Cool New Features suggests that working within the limitations of the original COBOL programming model can make for robust and maintainable code.

I wonder whether it isn't worth thinking of COBOL as a kind of DSL, specialized to the task of building high-reliability business systems in a mainframe environment. The question would then be not what does COBOL lack that other general purpose programming languages have, but what would a good replacement for COBOL look like? What are the design issues around creating a language specialized to COBOL's domain - what does COBOL get right, and what could be improved upon?