[comp.software-eng] Computer langauges and software lifecycle - references request

slores@umiami.miami.edu (Stanislaw L. Olejniczak) (04/24/89)

Several days ago I heard an very vigorous argument about the usability, if
you will, of various computer programming languages.  A person (a
professional programmer) was claiming that COBOL is probably the very best
langauge for software writing _in general_ (i.e., for applications not
specifically requiring facilities of special purpose langauges) because it
can do everything C or Pascal or FORTRAN can, and in addition it is so
widely used and so well standarized, applications are generally
transportable from machine to machine with no modifications.  The sense
of the argument was that COBOL was the most "useable" language, which by
the virtue of its modularity, standarization, and wordiness made it the
easiest of the major langauges to create reliable, portable and modifiable
software. 

These arguments did not sit well with me, and they still do not.  I
believe COBOL is anything but that.  However, I neither know COBOL well
enough to make a reasonable argument against it, nor do I know well
enough about the research about the benefits and drawbacks of various
languages as far as creation of reliable, portable, modifiable software
goes to support my belief with hard facts.

Therefore I would appreciate if anyone would suggest for me references to
either books on the subject of langauges and their influence on software
reliability, portability, maintainability, and other aspects of the
software life cycle (preferred) or research articles (if they would be
reviews, "general" or basic enough to serve as jump off points for further
reading) covering these questions. 

Many thanks!
----
Stan Olejniczak           Internet:    slores@umiami.miami.edu
University of Miami       UUCP:        {uunet!gould}!umbio!solejni
Miami, Florida, USA       BITNET:      SLORES@UMIAMI
Voice: (305)-547-6571     FAX:305-547-6412
My opinions cannot possibly represent the views of anyone else!

schow@bnr-public.uucp (Stanley Chow) (04/25/89)

In article <570@umiami.miami.edu> slores@umiami.miami.edu (Stanislaw L. Olejniczak) writes:
>Several days ago I heard an very vigorous argument about the usability, if
>you will, of various computer programming languages.  A person (a
>professional programmer) was claiming that COBOL is probably the very best
>langauge for software writing _in general_ (i.e., for applications not
>specifically requiring facilities of special purpose langauges) because it
>can do everything C or Pascal or FORTRAN can, and in addition it is so
>widely used and so well standarized, applications are generally
>transportable from machine to machine with no modifications.  The sense
>of the argument was that COBOL was the most "useable" language, which by
>the virtue of its modularity, standarization, and wordiness made it the
>easiest of the major langauges to create reliable, portable and modifiable
>software. 
>

Having had to make a living writing/maintaining COBOL, FORTRAN & PL/I programs
for a couple of years (over a decade ago) and having been involved in some
big software project in very different areas, I agree with your friend with
some provisos.

In the limited domain of file processing (e.g., the classical edit/sort/update
cycle for accounting), COBOL is basically unbeatable. This is assuming you
take into account of the *life-cycle* costs. The reasons:
  - Good input format specification
  - Good output format specification
  - Good file/record handling
  - Good interface to many commercial packages
  - Portable
  - Easy to read for simple programs
  - Versatile (but precise and easy) numeric types

Amazingly, it is possible to write good modular code in COBOL. It takes some
discipline but is certainly an order of magniture easier than doing so in C.
It is also possible to write very bad code in COBOL but it takes real effort
(as opposed to merely bad code, which is always easy). It is also very fast
even with minor tunning (and you should see some accounting files to appreciate
what BIG is).

If I may preempt some objections to COBOL:
 - Verbose. 
    True but irrelevent. Proficent programs can knock out COBOL just as fast
    as C hackers can crank out filters in C. Most COBOL shops will have set up
    libraries of data structures any way, so programers don't have to do much
    data structures (in fact, usually, most programmers are not allowed to
    fiddle file formats).
 - Not-block structured, no variable scoping.
    Again, true but irrelevent. Most shops have set up variable naming rules
    so that scoping is not needed. With the PERFORM verb (calls a subroutine)
    you can write good modular code.
 - Poor choice of control structures.
    True, but in the right domain, the COBOL paradigm is very effective.

As soon as you get into more complicated programs, the verbose nature becomes
a great handicap. Doing interactive programs or number crunching in COBOL is
not what I would consider fun.

The major problem is that very few problems/systems these days are suited to
COBOL. All the new sexy things (real-time, windows, graphics, ...) don't work
well in COBOL.


Stanley Chow    ..!utgpu!bnr-vpa!bnr-fos!schow%bnr-public


Since I am talking about a previouse life, I would be very surprised if
my current employer want to be included.

billwolf%hazel.cs.clemson.edu@hubcap.clemson.edu (William Thomas Wolfe,2847,) (04/26/89)

From article <432@bnr-fos.UUCP>, by schow@bnr-public.uucp (Stanley Chow):
> The major problem is that very few problems/systems these days are suited to
> COBOL. All the new sexy things (real-time, windows, graphics, ...) don't work
> well in COBOL.

   Don't forget multitasking, reuseable ADTs, packages, true exception 
   handling, operator overloading, or separate compilation...

   Personally, I'd like to see a good COBOL vs. Ada study, 
   if anybody knows of one (or is interested in doing one)...


   Bill Wolfe, wtwolfe@hubcap.clemson.edu

