55

When people mention COBOL, it's usually either met with a snort or groan. I don't know much about COBOL, but I've seen some programs written in it. I can see that it's wordy, and to uninitiated eyes such as mine, unintelligible. But, really, aren't all programming languages complete gibberish to a lay person?

I understand that it works, works well, and is still in widespread use in the industries it was designed for. Aren't those the hallmarks of a good language? What's so bad about COBOL?

JSBձոգչ
  • 1,310
  • 12
  • 15
Barry Brown
  • 4,095
  • 4
  • 25
  • 27
  • 8
    COBOL's OK for manipulating hierarchical databases or flat files and for pumping data out into big text-only reports on a giant dot-matrix printer. But most data nowadays is in RDBMSs and most managers like pretty reports. COBOL just doesn't handle that so well. – pdr Oct 07 '11 at 08:27
  • @pdr - I think you mean giant line printers - http://en.wikipedia.org/wiki/Line_printer –  Oct 07 '11 at 08:56
  • 1
    @Steve314: Yes! Those! Except ours were Line Matrix, and I hadn't had coffee this morning when I wrote that. - http://en.wikipedia.org/wiki/Line_matrix_printer – pdr Oct 07 '11 at 09:36
  • 3
    Without single ing out COBOL, if you search a bit, I think you'll notice a lot of domain specific languages are not very *popular* here (to say the least); COBOL, Fortran, VB6, MATLAB ... all very good languages, just not good for teaching computer sciences and their abstractions. – Rook Oct 07 '11 at 10:42
  • @pdr - A stereotypical thought with so many wrongs in only one comment, I won't even bother to single them out. – Rook Oct 07 '11 at 10:45
  • 5
    @Rook - do those really all count as domain-specific languages? Even MATLAB, IIRC, is still capable of general-purpose programming. I thought DSL mostly applied to things like yacc, lex etc - languages that are only really capable of a fairly narrow task, leading to the other common name "little languages". It never occurred to me that COBOL, Fortran or VB could be called domain-specific. Of course they each tend to be used in particular fields, but I thought they were still usually considered general purpose languages. –  Oct 07 '11 at 10:53
  • 1
    @Steve314 - Yes, well - we can say there are two sides. One says the dom.spec. ones are only those you mentioned, the other takes a more general view and counts in the one I mentioned too, while still keeping them in the general purpose category. But practically, wherever you mention engineering and sci. comp. you'll get Fortran or MATLAB, business ... COBOL ... use the terminology which seems most logical to you. I use this one because I find it fits with most people. In any case, they do get a fair share of bashing for some reason from the cs community in general. – Rook Oct 07 '11 at 11:49
  • Before getting too wrapped up in Gartner, go over to Gartner.com, register a free account, go to the Research tab, and search on the keyword COBOL. You get summaries and a keyword snippet, and you have to sift to find something that really intuits. However, it seems clear that Gartner is quietly pushing businesses to move off COBOL as they appear to see COBOL as winding down. – Kennah Oct 19 '11 at 08:24

9 Answers9

69

COBOL was one of the first languages I learned - if you ignore countless versions of Basic, three or four assembler languages and a variant of Forth, then it was in my first five, and learned concurrently with Pascal. IOW, I'm answering from personal experience using the language.

EDIT I should say ancient experience. I never used the language after the end of the 80s, though I did buy a new book (to replace the old one I threw away in disgust) so that I had something to refer to so my horror stories wouldn't get too distorted. But I have no idea how the language has evolved in at least the last 20 years.

Obviously, for many people, it is just that "old is bad" view that jonsca has already described - and also much more a third-hand pass-me-down attitudes thing. But there are real issues underlying that.

Being too wordy is a real problem - there's too much clutter in the way of understanding the code. This is by far the biggest issue. People who look at the MOVE, ADD and MULTIPLY etc statements in horror have a slightly exaggerated view of this, true - the COMPUTE statement is closer to the assignments in other languages. But there's still a lot of clutter in all those divisions and sections. One of the first things I learned in COBOL was to always start by copying a standard page-of-A4-long SKELETON.COB.

COBOL does have some interesting features, but those features (e.g. the PIC thing) tend to be things that are now more part of the DBMS rather than the programming language, and that seems to me to usually be a better way to separate those responsibilities. Also, some libraries in other languages use something comparable to PIC (e.g. printf and scanf in the C standard library). Arguably, the best has been kept, but the worst dropped.

Also, for every nice feature, there was at least one intolerable one. For example, no matter how trivial a loop is, you have to move the body into a separate procedure. The PERFORM ... UNTIL ... and similar statements are single statements - not block structures. In a sense, COBOL was a taste of structured programming from before structured programming was invented - there was a GO TO, but it's use was discouraged (at least when I used COBOL), but looping in particular just wasn't handled that well.

In fact, the language that I used after COBOL that most reminded me of it was... dBase. As in Ashton-Tate dBase III+. These days, people are more likely to remember all the now-dead-or-dying clones (Clipper, FoxPro etc) that led to the generic name xBase - and there is still a living descendant in xHarbour. The point is that these were database languages, but nothing like SQL.

