What a bunch of crap. Not what you write Jeff, but the COBOL “article” you reference.
First of all, the author of the article is one Stephen Kelly, who seems to be the owner or is otherwise affiliated with Micro Focus World, a dis-functional website (http://www.microfocusworld.com/) with a business focus. Micro Focus is a sponsor (the only one?) of http://www.cobolportal.com/ which as you can get by it’s name is all about COBOL. Gasp, cue conspiracy theory…
So of course such a person would spout all kinds of “facts” about how prevalent COBOL is and how it is still important.
As for the facts themselves…
“There are over 220 billion lines of COBOL in existence, a figure which equates to around 80% of the world’s actively used code.” - bunch of crap figures regurgitated from a 2003 (!!) PDF linked to from the Wikipedia article on COBOL (citation #5). That PDF was published by LegacyJ, a – you guessed it – software firm specializing in COBOL solutions. Gasp again!
Not only that, the LegacyJ PDF lists a 1997(!!!) Gartner study as the source of these figures - but fails to provide a reference. Was there really a Gartner study back in 1997 which gave those numbers? How did Gartner collect them? what does “actively used code” even mean?! Are these numbers as relevant now, 12 years later?!
“There are estimated to be over a million COBOL programmers in the world today.” - yes, estimated by COBOL software houses eager to sell you their solutions and to calm your likely fears of being stuck with a language but without any programmers…
Pop question - how many questions in StackOverflow are currently tagged COBOL? It’s 61 of this writing. Compare to 17k questions tagged Java, just for example…
I could go on but you get the idea. COBOL is out there, it is used. But I seriously doubt any claims making it to be the “dark matter of programming languages”. It it were so prevalent we would know.
Now if you really want to talk about a prevalent but no longer sexy language, there’s… C. Simple old C, no longer sexy enough for most people… yet so much code is still written in C, including the little OS that could, Linux…
COBOL is still in use this is a fact! As mentionned COBOL programs still doing business! Companies maintain COBOL applications because it will be too expensive to rewrite them. Moreover lot of companies have based their core system on COBOL applications. So rewriting COBOL applications would be a business risk too high .
BUT, we have to pay attention that this does not mean COBOL programs are still under control. Several generations of developpers have coded those applications. COBOL applications knowledge has often gone away following the developpers. Consequences are: code duplication, fear to modify working, regressions… To ensure the ability of our COBOL programs to evolve we have to control them again. That is to say to instantly measure impacts of a code modification.
Newer language (Java, .NET, PHP, C) used XUnit framework to write unit tests (JUnit, NUnit, PHPUnit, CUnit). RPG has its unit test framework too: RPGUnit. The first need is to have a simple tool to write and automate unit tests on new code or on legacy code (to ensure no regression when delivering a code change or ensure capability of COBOL prgrams to interact with recent programs written in new generation language).
COBOLUnit (http://cobolunit.org) is a simple open source Unit testing framework to write and run repeatable tests in COBOL. It is an instance of the XUnit architecture for unit testing frameworks.
This framework is a way to modernize our existing application and made them more agile!
COBOLUnit is young and needs you to evolve. Have a look on COBOLUnit (http://cobolunit.org) and send your feedback to the COBOLUnit community (or join it) to make this initiative fit your needs.
At the moment i’m involved in a project to replace old Cobol software with a brand new Java-based one. The old software is absolutely critical and rather big so it was a tough decision to rewrite it. They probably wouldn’t have done it at all, but they wanted certain features which Cobol simply couldn’t implement.
The numbers are probably exaggerated, but a lot of Cobol is still out there up and running. The smaller and less critical software has already been replaced, but some big and important ones remain because they are so expensive and important.
Wow… that is new COBOL with functions it looks like. I was taught old COBOL86. No functions for me.
“It it were so prevalent we would know.”
@Solidstate: That is the point, you would if you were told about it, but most people are not, so you don’t. As a programmer these days, the smart money is in COBOL because it is a niche, you could charge pretty much whatever you want as a consultant and they would pay because they would have very few other choices ;).
I have never programmed in Cobol, but I learned some concepts and, although I did not like it, its simplicity and effectiveness is certainly something that keeps it alive. Since the language and the tools are fairly crude, your brain has to work for a living. You have to know how to compile programs out of object files. And, you have to understand your business problem inside out or you will not get anywhere otherwise.
Compare that crude simplicity with modern languages which pamper us with development tools, complexity, GUI… software development has worsened as the tools have improved. When I say “worsened”, I am saying that there are more failed project (on a big scale) than ever before - despite the “body of knowledge” and “improved” tools.
Aside from its simplicity, Cobol offers a standard for everything in the pipeline, from user interface (green screen) to database (VSAM).
All our methodologies are designed to deal not only with complexity but also with ineffective development tools, ineffective build tools, shitty environment (service pack on top of another service pack), memory hogging, garbage collections which don’t work as they should half of the time…
The school of simplicity was burried under OOP school of complexity. Niklaus Wirth developed an Oberon system (which was OOP all the way) which also provided end-to-end software environment (development and runtime) and worked beautifully. I am not saying that Oberon was perfect but it solve some of the burning issues that arise from complexity.
Unfortunately, the industry embraced piece of garbage called VB, dll hell, Windowses and the rest is history.
Wow, Cobol86! when I went to UNB in 97 they were still using Cobol72. It was hard to take a course seriously when the compiler was older then 99% of the class. I didn’t mind COBOL all that much except for all the typing, I sucked (and still do) suck at typing.
My first job as a programmer was doing COBOL development. This was a little over a year ago. The company I worked for not only did maintanence of old COBOL programs, which, granted, was the bulk of the work, but they were also doing new applications in COBOL. Right before I left, the company was gearing up to create a new web app in COBOL. Before then, I didn’t even know you could do that sort of work in COBOL, but lo and behold, you can.
The reasoning behind using COBOL was that COBOL was more readable than any other language. I would tend to agree that COBOL is easier to comprehend in smaller programs to non-programmers (it was, in fact, created to be understandable to managers), but when any sort of complexity is introduced, the sheer verbosity of COBOL causes programs to become convoluted messes that take a large amount of time to figure out what’s going on.
The major problem with using COBOL as a starting point (most new-hires cut their teeth with COBOL before being allowed to go on to anything else, if they ever were) was the carry over of COBOL techniques to more modern languages. The PHP and ASP apps tended to be utter messes. There were a few notable exceptions to this, but, for the most part, The COBOL mentality dominated.
Besides just using COBOL, we were also using an antiquated version of COBOL (COBOL86, I believe) on an antiquated system (MPE/iX). There were many times where the copyright date on the software I was using was before my year of birth. One was even around 10 years before I was born.
Is this the norm? I highly doubt it, but don’t be so quick to believe that COBOL is gone. It may be dying, but it’s going to die a very, very slow death. There are (shockingly) some people in the world who actually find COBOL to be a very good language, and will continue to use it, regardless of developments in language design.
I think you should take the site you quoted with a grain of salt though.
It lists C as the #6 dying technology. Clearly, that’s not true if you walk into anywhere that does embedded, systems, or a number of other different kinds of work.
I keep hearing about how COBOL programmers are in demand still, yet I never see jobs advertised for it. You’d think if it was so in demand that they’d be looking for people! COBOL is not my preferred language, but I have no problem with it. Problem is that so much “COBOL” is actually CICS… They DO still teach COBOL in school, but nobody knows CICS, so there’s a significant amount of learning that needs to happen for new COBOL programmers before they can actually get any work done.
Also, you’re right, there’s a huge disconnect between the “Internet world” and the rest of the programming world. There’s a huge portion of programmers that don’t do web, don’t use the web other than e-mail, etc. The things that they’re working on just don’t intersect with the Internet world. A few of us try to live in both worlds.
One of those big investment banks which just failed had a core trading platform written in Cobol on an AS/400 with a back end DB/2. They had scores of Cobol programmers maintaining it.
They had a C# front end I worked on which could only access the database by sending socket messages to Cobol jobs. Of course these jobs were actively being developed as well, in many cases by people in different offices, which made debugging and development something of a challenge to say the least. You could go for hours unable to even start the C# app up, because some crucial job was shut down (“in message wait”).
They had also contrived to bring the lack of productivity you expect from green screen Cobol development to the .NET world.
Most of the screens were so complex they were incapable of being loaded into the screen designer, so adding a control meant spelunking through the .designer.cs file and adding it (and figuring out location co-ordinates) by hand.
And by underpinning the whole with a very large and creaky market data engine written in C++ they removed the ability to use the Visual Studio debugger. If you stopped in the debugger at any point the market data engine killed your process!
Putting aside the “my computer language is bigger than yours” statistics, it’s interesting that computer language communities are so isolated from each other. Is it just because of historical happenstance, or is there some not-well-understood advantage in staying out of the “mainstream”?
… is great. That company migrated all their Cobol codebase to Java by writing their own conversion tool. You have to read all the papers, because it’s a very cool way of doing it.
Basically, unlike what you’d expect from existing language converters, the converted code is maintainable, and there is no need for any manual intervention after it’s done.
They fine-tuned the system until it was perfect, continuing in the mean time on working on the Cobol code (because you always need some amount of change to keep your business going!) and when it was, they converted and migrated over to the java version, working on that from then on.
They released their tool as F/OSS so that others could benefit from it.
Very, very cool.
“`I have a hard time reconciling this data point with the fact that I have never, in my entire so-called “professional” programming career, met anyone who was actively writing COBOL code.”
The other day there was a presentation in school by a former student and also friend of mine. She is working for New York Life, an insurance company, and guess what tool she is using everyday to write programs? You said it: Cobol (and also Assembly!).
Why is COBOL around? There are a lot of reasons but I can certainly give you one glaring example. IBM mainframes and DEC VAXes and Alphas don’t have “Blue Screens of Death”. They measure their uptimes in YEARS. In my previous incarnations as a Cobol programmer on DEC (VMS) hardware, I can count the layers between source code and the CPU on one hand. You can’t do that on Windows or with Apple. You could be running an ASP.NET application with Java going through a browser built on several layers of OS andp-code translators before you actually make it to the CPU. All those opportunities for failure.
Don’t get me wrong, I’m in the .NET world now becuase there weren’t enough “legacy” jobs as of 5 years ago. If you learned top-down modularization and object-orientation, your programming skills still translate in the “brave new world”.
