COBOL is a great example of what happens when a programming language becomes widely used in a particular domain, but then falls out of favor with the field at large. Fortran is another good example of this: it’s the bedrock of HPC and scientific computing, but the broader computing field has abandoned it. I learned Fortran in a class on fluid mechanics, where it was still extremely relevant, but mentioning my Fortran experience is always a good way to shock my colleagues who got CS degrees. (I’m not exactly old, either — I’m 33! But my degree is in physics.)
Based on the attitudes of younger colleagues, I wonder if Java is also on this road. Perl was never as popular, but I occasionally see job postings for “please come maintain this huge Perl stack!” And there’s no reason to think it won’t keep happening. Is it realistic to think the same set of languages is going to be in wide use in 30 years?
One possible result is that we will simply always have these languages with us, and they’ll take on the status of domain-specific languages. I wonder if there’s money to be made in running a series of “industry-specific” coding bootcamps. Want a job in banking? Do your CS degree, then come and take my 10-week class in COBOL and Java…
I think there’re two things here that this article really kinda misses. One is that, yeah you need cobol programmers to maintain those millions of lines of cobol. What’s not said is; first you want the guys who implemented it because they had all the domain knowledge. If they’re not available, you want cobol programmers from the same industry, next you’ll take “good” cobol developers who can understand code fast and get up to speed on yours. The last thing you want is fresh grads. This is assuming you’re ok living with cobol.
The other thing is; the skills thing is kind of a known known. You can contract out maintenance or new development to Tata or whoever so that’s kind of a non issue. Other issues are the IBM tax for running the systems. Another is market perception of these old systems. In some industries, cobol can be a big minus to customers shopping for claim systesm, retirement record keeping systesm, etc… It can be a huge head wind to sales for example.
I think these companies would be best served by reversing course and promoting cobol as a viable technology for the future; rock solid, (essentially) bug free, battle tested systems. The bedrock of entire industries as the article notes. Developers may frown upon it nowadays, and although we may not like it, the business doesn’t need rock stars for this stuff anyway.
Another thing is rehosting mainframe apps, this is where microfocus and other providers come in. Running the old mainframe stuff on commodity hardware can save millions. There are a lot of so called rehosting solutions around nowadays.
Do you mean that in the sense that all languages are equal in terms of their ability to solve a problem, so the rewrite is both unnecessary?
I agree that it will be a catastrophe if people decide to just rewrite whole systems, but not because all languages are equal but because rewrites are technically very challenging (recent examples include outages from RBS and TSB when they did big-bang rewrites and deployments of major systems).
This question is really hard to answer and probably doesn’t have one. I’ve worked in enough projects that were objective failures but human nature makes us turn it into a success in some way. Maybe if the software was kept more up-to-date my bank wouldn’t have maintenance windows on Sundays where I cannot do any transactions? Or maybe if the software was implemented in a more expressive language it would be less code so easier to maintain. But then you can always argue that when this software was written, COBOL was more-or-less the only game in town so would you rather not have the banking software at all?
So, I don’t know if mattered that much, I don’t know if anyone does. So I don’t think it’s that interest of a statement to make. I do think advising caution if people want to migrate away from it is an interesting discussion to have, though.
“Police, today, have apprehended a cartel of COBOL programmers with a shipment of COBOL code with an estimated street value of 300 billion lines…”
I think articles like this always inflate/exaggerate by some orders of magnitude and can’t be taken literally, like when you read about police arresting a dealer with a dimebag worth $1,000 “on the street.” Unless there is an actual measurement (vs. “some guy estimates …”), they could be wildly off in either direction, but will tend to round up for effect.
It might be high, I’m not sure, but I’ve been told (no hard evidence to back this up) that a lot of COBOL code starts as copy&paste of old code. So the number of lines produced per year is large but they are not new lines.
Has to be some, but still. Just was trying to ballpark it: a billion means a thousand of 1MLOC projects. This is a major institutional project size, even today. The article implies there were hundreds of thousands such projects in COBOL’s heyday, or untold millions of smaller projects. Given the installed mainframe base by late 1970s, it just doesn’t check out. The only explanation is it boomed in later years, which sounds contrary to common perception.
COBOL is exceptionally verbose. A programmer I know who develops new features in it today estimates that a typical module developed years ago is likely around an order of magnitude larger than if it was written in a modern language.
After seeing the code for a legacy ERP system up close, I’d wager it’s closer to 15x larger.
COBOL is a great example of what happens when a programming language becomes widely used in a particular domain, but then falls out of favor with the field at large. Fortran is another good example of this: it’s the bedrock of HPC and scientific computing, but the broader computing field has abandoned it. I learned Fortran in a class on fluid mechanics, where it was still extremely relevant, but mentioning my Fortran experience is always a good way to shock my colleagues who got CS degrees. (I’m not exactly old, either — I’m 33! But my degree is in physics.)
Based on the attitudes of younger colleagues, I wonder if Java is also on this road. Perl was never as popular, but I occasionally see job postings for “please come maintain this huge Perl stack!” And there’s no reason to think it won’t keep happening. Is it realistic to think the same set of languages is going to be in wide use in 30 years?
One possible result is that we will simply always have these languages with us, and they’ll take on the status of domain-specific languages. I wonder if there’s money to be made in running a series of “industry-specific” coding bootcamps. Want a job in banking? Do your CS degree, then come and take my 10-week class in COBOL and Java…
I think there’re two things here that this article really kinda misses. One is that, yeah you need cobol programmers to maintain those millions of lines of cobol. What’s not said is; first you want the guys who implemented it because they had all the domain knowledge. If they’re not available, you want cobol programmers from the same industry, next you’ll take “good” cobol developers who can understand code fast and get up to speed on yours. The last thing you want is fresh grads. This is assuming you’re ok living with cobol.
The other thing is; the skills thing is kind of a known known. You can contract out maintenance or new development to Tata or whoever so that’s kind of a non issue. Other issues are the IBM tax for running the systems. Another is market perception of these old systems. In some industries, cobol can be a big minus to customers shopping for claim systesm, retirement record keeping systesm, etc… It can be a huge head wind to sales for example.
I think these companies would be best served by reversing course and promoting cobol as a viable technology for the future; rock solid, (essentially) bug free, battle tested systems. The bedrock of entire industries as the article notes. Developers may frown upon it nowadays, and although we may not like it, the business doesn’t need rock stars for this stuff anyway.
Another thing is rehosting mainframe apps, this is where microfocus and other providers come in. Running the old mainframe stuff on commodity hardware can save millions. There are a lot of so called rehosting solutions around nowadays.
The real crisis will come when they decide to rewrite it in a “modern” language. Programming languages are overrated.
Do you mean that in the sense that all languages are equal in terms of their ability to solve a problem, so the rewrite is both unnecessary?
I agree that it will be a catastrophe if people decide to just rewrite whole systems, but not because all languages are equal but because rewrites are technically very challenging (recent examples include outages from RBS and TSB when they did big-bang rewrites and deployments of major systems).
COBOL is probably a bad language by most criteria that you can come up with. And yet… Has that it mattered that much?
This question is really hard to answer and probably doesn’t have one. I’ve worked in enough projects that were objective failures but human nature makes us turn it into a success in some way. Maybe if the software was kept more up-to-date my bank wouldn’t have maintenance windows on Sundays where I cannot do any transactions? Or maybe if the software was implemented in a more expressive language it would be less code so easier to maintain. But then you can always argue that when this software was written, COBOL was more-or-less the only game in town so would you rather not have the banking software at all?
So, I don’t know if mattered that much, I don’t know if anyone does. So I don’t think it’s that interest of a statement to make. I do think advising caution if people want to migrate away from it is an interesting discussion to have, though.
Do you think runtime environments are also overrated?
I have no idea what a “COBOL runtime environment” looks like, to be honest.
The claim of hundreds of billions of lines in COBOL sounds exaggerated.
“Police, today, have apprehended a cartel of COBOL programmers with a shipment of COBOL code with an estimated street value of 300 billion lines…”
I think articles like this always inflate/exaggerate by some orders of magnitude and can’t be taken literally, like when you read about police arresting a dealer with a dimebag worth $1,000 “on the street.” Unless there is an actual measurement (vs. “some guy estimates …”), they could be wildly off in either direction, but will tend to round up for effect.
It might be high, I’m not sure, but I’ve been told (no hard evidence to back this up) that a lot of COBOL code starts as copy&paste of old code. So the number of lines produced per year is large but they are not new lines.
Has to be some, but still. Just was trying to ballpark it: a billion means a thousand of 1MLOC projects. This is a major institutional project size, even today. The article implies there were hundreds of thousands such projects in COBOL’s heyday, or untold millions of smaller projects. Given the installed mainframe base by late 1970s, it just doesn’t check out. The only explanation is it boomed in later years, which sounds contrary to common perception.
COBOL is exceptionally verbose. A programmer I know who develops new features in it today estimates that a typical module developed years ago is likely around an order of magnitude larger than if it was written in a modern language.
After seeing the code for a legacy ERP system up close, I’d wager it’s closer to 15x larger.