On COBOL

you have to better read this ... no prophecy ..just plain truth ...

COBOL in the eyes of Mr.Steve Gomori....


I'm not slamming any of these languages like C, Java etc. I like C++ and I like Java. They're great for what they were intended for, just like COBOL, SQL and Visual Basic. Take any language out of its element and it quickly becomes inadequate.

You need to develop a web app, go with Java. You need a Windows-based GUI app or GUI front end for a client-server app, then use Visual Basic. Middle-tier for that client-server application? C++ or C#. Need to process large files for a business app? COBOL. Formatted reports for that business app? COBOL. How about an on-line interface to that system that could have several, even hundreds of concurrent users (in-house)? COBOL.

OK. Let's pretend that Java was a suitable alternative. So we're saying it either can handle all the things a business needs in its processing or that the company is willing to live without a lot of its current functionality. A big stretch wither way. Let's look at the business case. How long would it take a small company, with something like 15,000 programs, to convert to Java? Let's say a person can get two programs done in a week (20 hours each). This includes coding, testing and implementation. Realistic? Probably not. But it's a nice round number. If you figure a person works about 1,920 hours a year (the standard 2,080 hours in a year, minus 2 weeks vacation and minus another 10 days for holidays and sick time) then he/she can convert 96 programs a year.

This assumes that any non-productive time (in meetings, on the phone, etc.) is made up for. At that pace this conversion would take over 150 man-years. If that coder can get one program done a day it would still take .5 man-years. So at that pace an army of 63 consultants could be brought in for a year and get it all done. How much would it cost? 63 consultants for a year? Ones that ow COBOL and Java well enough to pull this off? At $75 an hour (a little low, I think, but a round number) it would be over $9 million. What's the end result? If a program is rewritten correctly then will do exactly what it did before. The same results, the same output. The end user will see no difference. Except now you have a program that's harder to read, harder to document and harder to maintain.Hardly worth the effort and definitely not worth the cost.

Can you imagine trying to get approval on a budget item of nine million dollars to reproduce what you're already getting? Maybe the report will come off the printer faster but it still won't get delivered until the guy in the mail room makes his rounds. Now consider a large company with COBOL programs numbering several more thousands.

There's more new COBOL development going on now than there ever was. Y2K tied up resources so there was a lot of work placed on the back burner that now needs to be done. Those new Y2K-compliant systems will need maintained. Y2K fixes will need corrected.

It's been estimated that over 150 billion lines of COBOL code is currently in use (not just exists, but is in use) with another 5 billion added annually. It's also been estimated that over 98% of the world's economy is processed by COBOL code. More new development in COBOL than ever. And the language is still being revised. Exisitng COBOL code works as expected. No one has developed a language to challenge it. The future of COBOL is safe.






- Now after all that , coming to your point ...


And I become more and more confident than the whole project we are working at could be implemented by a group of 10 good Java programmers withing a few months - while the project team consists of hundreds of people and we've got three or four years to do it.

I DISAGREE ... Why ?... you must have understood by now , if you have read the article ...

Just because the job you got is boring does not mean that , COBOL is hell .


- DENIMINOO

Re: you have to better read this ... no prophecy ..just plain truth ...

Re: Just Plain Truth, Anonymous
Among all the those active programs still residing in COBOL libraries many are accomplishing tasks previously thought only machine oriented languages as Java, C++ etc could handle. Except, for possibly scientific oriented tasks COBOL has shown it can effectively do the task of most applications. This is substantiated by the millions of COBOL programs still being kept active. COBOL's only drawback is not COBOL itself. It is software management and programmers rejection of the "Clarity Concept" envisioned and intended by the creators of COBOL. If COBOL were to be written as it's creators intended those machine oriented languages would fall by the wayside. COBOL would become the dominate computer language it once was. This time it would be based on it's actual productivity resulting from it's conduciveness to clearly readable/understandable code. The code understandability that was previously being destroyed by the flooding of abbreviations. Abbreviations create "broken COBOL" which like broken English can range from poorly understandable to nearly incomprehensible. Clarity coding was the basic reason for COBOL in the first place. All our Software Industry need do is assure their COBOL programmers write COBOL as envisioned and intended by the committee that created it.

That's one small step for COBOL and one giant leap for software productivity.

Not to take that step means more and more programs will be written in poorly understandable coding whether, by using machine oriented languages which are not conducive to the Clarity Concept or broken COBOL which is just as poorly understandable.

Refer to my previous response to ON COBOL
Jerry S
nycnmi@aol.com

On COBOL

Re; On COBOL, Making The Matrix
It's too bad you don't understand what programming is all about. It's not an ego trip as it seems to be for you. It's to write programs that first of all accomplish a task. Then to do it as easily and quickly as possible. Then make sure, if at a later date it should need maintenance, the code is clearly understandable for the maintenance programmer. COBOL was created for those reasons. First of all the fact that there are millions of COBOL programs still active shows they continue to accomplish the task assigned to them. Their maintenance is not to correct them but to enhance them. COBOL's problem, from it's inception, was it never was written by any programmers as intended or envisioned by it's prestigious creators in 1959. The following is quotes emanating from the Department of Defense Committee that created COBOL back then:

1) "Majority of the group favored maximum use of simple English language."

2) "The need is for a programming language that is easier to use even if less powerful."

3) "It certainly was intended (and expected) that the language could be used by novice programmers and read by management. We felt the readability could would be achieved because of the intended use of English ... most of our concentration was on making it "easier to read.".

4) "The driving force behind consideration of all the "statements" was the concept of readability.".

5) "and there was a definite emphasis on ease of reading not on ease of writing."

COBOL programmers from it's inception never followed any of these committee quotes. They did the exact opposite. They flooded their coding with abbreviations under the misconception it would lessen the time needed for program implementation. Instead it lowered COBOL's understandability level to all the other computer languages that were machine oriented. Had they written COBOL as intended and envisioned by the committee you would not have any job today, documenting COBOL programs. They would have been self documented when originally written. Get off your ego trip if you want to be a good programmer. Simplicity is the key stone to both art and software productivity.

Jerry S

Re: On COBOL

Nice to know that someone reads my old entries, thanks :)

First of all, I strongly believe that object-oriented programming is, in vast majority of situations, the best approach. And that a small team of advanced programmers who use an OO language is a better solution than a complex management structure of many novice-to-intermediate programmers supervised by a few advanced ones, or even worse: by managers who are not programmers themselves.

What's more, a programming language is something that works on logics, so readability in case of programming languages bases mainly on the concept of precise, straightforward commands and clear declarations of data structures. A programming language which is designed to bear resemblance to a human language so a novice can read it easily is for me a contradiction. A human language was not designed for being precise. Hell, it wasn't designed at all. It is an evolved feature which for the main part of its existence was used to express simple needs of hungry and tired human beings. It is not very good in making precise logical statements. Yes, it is easier to understand code which is written in a way more resembling English - when you speak English and when you have little mathematical background. In other cases (as for example, in my case) usually it is easier to learn the syntax of a given OO languages. Which, by the way, is not a very hard task.

Another thing: Abbreviations is something which should be expected when designing a programming language. When you program, first you usually want to create a working version of the given piece of code, test it, and only when you see it works, you can spend some time on making it more readable. But then usually there is not time for it, so you leave it as it is, with abbreviations. In cases of OO languages abbreviations should be avoided as well, but because of the syntax they are not as problematic as in COBOL. Honestly, whining on programmers that they use abbs (pun intended ;) ) is like whining that they are human.

But, on the other hand, it is true that I approach programming from another side than people who designed COBOL. I love AI, simulations of ecosystems and game programming in general. Nowadays in my work I write code in Java, programming new features for a bugs and reports tracking system - JIRA. Not so interesting as AI, nevertheless it gives me space for some creativity. So if COBOL is good enough for people writing banking applications, then OK. I will still claim that Java or Python would be better, but I'm into banking applications.

Re: On COBOL

MTM
Unless you can give me a straight forward reason for our Software Industry being at the bottom of the Industry Productivity Chart year after year after year I feel for me to respond to you any longer a waste of energy. You seem to be more interested in supporting your ego trip not to solve the productivity problem.
Good luck
Jerry

Re: On COBOL

I don't consider it to be an ego trip - my first entry was emotional, but it was supposed to be so. Now I write simply how I look at it.

I can only describe how it works in my current company, which seems to be pretty effective. We work in small teams, three - four people in each, and we strive to hire only programmers with MSc (or just before MSc) from best universities in the country. And with some decent programming experience. We extensively use JIRA, a system for bugs, requirements and reviews tracking (each piece of new code has to be reviewed by another person - not the author - so that each piece of code is known by more than one person). There are CVS branches for every new feature and tests are written in line with the code and there is a system for tracking their results and connecting them with bugs and reviews. In general, we give programmers much freedom and flexibility, and trust, but in the same time their responsibilities are very clear.
And our boss is a real workaholic. That helps a lot.

But as I write it... I have a feeling that it won't help you at all, right?

Re: On COBOL

You seem to have missed the point entirely. COBOL was created by a committee that had to decide what it's coding attributes should be. That committee was convinced machine oriented languages were not conducive to easily readable/understandable coding, the key to productve coding. They decide to create a language that, unlike machine oriented languages of that time, could be easily tested, debugged or maintained. This new language had to be the easyist to read and understand of any previous language. They weren't looking for an ego trip. They wanted the language to be as easily readable/understandable as possible, thereby making the language easily tested, debugged and maintained. "Simplicity is the keystone of art". The problem is in COBOL's 50 years it has never once been written as the committee either envisioned or intented due to misconceptions. What has been written in these last 50 years is Btoken COBOL which like Broken English ranges from poorly understandable to nearly incomprehensible. The main culprit has been "abbreviations". Notice the committee never abbreviated a single reserved word. The didn't want to set a bad example for data and paragraph names. Abbreviations flood all COBOL coding since it's inception. Heaven help us. Jerry nycnmi@aol.com