WHY COBOL LOSSED IT'S POPULARITY

                            COVER PAGE OF COBOL 60 PRGRAMING LANGUAGE




                   

Lack of structure

In the 1970s, adoption of the structured programming paradigm was becoming increasingly widespread. Edsger Dijkstra, a preeminent computer scientist, wrote a letter to the editor of Communications of the ACM, published 1975 entitled "How do we tell truths that might hurt?", in which he was critical of COBOL and several other contemporary languages; remarking that "the use of COBOL cripples the mind".  In a published dissent to Dijkstra's remarks, the computer scientist Howard E. Tompkins claimed that unstructured COBOL tended to be "written by programmers that have never had the benefit of structured COBOL taught well", arguing that the issue was primarily one of training.
One cause of spaghetti code was the GO TO statement. Attempts to remove GO TO s from COBOL code, however, resulted in convoluted programs and reduced code quality.GO TO s were largely replaced by the PERFORM statement and procedures, which promoted modular programming and gave easy access to powerful looping facilities. However, PERFORM could only be used with procedures so loop bodies were not located where they were used, making programs harder to understand.
COBOL programs were infamous for being monolithic and lacking modularization. COBOL code could only be modularized through procedures, which were found to be inadequate for large systems. It was impossible to restrict access to data, meaning a procedure could access and modify any data item. Furthermore, there was no way to pass parameters to a procedure, an omission Jean Sammet regarded as the committee's biggest mistake.Another complication stemmed from the ability to PERFORM THRU a specified sequence of procedures. This meant that control could jump to and return from any procedure, creating convoluted control flow and permitting a programmer to break the single-entry single-exit rule.
This situation improved as COBOL adopted more features. COBOL-74 added subprograms, giving programmers the ability to control the data each part of the program could access. COBOL-85 then added nested subprograms, allowing programmers to hide subprograms. Further control over data and code came in 2002 when object-oriented programming, user-defined functions and user-defined data types were included.
Nevertheless, much important legacy COBOL software uses unstructured code, which has become unmaintainable. It can be too risky and costly to modify even a simple section of code, since it may be used from unknown places in unknown ways.






                                       

Isolation from the computer science community

The COBOL community has always been isolated from the computer science community. No academic computer scientists participated in the design of COBOL: all of those on the committee came from commerce or government. Computer scientists at the time were more interested in fields like numerical analysis, physics and system programming than the commercial file-processing problems which COBOL development tackled. Jean Sammet attributed COBOL's unpopularity to an initial "snob reaction" due to its inelegance, the lack of influential computer scientists participating in the design process and a disdain for business data processing. The COBOL specification used a unique "notation", or meta language, to define its syntax rather than the new Backus–Naur form because few committee members had heard of it. This resulted in "severe" criticism.
Later, COBOL suffered from a shortage of material covering it; it took until 1963 for introductory books to appear (with Richard D. Irwin publishing a college textbook on COBOL in 1966). By 1985, there were twice as many books on Fortran and four times as many on BASIC as on COBOL in the Library of Congress.University professors taught more modern, state-of-the-art languages and techniques instead of COBOL which was said to have a "trade school" nature. Donald Nelson, chair of the CODASYL COBOL committee, said in 1984 that "academics ... hate COBOL" and that computer science graduates "had 'hate COBOL' drilled into them". A 2013 poll by Micro Focus found that 20% of university academics thought COBOL was outdated or dead and that 55% believed their students thought COBOL was outdated or dead. The same poll also found that only 25% of academics had COBOL programming on their curriculum even though 60% thought they should teach it. In contrast, in 2003, COBOL featured in 80% of information systems curricula in the United States, the same proportion as C++ and Java.
There was also significant condescension towards COBOL in the business community from users of other languages, for example FORTRAN or assembler, implying that COBOL could be used only for non-challenging problems and that COBOL programmers were not particularly bright


^{CURRENT SITUATION OF COBOL LANGUAGE}



                                                   
Until a few months ago, the clearing and billing system for NYSE Group Inc.’s stock options exchange consisted of about 800 discrete COBOL programs running on an IBM mainframe. Today, the entire application set has migrated onto a pair of clustered, quad processor Windows servers. The recompiled programs remain in COBOL today, but they won't stay there for long.
“It's not our long-term goal to remain running the COBOL applications. That was a tactical move, designed to slide the existing applications off of the mainframe with as little disruption as possible,” says Steven Hirsch, vice president of technology support at the stock exchange.


                                                     So what's wrong with COBOL? The technology, which has been around since 1960, is rock-solid. It excels at batch processing and is practically self-documenting, and tools for it have not only been modernized but also support distributed systems. Vendor Micro Focus International Ltd. even offers COBOL.Net, a part of its Net Express offering that fits neatly into Microsoft Corp's .Net Framework and integrates with the Visual Studio suite of programming tools. But COBOL is also a procedural language in an object-oriented world. While it's well suited to batch operations, the language isn't as good a fit for developing interactive applications or Web-based front ends. And it has a major image problem. Outside of the mainframe data center, COBOL is viewed today by many JAVA, VISUAL BASIC and C# programmers as an obsolete and inferior language, a vestige from the dark ages of big iron.
Most new Cobol programs are written only to extend or support existing applications on the mainframe. For example, Shaun Swift, director of information systems at capital goods retailer Papé Group Inc. in Eugene, Ore., says his company writes new COBOL applications for his back-end systems to accommodate acquisitions.
When COBOL applications are migrated over to Windows, Unix or distributed systems, they remain in COBOL because rewriting them is expensive and risky, not because COBOL might be the best choice for the application. “Nobody wants COBOL, but realistically they can't get rid of it,” says Dale Vecchio, an analyst at Gartner Inc. in Stamford, Conn




                                                      *********************