Anonymous [10.16.06 01:00 PM]

> And there'll still be 5% of the marketplace saying of whatever new

> language is being created, "of course, this was first done more

> elegantly in Lisp."

And the truly sad part is that they'll probably be right.

Dave [10.16.06 01:43 PM]

The 'problem' with COBOL is that it won't go away while there are so many billions of lines of it in big-iron applications. While these apps are running it makes economic sense to keep the number of skill sets at a minimum and do the new stuff in COBOL as well. Rewriting (into anything) is tough, anyway if it ain't broke.......

While 4GLs have attracted interest from COBOL shops good old COBOL has still to be the easiest thing to maintain. Most senior IT people won't have looked at a line of COBOL in twenty years but I'd bet could understand almost anything put in front of them.(caveat: excluding the ALTER statement ) Can anyone say that about C?

Grace Hopper Rules!

Mz K [10.17.06 10:55 AM]

Oh my! COBOL, the zombie for the ages!

And even more hilarious, since before this little post I'd never heard of Haskell, I thought perhaps it was a programming langauge named after the every quirky Eddie Haskell! Ha!

Fun stuff.

keith ray [10.17.06 01:31 PM]

The real problem with replacing COBOL is that new languages don't do everything that COBOL environments can do. With the appropriate class libraries, Java or Smalltalk could do it all, but probably not right out of the box, and probably not running on those Big Iron boxes.

Maybe someone could make a "New Cobol" (like "New Coke" but better) with a nicer, up-to-date syntax, so that people could write "x += 1" instead of "add 1 to x giving x. (which is all I remember from learning Cobol in college 20 years ago.)

Bruce Hoult [10.19.06 12:03 PM]

What's wrong with ALTER? It's used for exactly the same things as function pointers are used for in C -- to choose from one of a set of similar operations at runtime, without having to have the overhead of an explicit test for every data item.

COBOL is a horrible, horrible language (I programmed in it in the early 80's, before moving to PL/I, then Object Pascal, then C++ in 1989) and you would not want to try to write a compiler or a GUI program in it.

But, y'know, it's perfectly fine for a certain class of applications, which is for making small simple processing steps in a transaction-oriented system where the tricky stuff relating to communication, concurency, integrity etc is handled by a higher-level framework. Such as, oh, CICS. Or Tomcat.

It might be crap, but it's no worse than PHP. And one hell of a lot easier for talking to databases than the crud you have to do in Java.

But we really *should* be using Lisp. Or at least something that is 99% Lisp, but easier to read, such as Dylan.

martin english [10.23.06 01:52 AM]

To expand on what Bruce said above, COBOL is a domain specific language. But, it was not designed as a transactional language. It was designed to process humoungous numbers objects called 'records', back in the day when IT was called DP (where the D stood for DATA). And it was designed to run on hardware that had more smarts and memory in the IO channels than 'onboard the CPU' (quotes because the CPU was cabinet bigger than most walk in freezers).

oh, and an object oriented version of COBOL would be interesting but pretty pointless ... after all, there is really only one object in COBOL - a record; everyting is an instantiation of a record.

anonymous [01.01.07 06:58 PM]

Interesting comments, since Sourceforge and Freshmeat both have many active COBOL or COBOL-related projects going. As for OO COBOL, the Brit company Micro Focus has a whole suite of products for it. Others probably do too. Gartner says the COBOL code base is growing at 5.1 billion lines a year. Verbose or not, that's a lot of code. Banks, phone companies, credit card companies... I'm not a COBOL partisan. Just saying it doesn't seem much like a dead language to me.