“What I soon learned was that the structure of COBOL, in particular the rigidity of the DATA DIVISION, made it the easiest language there is in which to modify someone else’s code.”
I’m sorry but I really fail to understand how for example a 30000 line program with all the variables that have to be global within DATA DIVISION is easy to modify. Trust me, whenever you want to change anything in such a program chances are you’re gonna screw something else. For all of those that mention the beauties of COBOL have you ever programmed in a real programming language? In any other programming language? I’m working with a few COBOL programmers and I completely understand the point in Dijkstra’s quotation. Once you start programming in COBOL it really rots your mind.
@Schnapple
"When something came up she didn’t want to do, she’d just refuse to do it, or threaten to quit."
I completely understand that. After only a few years of programming in COBOL people are unable to grasp any concept that does not exist in COBOL. OOP? Refactoring? Local variables? SQL? It’s only flat files and spaghetti programming in COBOL programmer’s mind. Reusing the objects? Try writing procedures (functions are too advanced concept) for every little thing that you need. Need to copy, trim, concatenate or do anything to a string? Write your own procedure. And then copy-paste it everywhere you need. Need to do anything that every other programming language has a set of pre-made functions or objects for? It’s roll your own procedure in COBOL world! And that’s how we come to 220 billions of lines of code. It’s crap and unnecessary stuff for 90% of that! What you do in one line in most of programming languages it’s 30-40 lines in COBOL.
“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.”
I think I might know why that is – when I was in university, I ended up doing a 4 month Co-op position in the IT department of a large international grocery store chain. They ran everything through COBOL with no plans to migrate away from it – I even worked on some code that originated before I was born. A bunch of us students started at the same time as a bunch of new hires.
What was interesting about these new hires is that none of them had any computing science background. None of them were professional programmers. For the most part, they were blue-collar workers in their late 30’s who were looking to move into white-collar work. They were were trained entirely by the company specifically for this job. So they weren’t COBOL programmers when the started, the training they got is specific to the company which so heavily promotes from within. I think that makes them pretty much invisible to you.
At my college the Comp Sci majors got to play in C++ and Java and the IS majors had to take COBOL. I assume they all got stuck doing COBOL while I enjoy doing C# every day.
As far as your code sample I didn’t even attempt to read it. Some good advice is to never learn or do anything you don’t want to be pigeon-holed into doing. If you don’t want to do COBOL make sure you don’t know COBOL.
COBOL is still out there and rumours of it’s death, or even retirement, are very premature. At the very least it’s utterly pervasive in the big payroll world. I’m slightly suspicious of attempts to move old COBOL code to a new platform or environment. This is code that works, you don’t mess with it. At the same time I wouldn’t touch the language with a 10 foot pole these days.
I spent the first six years of my career programming in COBOL on what was then a new system (in 1990). We were very mindful of sticking to good coding standards, and I don’t feel at all sullied by the experience. Because of its English-like syntax, good programs often documented themselves. Indeed, it was originally designed to be a reporting language for non-programmers.
Of course, I prefer doing C++ and Python these days, but if I had to I could do COBOL again it wouldn’t kill me.
And if you’re a scripter and savvy with ISPF Edit and REXX, the development environment is not as miserable as these no-COBOL-knowing babies would say it is.
You definitely have to look at the enterprise. I work for a Fortune 500 in the financial services industry. Enterprise wide, I’m guessing that we’re now up to even split between .Net and COBOL. The bugs from two decades ago were either ironed out already or (something I’ve seen frequently) people just adapted to working around them, and forgot that the bug even exists.
Obviously the perfect language is not needed to build enterprise systems that last decades. And I am no COBOL fan.
In a way, our condition today is a sad commentary – that despite so many new technologies there are so many software project failures, and so much code that gets written and then put on the shelf.
The Social Security Administration has a significant COBOL program inventory. 12,500,000 lines at one time - don’t know how much now. I was fortunate enough to escape the COBOL batch mainframe world at SSA and now work in Java, but we are small in number compared to the number of COBOL programmers. I guess I’m one of the “old” people you youngsters are so disdainful of.
About size of COBOL code; I’m repeating a bit what others already said in comments, but if I remember correctly (I don’t have this book by me, unfortunately) Jon Bentley in “Programming Pearls” described an example where rewriting code (IIRC for telephony system), which was originally in COBOL, in modern programming language with dynamic structures, reduced code size one or two orders of magnitude (10 or 100 times smaller), and make it much easier to maintain and extend.
It’s not only excessive verbosity of COBOL, but also lack of modern programming concepts, which means workarounds and repetitions. So divide those alleged 220 billion (10^9) lines of code by 100 (or more) for comparison with more modern codebase.
@o.s. “Also, about that 220 billion lines of code figure I can guarantee that if that code was rewritten in C the line count would go to 220 million lines of code easy if not smaller.”
Ya. Right. Each 1000 lines of COBOL would be one line of C…you really really think that? I mean…realllllllly?
COBOL hating isn’t new. My dad had a picture of the COBOL gravestone taken when we visted the Boston Computing Museum back in 1998. The gravestone was presented to one of its creators back in the 50s, presumably by LISP programmers.
@Anonymous
Not directly I exaggerated a bit as a joke but its plenty bad. Modern languages make it easier to facilitate proper code reuse and makes it easier to create a reusable library of code. To be honest, C++ would be the best choice to cut down on the lines of code count since it has better OOP features but C could do some of the job.Fact is COBOL forces devs to recreate the wheel on a regular basis on top of its extreme verbosity which contributes mightily to its lines of code count. For all the COBOL lovers out there, their isn’t any magical properties of the COBOL language that makes it more maintainable. It’s all in your imagination, COBOL sucks and makes you work too hard to build simple systems.
Where I work (a large relocation and moving company), many of the systems are still based on the mainframe. Half of the code or so is COBOL that’s been updated and modified since the 70s - the other half is a mix of Adabase and a dozen or so other archaic languages - totaling nearly 6 or 7 million lines of COBOL code. We’re just now in the process of converting from the mainframe to a SQL Server/C# environment (through an automated tool that is going to cause massive, massive headaches), but even so, some of the code is being converted to COBOL.Net, which is going to keep the COBOL legacy going for years more to come. The cost of the conversion from old-COBOL to new-COBOL is still going to be far less expensive and time consuming that trying to rewrite the entire set of systems in something newer, and we plan to update sections of the code over time. People don’t like the change, and older languages stick around for a loooong time.
My mother coded COBOL for Philip Morris for over 20 years. Even today, entire contracting companies focus on maintaining, and yes… building new systems in COBOL for said company.
You have to remember… not everyone that codes is trying to ride the technological wave. Many COBOL programmers came to the market straight out of high school and saw it as a job no different than any other.
I started a job in the finance sector programming in Cobol/Cics/Db2 back in 1995, and had people tut-tut my choice of a programming language that would be dead in 2-3 years, or 5 on the outside because surely, all companies would have replaced their old Cobol code before Y2K!
14 years later, and I’m still happily working with the same languages while some of the tut-tuting java programmers are drawing unemployment. (For fun, I also use some java/ruby/“programming language of the month” on minor tasks – this as an aside to those who blithely assume that Cobol rots the mind. To a good programmer, a language is a tool, not a religion, and which one you use rarely matters as long as you wield it with skill.)
Cases where I’ve found Cobol programmers include banks and a couple of mid-sized corporations using outdated AS/400 systems. That’s in Greece of course which is not so advanced as the US. But then if you think of it, there must be dozens of not so advanced countries where daily operations would be performed through Cobol programs.
