Re: 7E7 Flight Controls Electronics (COBOL Popularity)

["Richard Riehle" <adaworks@earthlink.net>]

"Warren W. Gay VE3WWG" <ve3wwg@cogeco.ca> wrote in message
news:Nplyc.52642$8k4.1169496@news20.bellglobal.com...
> Richard Riehle wrote:
>
> > "I R T" <rambam@bigpond.net.au> wrote in message
> > news:oenv7hhc.fsf@pop-server.bigpond.net.au...
> >
> >>Association with the military was the kiss of death as far
> >>as many developers were concerned.
> >>
> >>COBOL also had the benefit of backing by IBM.
> >
> ...
> > IBM wanted COBOL gone.  The only reason it kept it alive
> > was to satisfy RFP requirements from the DoD.  In time, COBOL
> > became the dominant language for business data processing, even
> > though IBM continued to insist on the superiority of PL/I.
> ...
> > Richard Riehle
>
> One of the areas that COBOL was very successful in (and still),
> is providing the necessary facilities to perform business
> functions. While it may seem trivial, the need to format
> numeric values (particularly monetary values) in a picture
> format is so prevalent, that it becomes a major pain to
> use other languages that don't conveniently provide this.

You wrote this in reply to my note about the role of the
DoD in the survival of COBOL.  The events of the time,
mentioned in my earlier post, were such that IBM had
a virtual monopoly in the computer business, much the
way Microsoft has today.   At that time, the Federal
Government was less inclined to accomodate that
monopoly than is the current government.  Therefore, a
lot of effort was made to ensure that all qualified bidders
were able to compete for contracts.

For the USAF contract (as with many other contracts at
this period of computing history) was originally specified
for PL/I.   IBM managed to get that requirement into a
lot of Requests for Proposal.   Protests from several vendors,
as well as from the community at large, resulted in that
requirement being replaced by COBOL.

It was IBM's intention to replace both Fortran and COBOL
with PL/I.   If IBM had been successful, the history of computer
programming languages would have been much different.  PL/I
was, in many respects, an improvement over COBOL and Fortran.
However, IBM failed to manage its acceptance by the computing
community -- much the way the DoD mismanaged the Ada
initiative almost from the start.

> Of course, I am sure there were many other factors that
> played into the popular use of COBOL besides this. I've
> forgotten any COBOL I once knew, but I seem to remember
> that having builtin support of Indexed files etc. to be
> a great asset to business.
>
The survival of COBOL is a complex story.  Much of that story
is political.  Some of it is technological.   Most of it is due to Newton's
First Law of Motion.

> PL/I had a number of whizbang features (for the time),
> but they didn't exactly pander to the real business needs
> (I don't recall if the full PL/I language supported the
> picture formatting or not). Certainly one of PL/I's
> downfalls, was the shear size of the language, for the
> time.
>
PL/I did not look like COBOL to COBOL programmers and it
did not look like Fortran to Fortran programmers.  We all have
had to experience of a programmer being resistant to some new
language (e.g., Ada), not because it is a bad language design, but
because it does not look like the language they are used to.  Anyone
who has tried to persuade a C programmer to consider Prolog, an
Ada programmer to consider C++, a C++ programmer to consider
Ada, or a Forth programmer to consider C, understands how this
works.    PL/I, though it had some small flaws in its original design,
had all the elements needed to evolve into a better language than
those in widespread use at the time.

This is an Ada forum, so we might take notice of the lessons of PL/I
when discussing Ada.   In the case of PL/I, and large organization,
IBM, tried to bully its customers into using a new and strange language
to replace what they were already using.   In the case of Ada, a large
government agency tried to dictate the use of an equally strange and
unfamiliar language.   The people who actually develop software resisted,
sometimes with malicious compliance, other times with outright defiance,
and both the PL/I mandate and the Ada mandate failed.   The failure
had little to do with the relative virtues of the respective languages.
It had much to do with the fact that human beings dislike being ordered
to change their ways.

Now that Ada must be a choice rather than fiat, we have the opportunity
to persuade people to use it rather than mandate its use.  The only way
we can do that is through example.  Those who believe it is a superior
approach to software development need to prove it by building better
software with it.   Then they can announce their success with Ada. There
is no other avenue for Ada's long-term success.  No amount of preaching,
complaining about someone else's stupidity,  or managerial incompetence
will garner a single iota of success.  Only success will lead to success.
Prove
Ada by its fruits, not through declamation and oratory.

Richard Riehle