How Cobol is business oriented?

Question

Is Cobol business oriented only because it's syntax is like real spoken English? Or is there something more to it and has Cobol frameworks that generate some code too?

If there is no other business oriented aspects in Cobol than English like syntax, then spoken English can be achieved using verbose coding like totalSumOfLowCostItems = salesOrder.GetTotalSumOfGroupItems(ItemGroup.LOWCOST).

Answer 1

Yes, I think the syntax is largely the reason it was referred to as that. As for what you're talking about with coding conventions, you are getting close to what is a hot trend in programming now, namely Domain Specific Languages:

http://en.wikipedia.org/wiki/Domain-specific_programming_language

So, the basic idea is that you program in the "language" of your problem set. For instance, there is a language called ATMOL for Atmospheric Modeling Language.

Yes, you can achieve the same thing in several other languages but the idea is that it is more productive for domain experts (say, atmospheric scientists) to program in a language that is "closer" to their problem domain.

Answer 2

Cobol is business oriented not only because of it's verbose syntax. The main value of Cobol is a huge amount of written code (since 1959). Also for 60-70s Cobol had good facilities of working with data structures and files.

Answer 3

COBOL was the first attempt to produce an end-user computing tool where 'business people' could develop their own applications. Thus, it had a syntax like structured English with the intention that it would be less hieroglyphic than the technologies of the day, which ran to core dumps and assemblers (if you were lucky).

The (ultimately futile) intention was that people who were not programming specialists could write their own programs in COBOL, hence the 'Business Oriented' part of the title.
Like all subsequent attempts (with the possible exception of spreadsheets) it failed because most people don't have the abstract thinking skills to develop non-trivially complex systems.

However, COBOL endured because it did a good job of the data processing tasks of the day, and is still quite good for that sort of task. Plus, there is a large body of existing COBOL code in production where the cost of replacement so far outweighs the cost of running the existing system.

Answer 4

COBOL not only has readable keywords, but comes with features for data processing built in. Things like data definition an manipulation, record based data storage and retrieval, sorting and merging and reporting are all included in the language itself.

Later languages like C++ and Java are less targeted at a specific type of usage and rely on external libraries, frameworks or third party software for such functionality.

Answer 5

COBOL in many ways is a 3GL that was an early attempt at becoming a 4GL language. With the goal being getting business folks to write their own programs, the syntax was verbose and relatively easy to follow.

To elaborate further, true 4GL languages developed later on like MAPPER made a huge difference in productivity in specific verticals when used instead of a 3GL like COBOL. This was the school of thought behind a language "business folks" could use.

Folks who write Oracle based PL/SQL (or in my case, I've written a pile of Progress 4GL code) would be able to tell you that there are some benefits to this style of language though perhaps not to "business based" extent originally hoped for. You've still gotta pretty much be a programmer or at least somewhat technical in order to make the code work for you.

Actually, with the advent of LINQ we're seeing a shift even in the .Net world to have a query language integrated into the syntax itself. Progress 4GL has been doing this since the 80's.

It also re-enforces the point already made about Domain Specific languages as 4GLs are commonly referred to as a subset of DSLs.

We're now seeing new BI and BA products like EasyAsk which is yet again another kick at the cat so to speak in getting business people the results they want without having to track down a programmer or reports specialist. How well these new types of solutions will work remains yet to be seen...

Answer 6

I would like to point out another strength of COBOL. Its ability with decimal precision is intuitive to the language. I believe that's one of the major reasons it has been used so much in the financial sector (IMO).

Answer 7

On Syntax: You get a frantic email from product assurance, telling you interest isn't showing up on a report. You look into it and find out that the type code is wrong. Which of these examples would you feel most confident copying and pasting into your email?

IF TYPE-CODE = 'A' OR 'B' OR 'C'
    MOVE INTEREST-AMOUNT TO REPORT-FIELD-3.


if(type_code == 'A' || type_code == 'B' || type_code == 'C')
{
    report_field[3] = interest_amount;
}


switch(type_code)
{
    case A:
    case B:
    case C:
        report_field[3] = interest_amount;
        break;
    default:
        break;
}

Now, this is all contrived for several reasons, and you probably wouldn't paste code into your email (and it's been a while since I've written anything c-like), but I thought an example would help drive this point home. These snippets probably look very similar to a developer, but non-standard symbols and keyword meanings make "normal" people's heads explode.