Even then, where every COBOL program operating on a particular database needs to include a copy of the specification of that database (and the copies could end up inconsistent), that isn't really the case in xBase where the database knows it's own structure.

Taking that into account, then, COBOL is not so terrible if you accept it for what it is. But what it isn't is a language for writing data structures. Which may be why COBOL suffered a lot back in the times of the C vs. Pascal holy wars - both sides could agree that COBOL was no good for reinventing the binary tree yet again.

Oh - and one thing I'll never forget is how my first COBOL textbook didn't describe the SORT command, saying that it was outside the scope of the book - apparently, either the author couldn't cope with the idea of sorting, or considered it to be more than the tiny little minds of COBOL students could cope with [see edit at end]. That kind of thing made it very difficult to take COBOL seriously.

An odd aspect of this was Jackson Structured Programming, which I also was forced to learn at around the same time, and specifically for use with COBOL. Part of this was drawing a structure diagram for the input, then a structure diagram for the output, then drawing the in-between structure diagram for the code. Sorting was clearly expected to be an already-solved problem - you couldn't derive a sorting algorithm in this way. So it was odd to be told by the recommended text-book that the whole concept of sorting was beyond my tiny little mind, while at the same time being taught something like a dozen different sorting algorithms and how to implement them in Pascal.

The problems that JSP can handle are probably a good guide for the things that COBOL can do relatively well. But even then, that doesn't necessarily mean that either JSP or COBOL are good ways to handle those problems.

EDIT on 30th July 2014

I just got a reputation boost from this, reminding me it's here. As it happens, due to some nostalgia-fueled ancient book collecting, I can now correct a point WRT the SORT command.

The book I originally used as the recommended text when learning COBOL was "Methodical Programming in COBOL" by Ray Welland. This doesn't cover COBOL 85 (though there was a later edition "Methodical Programming in COBOL-85" which I've still never seen).

kindall comments below that "You were supposed to sort the input files before reading them, or sort the output file after generating it, using the sort utility that came with the OS". From my reply to that, I missed the "came with the OS" point. Kindall was suggesting something akin to the Unix philosophy AFAICT, with COBOL used for the bits it's good for, OS utilities such as a sort utility used for some other things, and presumably using a batch/scripting/shell language to glue the bits together. This makes much more sense in an ancient world where interactive software was rare to non-existent, so you'd be submitting batches of work (hence "batch language") anyway.

The following is quoted from page 165-166 of "Methodical Programming in COBOL"...

The use of ordered serial files implies that it is necessary to have a means of sorting records within a file into some specified order by key. Most larger computer systems have a sort utility which will sort a file given the position, type and size of each of the data-items forming the key.

There is also a facility for sorting records from within a COBOL program but this is beyond the scope of this book for two reasons:

(a) the interface to the operating system is often quite complex and varies from system to system,

(b) the sort module is an optional part of ANS '74 COBOL and may not be implemented in COBOL systems for smaller computers.

Therefore it will be assumed that facilities exist for sorting files into a specified order and the problem of updating such files will be considered.

In short, kindall is correct - the assumption was that usually sorting would be done outside of COBOL. There may even have been a real justification to excluding sorting from a programming language around 1974 for small computers.

What I said above was basically what you get after around 20 years of not being able to check facts due to throwing away the book.

I should still point out, though, that I formally studied COBOL from this recommended book that covered the 1974 standard (not the 1985 standard) in 1988 and 1989. The third edition of "COBOL for Students" (Parkin, Yorke, Barnes) - the first edition covering COBOL 85 - wasn't published until 1990. I'm not certain, but I think the COBOL 85 edition of "Methodical Programming" wasn't published until 1994.