crm@romeo.cs.duke.edu (Charlie Martin) (04/26/89)

As far as a study comparing COBOL and Ada -- I'd be pleased to hear
someone propose an experiment design that could compare Ada and COBOL
(or any two languages) in a reasonbly rigorous fashion.
Charlie Martin (crm@cs.duke.edu,mcnc!duke!crm) 

hollombe@ttidca.TTI.COM (The Polymath) (04/29/89)

In article <570@umiami.miami.edu> slores@umiami.miami.edu (Stanislaw L. Olejniczak) writes:
}... A person (a
}professional programmer) was claiming that COBOL is probably the very best
}langauge for software writing _in general_ (i.e., for applications not
}specifically requiring facilities of special purpose langauges) because it
}can do everything C or Pascal or FORTRAN can, ...

This is true only in the broadest possible sense:  All four languages can
be made to get the job done.  When you get down to _how_ the job is done,
not to mention how efficiently, there are clear differences.

One obvious example is dynamic allocation/deallocation of memory.  Unless
the language has changed considerably since last I had to deal with it,
COBOL can't do this.  In practice, the COBOL programmer has to size data
structures to handle worst case conditions, if they know what those
conditions are (or cross their fingers and hope, if they don't).  Pascal
and C programmers can dynamically allocate structures as needed, and
release them when no longer needed, making for more efficient memory use
and more compact object code.

}... and in addition it is so
}widely used and so well standarized, applications are generally
}transportable from machine to machine with no modifications. ...

Not necessarily so, in my experience.  For example, one of my first COBOL
projects was done on an HP-3000 using their COBOL-3000 language.  At least
one of its commands worked in a manner directly opposite to what was
described in the ANSI standard. (That was 10 years ago, and I don't
remember which one, only the outrage when I found the bug that bit me).

I once even stumbled across a bug in an IBM COBOL compiler (is nothing
sacred? (-:{ ).  SDC was quite grumpy about applying the necessary patch.

}... The sense
}of the argument was that COBOL was the most "useable" language, which by
}the virtue of its modularity, standarization, and wordiness made it the
}easiest of the major langauges to create reliable, portable and modifiable
}software. 

Most COBOL coding standards I've seen mandate use of the abbreviated forms
of COBOL key words.  So much for wordiness.  I think COBOL is about as
modular as BASIC and I've already commented on it's standardization.

}These arguments did not sit well with me, and they still do not.  I
}believe COBOL is anything but that.  However, I neither know COBOL well
}enough to make a reasonable argument against it, nor do I know well
}enough about the research about the benefits and drawbacks of various
}languages as far as creation of reliable, portable, modifiable software
}goes to support my belief with hard facts.

