1. Jan 14th, 2008

    ABEND

           IDENTIFICATION DIVISION.
       PROGRAM-ID. HELLO-WORLD.
       PROCEDURE DIVISION.
       MAIN.
           DISPLAY 'Hello, world.'.
           STOP RUN.

    Yeah, I’m trolling Wikipedia for quotes. Sometimes I spend an hour or two browsing from one article to another with no particular goal in mind, just learning new things I didn’t know before. And occcasionally, I will end up reading articles about computing history, some of which feel relevant even today:

    Critics have argued that COBOL’s syntax serves mainly to increase the size of programs, at the expense of developing the thinking process needed for software development. In his letter to an editor in 1975 titled “How do we tell truths that might hurt?”, computer scientist and Turing Award recipient Edsger Dijkstra remarked that “The use of COBOL cripples the mind; its teaching should, therefore, be regarded as a criminal offense”

    I think it might be due to the fact that:

    Older versions of COBOL lack local variables and so cannot truly support structured programming.

    But then again, not everyone was happy with the continuing attempt to extend the language:

    Others criticize the ad hoc incorporation of features on a language that was meant to be a short term solution to interoperability in 1959. Coupled with the perceived archaic syntax, they argue that it tries to fill a niche for which better tools have already been designed and developed.

    But then again, perhaps it’s not a good idea to argue with success:

    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.

    Printable PDF | Posted by Assaf Filed in general 5 Comments »

    1. Jan 14th, 2008

      Chris Adams

      I’m unusual for being under 30 and having actually written a fair amount of COBOL; exposure to both one of the older languages and many newer ones has left me somewhat mixed on the state of the industry. There are certainly features which should have died by 1970 or so but there were also some rather handy features: e.g. the language spec includes an indexed filesystem so the entire class of bugs related to people poorly handling the task of reading and writing structured data is largely non-existent; similarly the built-in field definitions means that most input validation is trivial (as are most simple form-based apps since the screen section was added, making it possible to say “Here’s a form; get valid input from the user and populate this structure with it” ) and standard accurate decimal math makes accounts like this one about floating-point rounding seem comical.

      The common thread connecting all of these things is that they’re not very interesting problems from a computer-science perspective because they’re “just” things like displaying forms, storing and retrieving data with simple keys, etc. and not interesting except in that the industry has burnt some ridiculous number of man-years reinventing that wheel and dealing with the problems when J. Random Coder gets it wrong. The rise of smarter web frameworks has made me a little more confident that we’re reconsidering the value of getting these common tasks right – it’s somewhat pathetic that it wasn’t until the 21st century that COBOL had competition for being easiest way to write the simple CRUD-style apps which most of the world runs on.

    2. Jan 14th, 2008

      Assaf

      Chris, that does makes you unusual, so double thanks for this comment :-)

      I got exposed to dBase, SQR, PowerBuilder and ABAP (SAP) before — but not COBOL — and I think you’ll find some similarity to COBOL in how simple they are for CRUD-style apps.

      Purebred language theory would categorize them as “languages that suck and not worthy of discussion”, but they do power millions of lines of business code still in production today. And that’s a definition of success.

    3. Jan 16th, 2008

      Chris Adams

      I’d definitely agree that COBOL wasn’t unique in simplifying CRUD-style apps; the part which I wish was more widespread is the way that these features were considered important enough to become first-class language features with generally quite decent levels of portability. Brevity has become far more of a language design goal for classic computer-science tasks; I find it curious that despite having so many more LOC and money involved the commercial world has largely failed to have similar goals for routine business tasks — even after years of exposure to 4GLs and fairly widely recognized criticisms the rule still seems to be dumber languages with arcane boilerplate generators for common cases.

      It does seem like this is getting more attention as a language design feature – I many people were surprised to realize how many people switched to something like Rails not because of the more powerful language but simply because they got tired of having to think about every time they wanted to get structured data in and out of their app (PHP would probably still own this space if they’d provided a decent ORM and form-handling library in the core distribution).

    4. Jan 16th, 2008

      Assaf

      Purebred languages like C and Java are only ever concerned with the generality of the language, not any specific use case. So you end up with APIs that can do anything, given enough lines of code.

      COBOL definitely has the benefit of baking the features you need — for business applications, not necessarily for intergalactic navigation — into the language. Address the 80% use case of the target audience.

      I agree with you about Ruby. It’s purebred, but has just enough hooks to bring the syntax to the simplicity of COBOL, and that’s a big part of the appeal.

    5. Jan 17th, 2008

      Sterling “Chip” Camden

      (shudders) Looking at that code I can suddenly smell the Nature Valley Granola Bars I used to eat while writing COBOL programs, mixed with the odor of greenbar and impact line-printer ink.

    Your comment, here ⇓