But that doesn't necessarily represent the COBOL world dragging its feet - well, not that much anyway. New standards adoption takes time for any language, even now.

  • 5
    +1 For actually knowing what you're talking about. Wish I could give you another +1 for JSP. Did you ever use "Delta"? It was a Cobol generator such that you could write your JSP into the code, in a similar style to the memory definitions (01 - 03 - 05) and then write your Cobol into the gaps. Both fun and frustrating as hell. – pdr Oct 07 '11 at 08:23
  • Sorry, no - to me, "Delta" referred to a database program (possibly just a front end) on DOS PCs in the mid-to-late 80s. It sticks in my mind because it had this text-mode menu system where pressing Escape would *usually* take you out one level, but there was at least one case where escape would push you back down several levels, so that in some cases you weren't allowed to back out from a menu-misnavigation, and were forced to try and find a minimal-damage action to perform to get back to the start. Oh - and also a shoot-em-up for the C64 with some nice music :-) –  Oct 07 '11 at 08:42
  • interesting, sounds like JSP is like TDD for RegExps – jk. Oct 07 '11 at 09:31
  • 3
    Wikipedia page on JSP - http://en.wikipedia.org/wiki/Jackson_Structured_Programming. When I learned it, it was all done on paper. –  Oct 07 '11 at 09:36
  • +1: Even though this answer brings me back to places where I _really_ don't want to be. – Binary Worrier Oct 07 '11 at 11:04
  • This also hearkens back to the days of no interactive debugger. In the IBM world we called that type of debuging IEHEYBALL and IEBTHUMB. – Robaticus Oct 07 '11 at 13:23
  • @Robaticus - there were plenty of debuggers around then - I didn't have access to one for COBOL, but I certainly had access to one for Pascal. However, while I approve of using a debugger as an alternative to manual dry-running for getting a better understanding of a few bits on low-level code, if you routinely need a debugger just to read your code it's a bad sign. Besides, clutter is still clutter, even when it's in a debugger window. –  Oct 07 '11 at 13:39
  • +1 You're making me laugh. I once prototyped a reverse-engineering tool for COBOL. It could be worse. There's always RPG. And don't forget [plugboards](http://en.wikipedia.org/wiki/Plugboard). – Mike Dunlavey Oct 07 '11 at 13:41
  • What I wound up missing the most was functions. Stuff that would be a few nested function calls in a more structured language would require additional variables and lines of annoying calls in COBOL. Like Steve314, I haven't touched it in over twenty years, and know nothing of more recent developments. I intend to keep it that way. – David Thornley Oct 07 '11 at 16:04
  • I have good news for you COBOL is still basically the same. So you can pick it up right where you left off :) I am guessing that this is because anyone with the skills to improve the language would run far away from any project involving the language. – SoylentGray Oct 07 '11 at 16:50
  • 1
    The reason that sorting was treated as a solved problem was that it was. From my recollection, COBOL really discouraged having more than one or two records in memory at a time (the current record and *maybe* the previous one). You were supposed to sort the input files before reading them, or sort the output file after generating it, using the sort utility that came with the OS. – kindall Oct 07 '11 at 21:10
  • @Kindall - JSP isn't COBOL. And even in COBOL, sorting isn't an already solved problem if no-one will tell you the syntax of the command. To be fair, the book I still have now does tell you that, but that one recommended textbook is one of the few programming books at the time that didn't at least describe a bubblesort (so at least that was a good thing), and the only programming book I ever read that seemed to consider that even using a ready-cooked sort facility was too advanced for it's readers. –  Oct 08 '11 at 05:31
  • As for JSP - if you're using almost anything other than COBOL, (old-style) Basic or assembler it's just pointless. The kind of code you can "design" using JSP is trivial - easier to code directly. Drawing the final code structure diagram doesn't help write the code or communicate its purpose. An algorithm that might need explanation *isn't* explained (or designable) using JSP. The diagrams for the input and output structure *may* have a purpose, but that could be documented more clearly and easily in other ways. For Basic and Assembler, Warnier-Orr is the alternative not-really-design diagram. –  Oct 08 '11 at 05:44
  • MOVE CORRESPONDING was kind of cool. Otherwise, I can't say I've missed it much in the last 23 years. Or at all, really. – Mike Woodhouse Oct 08 '11 at 14:09
  • 1
    I did some COBOL for a couple years (for reference, I'm only 26), and I can clarify one thing for you. You no longer need to define paragraphs for each loop, you can now inline it with `PERFORM UNTIL` to `END-PERFORM` blocks. I really hate that I know that. – AgentConundrum Oct 14 '11 at 05:43
  • @agent F.Y.I. virtually all of the critism I see here goes back to pre 1985 versions of the language. If these COBOL bashers could get their heads out of 1960's to re-evaluate the language as it exists today, they would not find a lot to grumble about. – NealB Oct 17 '11 at 16:07
  • 1
    @NealB I was just clarifying the point for him, since he admits his experience is outdated, even by COBOL standards. I get your point about COBOL85, but there is a lot of old code out there that was either started before it existed, or was written by people who had their heads stuck in a previous version. You really can't assume a codebase is up to 85 standards, but even if it is, it's still an uncomfortable language. Older programmers are retiring quicker than they're being replaced, and very few new programmers want to work in COBOL. I know I wouldn't want to touch the stuff again. – AgentConundrum Oct 17 '11 at 16:40
  • @NealB - My old book covers the 1985 standard - though I hadn't checked that when I wrote this answer. What I was taught may well have been pre-85 COBOL. I wasn't even born in the 60's, so my head definitely isn't stuck there. My criticism is based on what was normal around the late eighties and early nineties, at least as far as I could see at the time. –  Oct 17 '11 at 16:56
46

Having spent most of today writing some COBOL I think I can give some current input.

First the BAD stuff:-

  • No function calls. Modern COBOL has some built in functions but its a serious engineering job to write your own.
  • No type checking on subroutine calls. You can pass (or not pass) anything on a subroutine call, the called subroutine will blithely assume it has the correct parameters, and, there is no way to detect missing or invalid parameters.
  • No libraries. None zero zilch. No standard libraries, no widely used easily available libraries. You end up coding commomplace tasks by hand over and over again.
  • Everything is implemented as a keyword. Because the language authors don't have the concept of a library every new feature ends up being implemented with new keywords e.g. PARSE and RENDER for XML support.

The misunderstood, i.e. those criticisms commonly leveled against the dear old language which are invalid or irrelevant.

  • Verbosity. So you type a few extra characters! Its not a serious issue. In many cases COBOL is less verbose than say Java.

  • "COBOL FILES" You see this term bandied around a lot. There is no such thing its just that COBOL can handle just about any file format and just about any file organization.

  • No multi-threading. In the environments where COBOL thrives, multi-threading is usually left to application containers like CICS or IMS which are good at it, rather, than programmers who tend to be bad at it.

And the good stuff - some aspects of COBOL are superior to other languages:-

  • Data structures. COBOL has a concise and flexible syntax for defining complex data structures and odd data types.
  • Decimal Arithmetic. It has native support for decimal arithmetic i.e. arithmetic as understood by accountants, with proper rounding etc.
  • Moving with the Times. Some aspects of COBOL are surprisingly modern. Built in XML support, support for OO programing, the ability to use Java classes etc.
  • Integration with DB2,CICS etc. This only applies to IBM's mainframe COBOL (but that is by far the largest chunk of COBOL still running) but the integration with DB2, CICS and other mainframe environments make it easier to code up things like data base backed web services than in any other environment.
  • Screen handling. The standard screen handling as implemented on AS/400 and MicroFocus Cobol is excellent.
  • Performance. For many years COBOL compilers have been producing very high performance executables. Only native C and native Assembler beat COBOL on an IBM mainframe.

So all in all its doing quite well for something that was put together by a committee in the 1950s. If an existing application is implemented in COBOL and does the job there is no reason to re-write it. However unless there is a really good reason I don't see any justification for new projects to use COBOL.

James Anderson
  • 18,049
  • 1
  • 42
  • 72
  • 2
    In my answer, I say COBOL is bad for data structures. Is this a difference in what "data structure" means? Maybe the record-layout tools are excellent, but COBOL is still the wrong language for binary trees etc? Or maybe my experience of COBOL was just too old or otherwise limited? Key question - does COBOL have pointers? (Worryingly, a quick Google suggests yes, though my old book suggests no). I'd hate to retract an answer that earned all those lovely rep-points for me, but if I'm wrong... –  Oct 07 '11 at 13:31
  • 3
    There's a downside to the decimal arithmetic: you have to say exactly how many digits you want. I remember finding bugs when we had one too few `9`s in the `PIC` clause in some program within a group. – David Thornley Oct 07 '11 at 16:12
  • 2
    My (uninformed) impression is that COBOL is particularly good at dealing with data in rigid, fixed-size records. Not so good, perhaps, at dynamic data structures. Correct me if I'm wrong. – Barry Brown Oct 07 '11 at 19:19
  • @Steve314 -- yep pointers came in about 1985 but were a bit lame as you could only set them to stuff in the linkage section. Later versions allowed you to point to anything. – James Anderson Oct 10 '11 at 01:37
  • 1
    @Structures -- while its not up to Python standards in in terms of hashes and trees etc. Its as good as C or Java -- except its not as good a C++ plus Boost or Java plus the collections Library. Once again the failure to appreciate the value of standard libraries and functions has crippled the language throughout its long life. – James Anderson Oct 10 '11 at 01:41
  • Excellent answer. I find it amazing how quickly some people run in to bash something that they clearly have no recent working knowledge of. Kind of like complaining that cars don't come with FM radios, which might have been true in the 1950's – NealB Oct 17 '11 at 16:28
27

This is probably down to Djikstra. Djikstra stated that "The use of COBOL cripples the mind; its teaching should, therefore, be regarded as a criminal offense." Cobol was viewed as naive, unstructured and verbose. With the ability to self-alter code (a practice discouraged even among cobol programmers) it was viewed as quite difficult to debug or follow too.

Then there is the matter of great incompatibility between versions too.

I would suggest reading the criticism and defence section in Wikipedia for the language - http://en.wikipedia.org/wiki/COBOL#Criticism_and_defense

Danny Staple
  • 469
  • 3
  • 8
  • 21
    Someday they'll discover a vault filled with code written by Dijkstra in languages he denounced. – jonsca Oct 07 '11 at 07:10
  • 7
    @jonsca - you'll be surprised at what you'll do for money. – JeffO Oct 07 '11 at 07:20
  • 3
    Incompatible versions was IIRC pretty common until at least the 70s, and even in the 80s there was Basic. Dijkstra was probably making his point based on an issue I mention in my answer - COBOL isn't good for (or meant to be good for) data structure coding. Therefore, for a particular value of "teaching programming" or "teaching computer science", COBOL really is poison. Of course since COBOL isn't intended for that, it's a pretty unfair claim - but then again, IIRC, the context was that some people *were* trying to teach these things using COBOL. –  Oct 07 '11 at 07:51
  • @jonsca: be filled with gotos. start: Those programs will also goto : – Vinko Vrsalovic Oct 07 '11 at 09:07
  • 2
    Dijkstra <- a man who talked too much ... – Rook Oct 07 '11 at 12:01
  • A hard-to-debug practice discouraged even among the programmers? Not much of a reason if you ask me. Look at C's `goto`, Javascript's optional semicolons, any interpreted language's `exec`... – Petr Viktorin Oct 07 '11 at 12:08
  • 1
    @Danny - imcompatibility? Gee, I wonder if any other prog. language had a problem with that ;) (don't think python, don't think python, don't ... drat, I thought of it ...) – Rook Oct 07 '11 at 12:28
  • 3
    @Danny: COBOL was despised well before Dijkstra wrote that line in 1975. – John R. Strohm Oct 07 '11 at 13:22
  • +1 Dijkstra was an academic. So was I. Academics can get away with that kind of pronouncement. It's a way of getting people to ignore them even when they are right. – Mike Dunlavey Oct 07 '11 at 13:44
  • Isn't C unstructured with the ability to self-modify? And isn't terse less useful than verbose? – Rob Perkins Oct 07 '11 at 16:47
  • @Rob - there's no self-modifying in C. To be honest, I'm not convinced the COBOL "ALTER" is self-modification either - it depends on how it's implemented by compilers - but it's definitely freaky. C has a goto, but at least it goes to the label that it says it does. And C *has* all the usual code structures, similar to Pascal, but with unstructured add-ons like `continue` (I'm not sure if Pascal has an equivalent of `break`). My god - how can I end up comparing C and Pascal, and it feels like they are the shinier newer languages! –  Oct 08 '11 at 05:56
  • @Steve314, of course self-modifying is permitted in C; clever viruses always take advantage of buffer overruns and such to load data in a data segment and then switch execution to it. Most all the programs with those vulnerabilities (IE6 comes to mind) were written in C. – Rob Perkins Oct 12 '11 at 22:56
  • 1
    @Rob - that isn't what's meant by self-modification. Self-modifying code is code that intentionally modifies itself as part of its normal behaviour. For compiled languages it either requires some special source-code construct, or explicit knowledge of the code the compiler will generate. It is possible to write code that self-modifies in C by abusing certain low-level features, and some features can be exploitable, but there is no feature of C which is intended to allow, or which can reliably allow, self-modification. –  Oct 13 '11 at 00:59
  • @Rob - for example, most buffer overrun attacks are blocked by using platform-specific features that prevent programs from writing to executable-code memory blocks, or by putting the executable code in ROM. Both of these approaches are entirely compliant with the C standard. There is no standard C feature that reliably allows buffer overrun exploits to modify the code - vulnerability to those exploits depends on the compiler, library and the platform, not (pedantically) on the language. Implementing C in a completely safe way on most platforms would be impractical, but that's not my point. –  Oct 13 '11 at 01:08
  • @Steve314, if you can `asm` out, you can self-modify, full stop. Calling that an abuse of a C feature is a dodge, in my opinion; asm is a C keyword, therefore the language facilitates self-modification. Now, if you use `asm`, then it's not C any longer, and we're into pedantic arguments, sure. Personally I think C is a lexical travesty, (What does "}}}}" mean again?) useful in the places Ritchie intended, but otherwise an unfortunate language choice for robust LoB coding. I think COBOL is actually better for that, but not better than other choices today. – Rob Perkins Oct 17 '11 at 23:30
  • @Rob - I never said anything about C being a wonderful language. I don't think I've ever seen that many braces packed together, though - that looks more like LISP, only in that case it's usually about twenty or thirty closing parens. Braces are for block structure, and I usually put the close brace where the `end` would be in a Pascal-family language - on a line of it's own. People who collect their close braces together and hide them off the RHS of lines will go to a *special* hell. –  Oct 18 '11 at 00:14
  • The "}}}}" is more a function of the limits of this forum; most of the time decent tooling will put them in indented lines. Its equivalent to me would be something like "Next counter: End If: End Select: End Function", which at least gives clues as to the flow control in a long code file. Yeah, I'm off on a little tangent; I've always hated C compared to other languages; case insensitivity, a memory manager, and a requirement for verbosity prevent more bugs than their lack facilitates, in my opinion. COBOL possesses those three things; C does not. – Rob Perkins Oct 18 '11 at 18:32
9

It's age and verboseness are typically the things that make people groan about it.

I seem to recall that the main aim for IBM when designing COBOL was that it "should allow a bank manager to write a program". This goal obviously had a profound affect on the way the language was designed, and it now it evolved.

Apparently there's more COBOL out in the wild than any other language. However, after working in IT for almost 20 years (15 in banking) I've never encountered a single system that was implemented in it.

Sean
  • 1,124
  • 6
  • 10
  • I'd heard someone mention banking in passing, which is the only reason I included it, but I'll certainly take your word for it over someone else's. – jonsca Oct 07 '11 at 07:06
  • 4
    I worked for 20 years in Banking, almost all of it in COBOL. Different banks have done things different ways I suppose. – TrueDub Oct 07 '11 at 07:52
  • I know of at least one major ERP system that has (or had up to about 2007) a lot of COBOL in it. – Alan B Oct 07 '11 at 08:39
  • 2
    It was not IBM who designed COBOL. The main instigators were the US Navy and UNIVAC. – James Anderson Oct 07 '11 at 10:25
  • @My IRS (it's not called IRS in here, but for the general audience ...) uses an app with both front & back end written in COBOL. Not on old hardware. – Rook Oct 07 '11 at 11:58
  • 10
    *"the main aim for IBM when designing COBOL was that it "should allow a bank manager to write a program"."* A noble goal, although the vast majority of managers I know can't even write me simple literature for a website, let alone write COBOL. – maple_shaft Oct 07 '11 at 12:25
  • Admiral Grace Hopper was a key figure in the development of what would become COBOL. Her understanding that the issues of debugging and coordination between programmers and users led to the popularity of "human readable" programming languages, like COBOL. The idea was that you could hand the program to the client who could verify the routine. Also by having the program in pseudo-english, more people could read it and possibly find bugs. She's also credited with the term "debugging" and I happen to have one of her "nanoseconds". I don't think the NAVY wanted the client writing the program. – Edwin Buck Oct 07 '11 at 15:19
  • very first system I ever worked on was written (largely) in Cobol. AFAIK it's still running today. And no, it wasn't a banking system but a mobile telephony system. I moved on in part because I wanted something that wasn't Cobol, mostly because in a buyout the buying partner pretty much shafted us financially to the point where we'd end up seriously underpaid and with far fewer benefits than our new colleagues doing similar work. – jwenting Oct 19 '11 at 10:59
8

What's so bad about COBOL?

Nothing.

I think people have a preconceived notion that old is bad, "newest is bestest". It's still very much in use, and I'm sure there will be enough maintenance work on code to be had for another half century.

In 1997, the Gartner Group reported that 80% of the world's business ran on COBOL with over 200 billion lines of code in existence and with an estimated 5 billion lines of new code annually. (via wikipedia)

In coding, one must always select the best tool for the job, and with certain industries that are married to certain hardware, the language is optimal. I've never worked in banking, where I had heard it was popular, but Sean's answer indicates this isn't the case.

If there's a problem with legacy code looking old, as long as you can slap a UI or a web interface in front of it, most users won't even know the difference.

jonsca
  • 585
  • 3
  • 10
  • 28
  • 1
    Languages are for users? – JeffO Oct 07 '11 at 07:23
  • @JeffO If the users are paying the bill, yes. ;) I modified that sentence a bit, as I see what you are saying. – jonsca Oct 07 '11 at 07:27
  • 16
    "Lines of code" is not a good cross-language measure. COBOL is notoriously verbose. Those 5 billion lines of code anually are probably equivalent to seventeen regex'es ;) – MSalters Oct 07 '11 at 07:52
  • 3
    Sometimes COBOL is the right tool for the job - a lot of times it isn't. The hard part is getting people to recognise the difference. – TrueDub Oct 07 '11 at 07:53
  • 1
    Quite true, @TrueDub. My sentence sounded a bit salesy, but it wasn't meant to be. – jonsca Oct 07 '11 at 08:01
  • @MSalters Characters per operator then? ;) – jonsca Oct 07 '11 at 08:03
  • 1
    @TrueDub - this is true for every language to be fair. – temptar Oct 07 '11 at 09:10
  • @temptar - languages like C, C++, Java, C#, Ada, Modula-2, Pascal etc each have/had their strengths and weaknesses, but also have a lot in common, and are more in line with the usual "right tool for the job" comparisons. COBOL is further outside that Algol-derived cluster. Not the same degree of culture-shock as Prolog, but without good reason, most people aren't going to get through that shock to the point that they can form a more balanced view. –  Oct 07 '11 at 09:47
  • 3
    @TrueDub: If COBOL is the right tool for a job, I don't want to do that job, as long as I have alternatives. There are far more interesting jobs I can get paid well for. – David Thornley Oct 07 '11 at 16:07
  • @temptar, I agree, every language has it's place – TrueDub Oct 10 '11 at 10:37
  • @DavidThornley, everyone's entitled to make the best choice for them, assuming they have choices. Sometimes, though, cobol is simply the best tool for the job - just as assembler, C, Java Python and every other langauge has their place in our armoury. No point in arguing over screwdrivers. – TrueDub Oct 10 '11 at 10:39
  • @TrueDub: I'm not saying that COBOL is always the wrong tool for the job; I'm saying it's only the right tool for jobs I'll avoid unless I have no real choice. Fortunately, other people have different and varied preferences, but I think COBOL and jobs best suited for COBOL are going to seem awful dull to the average person on this site. – David Thornley Oct 10 '11 at 14:07
  • @David Thornley, that's a judgement you can only make for yourself, not for others - I can assure you I've worked on projects and products of immense importance that operate partially or completely through cobol, and at the time I found them fascinating. – TrueDub Oct 11 '11 at 07:41
5

People dislike COBOL because it has limited application. It was designed for business, finance, and administrative systems for companies and governments.

What do all of these have in common? Data. Lots and lots of data.

Guess who was designed to crunch data and have lots of files for breakfast? Can you say COmmon Business-Oriented Language?

50 years ago COBOL was the best thing for large organizations with lots of data to manage. Today there are better ways to manage a large volume of data so COBOL is no longer relevant. Or is it?

Let's consider governments. What data does a government need to track? People ids, birth certificates, medical records, taxes (oh... yes... taxes) etc etc. And they must hold these infos indefinitely, today and 50 years ago also.

People also mnetioned banks in some of the answers and indeed banks are heavy user of COBOL. Why? because unlike other types of companies banks usually have a history. Some exist for hundreds of years (like this one for example).

That means that some data from 50 years must still be here with us, today, the 7th October, 2011. Now we have SQL Server and C# or Oracle and Java, but 50 years ago there was COBOL and files.

As time passed the data for govs and banks grew larger and larger and it was more and more expensive to migrate the systems. Which means they must remain in COBOL and be constanlty maintained and evolved as business evolves. Some banks are slowly migrating while other just stick a nice Web2.0 interface in front of the mainframe (c# and Java are the mostly used). Can you say legacy code? (COBOL goes hand in hand with (extreme) legacy code, some that was touched by plenty of people over decades of existence - another thing we programmers don't like :D).

And now you have a niche of activity. COBOL now has limited application and your experience is affected.

And people who get into COBOL eventually discover that you do the same thing over and over and over again, year after year after year and by the time they wake up they are no longer competitive on the market because people now want PHP, Java, C#, REST, jQuery and only banks look for COBOL people.

At this point the demand is lower than the supply and those who don't make the cut must move to something else. And they must start as juniors since COBOL does really cripple the mind (believe it of not Copy-Paste is the main style of development in COBOL and accounts for large its large productivity) and now they curse the day they picked up COBOL and don't lose any occasion to tell their horror stories about it :). But you could tell those stories about any old fart language that is no longer in demand these days but you are the unfortunate person stuck with it. O well...

P.S. and COBOL is bad for all the other reasons mentioned by the others :)

