The stock market is down, COBOL caused it. Gasoline prices are up, COBOL caused it. Businesses and governments are not responsive? COBOL caused it.
See the attached link referring to the State of California? Titled: "California can't perform pay cut because of COBOL"; according to their Governor; http://developers.slashdot.org/article.pl?no_d2=1&sid=08/08/05/1816206
And over the last few years I've seen many more of a similar bent. Basically COBOL applications, developers, and infrastructures are the root cause of IT not meeting it's business requirements.
Are our business leaders, IT leaders, governmental leaders and publications - when discussing languages - out of their collective minds?
So some facts.
There are 2 Billion lines of COBOL code running worldwide large corporate businesses. There are 1.5 Million COBOL developers doing business development. Both according to Gartner Group. That's the positive.
Much of the COBOL business processing is delivered in older less changeable architectures of the past. That's the negative.
One person's conclusion. COBOL is a good business language. And COBOL developers are generally good resources. But at the end of the day - as noted in my other blog entries - it's about IT delivering value. And for COBOL only applications - and COBOL only developers - that's a problem today.
COBOL will be one of many languages forward. It's easy to write, and performs really well. Great language attributes. But it won't be the key language. Nor will the architectures of COBOL's past be the key ones either. COBOL is not great at Rich User Interfaces, and providing the front end of Web and Web 2.0 architectures - which will drive most design and development efforts. COBOL as a language is and continues to be relevant for business processing. So for delivering back end services in a service oriented architecture, it will be a key language. It's also unparalleled in batch processing which will continue to provide back end support for web applications. And many customers want to share transactional and batch processing as well.
I also believe COBOL as a runtime should be viewed independently from COBOL as a language. EGL can let us take advantage of the runtime positives of COBOL like high throughput, very fast access to data, and strong transactional processing in CICS, IMS, and other transaction managers. And EGL can also be used for the UI and front end part of the application.
People eat up lots of the IT cost structure. Reuse as well is much more important today - both due to cost of writing code as well as in meeting requirements for faster responsiveness. These modern architectures also promote reuse. No matter what the underlying language or languages.
COBOL developers will need to deliver value in new languages and infrastructures, like Web 2 and SOA, to stay relevant in overall application design activities. It's not COBOL that's the problem - it's about IT doing, or not doing, more. Blaming COBOL is ridiculous. Blaming those who hinder the endgame; won't change processes; won't get with the new economic realities on how we need to perform; is also probably not going to be productive. My message. For the COBOL developers - learn Web 2.0, do Web 2.0, make your mark. You're companies will do better with their revenues, you'll do better in your careers, and I won't have to read the any more nonsense about COBOL