IMHO, there are applications for which COBOL is an acceptable, if not
ideal, language.  These are mostly the things for which it was designed
and intended.  Reading massive amounts of records off tapes, pushing the
data on them around a bit and writing them out again is the general idea.
On the other hand, there are applications for which COBOL is a complete
disaster to work with.  For example, I once had to solve a
point-polygon-inclusion problem in COBOL.  It still gives me the shivers
when I think of it. (-:
-- 
The Polymath (aka: Jerry Hollombe, hollombe@ttidca.tti.com)  Illegitimati Nil
Citicorp(+)TTI                                                 Carborundum
3100 Ocean Park Blvd.   (213) 452-9191, x2483
Santa Monica, CA  90405 {csun|philabs|psivax}!ttidca!hollombe

psrc@pegasus.ATT.COM (Paul S. R. Chisholm) (04/30/89)

In article <432@bnr-fos.UUCP>, schow@bnr-public.uucp (Stanley Chow) writes:
> Amazingly, it is possible to write good modular code in COBOL. It takes some
> discipline but is certainly an order of magniture easier than doing so in C.

Excuse me?  C has global variables, variables that can be local to a
module (source file), and both temporary and long-lived variables local
to functions (subroutines).  Cobol has global variables, and very
limited subroutines (PERFORM).

> It [Cobol] is also very fast even with minor tuning

I agree.  Cobol stores numbers in a way that makes simple arithmetic
reasonably efficient (and as precise as you'd usually want), and makes
I/O very efficient.  Most of what typical Cobol programs do is the
equivalent of lots of string copies, which C needs a function call
for.

> If I may preempt some objections to COBOL:
>  - Verbose. 
>     True but irrelevent. Proficent programs can knock out COBOL just as fast
>     as C hackers can crank out filters in C.

Maybe not.  Some studies show that programmer productivity seemed to be
proportional to the number of lines of code, regardless of the
language.  If that's true, a concise language helps.  (Besides, C
hackers crank out filers in sh, built out of other filters, written in
sh or C.)

>  - Not-block structured, no variable scoping.
>     Again, true but irrelevent. Most shops have set up variable naming rules
>     so that scoping is not needed.

Rules the compiler can't check for you.  The lack of true local
variables precludes recursion, unless you build your own stack.

>  - Poor choice of control structures.
>     True, but in the right domain, the COBOL paradigm is very effective.

I'd say the same thing for good 4GL's.  The intersection of their
domains is pretty large, and the 4GL's are more concise.

> Stanley Chow    ..!utgpu!bnr-vpa!bnr-fos!schow%bnr-public

Paul S. R. Chisholm, AT&T Bell Laboratories
att!pegasus!psrc, psrc@pegasus.att.com, AT&T Mail !psrchisholm
I'm not speaking for the company, I'm just speaking my mind.

schow@bnr-public.uucp (Stanley Chow) (05/02/89)

I don't want to start a war about C, please forgive any remarks I made/make.


In article <2846@pegasus.ATT.COM> psrc@pegasus.ATT.COM (Paul S. R. Chisholm) writes:
>In article <432@bnr-fos.UUCP>, schow@bnr-public.uucp (Stanley Chow) writes:
>> Amazingly, it is possible to write good modular code in COBOL. It takes some
>> discipline but is certainly an order of magniture easier than doing so in C.
>
>Excuse me?  C has global variables, variables that can be local to a
>module (source file), and both temporary and long-lived variables local
>to functions (subroutines).  Cobol has global variables, and very
>limited subroutines (PERFORM).
>

I meant to say:

   it is easier to write modular code that is easily maintainable by people
   with minimal familiarity with the language.

In the commercial shops (for which COBOL is intended), getting good people is
very difficult. 


>> If I may preempt some objections to COBOL:
>      [...]
>>  - Not-block structured, no variable scoping.
>>     Again, true but irrelevent. Most shops have set up variable naming rules
>>     so that scoping is not needed.
>
>Rules the compiler can't check for you.  The lack of true local
>variables precludes recursion, unless you build your own stack.
>

Recursion, I don't consider to be a problem for COBOL. The problems usualy
don't need recursion. The odd time that recursion is needed, you can fake it.

Most COBOL programs that I have seen do not require many local variables. Anyway,
after your tenth clone of the print program, you are not likly to have much
trouble with the eleventh clone.

>>  - Poor choice of control structures.
>>     True, but in the right domain, the COBOL paradigm is very effective.
>
>I'd say the same thing for good 4GL's.  The intersection of their
>domains is pretty large, and the 4GL's are more concise.
>

I have not used any 4GL, so I can't say. But I imagine you are right on this.



Stanley Chow			..!utgpu!bnr-vpa!bnr-fos!schow%bnr-public
				bitnet: schow@BNR.CA.BITNET

Disclaimer: I speak for myself only. [And even then, it's only sometimes]

diamond@diamond.csl.sony.junet (Norman Diamond) (05/08/89)

In article <459@bnr-fos.UUCP> schow@bnr-public.UUCP (Stanley Chow) writes:

>In the commercial shops (for which COBOL is intended), getting good people is
>very difficult. 

Only because they don't even bother to interview good applicants.
They just assume that good people don't really want to work for them,
and discard their resumes.

Norman Diamond, Sony Computer Science Lab (diamond%csl.sony.co.jp@relay.cs.net)
  The above opinions are my own.   |  Why are programmers criticized for
  If they're also your opinions,   |  re-inventing the wheel, when car
  you're infringing my copyright.  |  manufacturers are praised for it?

rsd@sei.cmu.edu (Richard S D'Ippolito) (05/09/89)

In article <10230@socslgw.csl.sony.JUNET> Norman Diamond's signature contains:


>  Why are programmers criticized for
>  re-inventing the wheel, when car
>  manufacturers are praised for it?

Car manufacturers do not re-invent wheels -- they re-implement them.  Not
only that, they don't even construct the implementations themselves; they
specify the new implementations and have others make the wheels for them!

Car manufacturing is mostly engineering, not science.

Rich
-- 
---------------------------------------------------------------------------
Ideas have consequences.                                    RSD@sei.cmu.edu
Richard Weaver
---------------------------------------------------------------------------

diamond@diamond.csl.sony.junet (Norman Diamond) (05/11/89)

In article <3326@ae.sei.cmu.edu> rsd@sei.cmu.edu (Richard S D'Ippolito) writes
that my signature contains [contained]:

>>  Why are programmers criticized for
>>  re-inventing the wheel, when car
>>  manufacturers are praised for it?

>Car manufacturers do not re-invent wheels -- they re-implement them.

OK.  Programmers don't re-invent wheels at all.  The criticism is only
a figure of speech, and I wondered why that criticism is not applied
in other disciplines of engineering.

>Car manufacturing is mostly engineering, not science.

Of course.  Who said it was a science?

--
Norman Diamond, Sony Computer Science Lab (diamond%csl.sony.co.jp@relay.cs.net)
  The above opinions are my own.   |  Why are programmers criticized for
  If they're also your opinions,   |  re-implementing the wheel, when car
  you're infringing my copyright.  |  manufacturers are praised for it?