P.S.2. In 1997, the Gartner Group reported that 80% of the world's business ran on COBOL with over 200 billion lines of code in existence and with an estimated 5 billion lines of new code annually. Really? And how did day measure that? Did they go do every company in the word and ask them how many lines of COBOL do they have or what?

4

Two features.

  • The ALTER statement is pure evil. While rarely used in more modern COBOL applications, it was heavily used in the "olden days" because it was more efficient than the equivalent "IF-GOTO" structure. When computers only had 32K of RAM, each instruction mattered. It modified a GOTO statement to have a different destination.

    This made some code opaque because the code itself was stateful.

  • The REDEFINES clause in a data structure (like the union in C) is a perpetual problem. The term "free union" -- i.e., overlayed data structures without a discriminator -- is a way to summarize the problem. Two REDEFINES aliases cannot be trivially distinguished by the data; only extensive reading of program logic could determine the meaning of the two alternate interpretations of the bytes.

    This made many data structures opaque because the data cannot be understood without the code.

The readability of the English-like syntax was defeated by these two constructs.

[I've been warned by moderators that short answers are dismissive of your important and interesting question. If you find this dismissive, you could ask for details. Or flag it so that the moderators can delete it.]

S.Lott
  • 45,264
  • 6
  • 90
  • 154
  • I don't remember either of those - either repression, or I never learned them. A quick search tells me that I certainly agree that `ALTER` is evil, but this feature is rarely if ever used, so it isn't really a reason to hate COBOL. I'm not so sure about `REDEFINES`, though. Comparing it with `union` makes me think a bit more kindly towards it - but maybe what's OK in a low level bit-fiddling and data-structure handling language may not be such a great idea in data processing. –  Oct 07 '11 at 10:41
  • Sometimes your answers strike me as dismissive, but this one is just useless. I don't know whether you are trying to help here, but doing it badly, or if you are just talking to yourself. I could ask you what you mean by 'pure evil', but the beauty of the good answers above is that I don't need to start a conversation in order to learn something. – Eric Wilson Oct 07 '11 at 12:43
  • @EricWilson: Thanks for dismissing my answer so thoroughly. That helped me understand what more needed to be added. – S.Lott Oct 07 '11 at 13:07
  • 1
    @Eric - the problem with `ALTER` is that it redirects gotos. First, that means you're using gotos - in itself I don't think that's evil, but in most languages it's an unusual special-cases thing. Second, that means the gotos go somewhere other than where they say they'll go to - and that's just terrifying. I'm not really convinced this is self-modifying code, but it's described as that where I looked, and thinking of it as modifying jump-instruction targets in assembler explains why. –  Oct 07 '11 at 13:08
  • @S.Lott Thanks for your additions (you too @Steve314), I learned something interesting, and reversed my vote. – Eric Wilson Oct 07 '11 at 13:47
  • @S.Lott Despite your generally dismissive attitude to most questions and comments, I can't upvote you enough for pointing out how evil `ALTER` really is :) – maple_shaft Oct 07 '11 at 13:58
  • @maple_shaft: I try not to be dismissive. I do not know how much other professional programmers know. Rather than post too much useless detail which everyone already knows, I feel it's better to post less and add based on comments. Apparently, I'm totally wrong on that count, and should -- it appears -- assume that the professionals don't know very much at all. I feel that over-writing an answer is dismissive of the experience that other professionals bring to the site. However, I've been told that I'm wrong in trusting others. – S.Lott Oct 07 '11 at 14:37
  • Use of ALTER has been actively discouraged for the past 40 years or so. I've earned a living as a COBOL programmer for the past 25 years and have yet to come across it in the "wild". I somewhat agree that REDEFINES can be misused but it does have valid useage too (work hard enough at it and anything can be misued). – NealB Oct 17 '11 at 15:53
  • @NealB: I'm quite sure that scorn against COBOL is debatable and perhaps even unjustified. I'm not scorning COBOL. just describing two known sources of that scorn. I've seen ALTER in the wild. It was disturbing. – S.Lott Oct 17 '11 at 16:58
3

I have programmed in COBOL for several good years. Its syntax is simple compared to today's languages and you don't need to much theory to learn to get going. COBOL worked very well with IBM's CICS (an on-line transaction management system) and the programmer needs to do noting in the code to scale the application number of users from 1 to several thousands. CICS provided a character based GUI that worked with a screen as a unit of display (no windows). You could display charts using (IBM's GDDM) on the mainframe. COBOL can talk to indexed files (VSAM and ISAM) as well as DB2 (SQL based relational) and also IMS. COBOL/CICS is a very robust environment and you can learn it in few weeks. That means you focus on the business not on the technology, so you work 7 out of the 8 hours on coding not at learning MVM, JavaScript and the like.

The issue with COBOL is bad marketing that lead to lack of interest from 3rd parties to develop tools and programming environments for it. Also, its lack of support to Windows like interface caused its popularity to decline after 1993. The mainframe cost lead customers to look for alternatives and compilers for COBOL was available in UNIX and DOS. The C language drew much of the light as it was able to be more portable and had direct access to OS functions which is something COBOL had very little of.

Languages like VB, DBase,FoxPro and Clipper had better ways to access 'databases' on the PC than the comparable COBOL on DOS so COBOL lost. CICS was not made cheap on DOS or UNIX for a long time, so its value was not present on these environments.

Today, COBOL is supported with .NET but I guess that it has lost the battle on all platforms except the mainframe (and possibly AS/400) where it is still there because of the huge number of mission-critical applications that are fully dependent on it.

NoChance
  • 12,412
  • 1
  • 22
  • 39
  • "lack of support to Windows like interface".... what about http://www.netcobol.com/products/Fujitsu-NetCOBOL-for-.NET/overview – JoelFan Oct 07 '11 at 19:21
  • @JoelFan thanks for your comment. You are correct that today, there are better tools for COBOL but I think that they all have arrived too late. My point regarding lack of if support to Windows interface was bout the beginning of the 90s where only Micro Focus was the only player on the market. – NoChance Oct 07 '11 at 19:45
2

Heh, I went to college in the early 80s, and people were scornful of COBOL even back then. I think the biggest problem is its verbosity -- a simple "Hello, world!" in COBOL is probably over fifty lines, 95% of which are required boilerplate. It's just not a very elegant or attractive language. It was also designed to handle yesterday's problems, and doesn't really lend itself to development paradigms developed after about 1970. It's a pretty good report generation language — as long as your reports are endless columns of numbers with headers and footers. If you want to stick in a graph or a logo somewhere, forget it. I think it's still the fastest language for "data processing"-type tasks (take a fixed-format file with 5M ATM transactions and do a simple balance adjustment for each one), but how many developers do those kinds of things any more? And lots of systems use XML or JSON nowadays, I'd hate to think about trying to parse anything like that with COBOL (actually, I'd hate to think about parsing in general in COBOL!)

TMN
  • 11,313
  • 1
  • 21
  • 31
  • 2
    ["Hello World"](http://en.wikipedia.org/wiki/COBOL#Hello.2C_world) takes how many lines?. Parsing/generating XML - is now built into the language. Maybe you should be upgrading your knowledge base. This answer belongs to the 1960's era of COBOL. – NealB Oct 17 '11 at 16:20
  • Interesting. I haven't had to work with COBOL for close to a decade, but that last time I saw it it was written just as I remembered it, IDENTIFICATION DIVISION, WORKING-STORAGE SECTION and all. I guess all those "required comments" (AUTHOR, DATE-WRITTEN, SOURCE-COMPUTER, OBJECT-COMPUTER) are optional now. XML parsing doesn't look that impressive -- you have to structure the data division to reflect the file structure, there's no SAX or DOM-style processing. Good to know it's there, though. – TMN Oct 17 '11 at 18:10