From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-0.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,5faad1722103f6a7 X-Google-Attributes: gid103376,public Path: g2news1.google.com!news1.google.com!newshub.sdsu.edu!elnk-nf2-pas!newsfeed.earthlink.net!stamper.news.pas.earthlink.net!newsread2.news.pas.earthlink.net.POSTED!01cc3b7c!not-for-mail Reply-To: "Richard Riehle" From: "Richard Riehle" Newsgroups: comp.lang.ada References: <90Stc.15309$be.3117@newsread2.news.pas.earthlink.net> <40b86431$0$186$edfadb0f@dread11.news.tele.dk> <40B888E0.5040707@noplace.com> <40B8C86A.3050302@noplace.com> <40BE6BFD.8030305@noplace.com> <40BF141F.8020001@noplace.com> <40C38E7C.64564F@notes.udayton.edu> Subject: Re: 7E7 Flight Controls Electronics (COBOL Popularity) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Message-ID: <99nyc.10465$uX2.6211@newsread2.news.pas.earthlink.net> Date: Fri, 11 Jun 2004 18:49:41 GMT NNTP-Posting-Host: 66.81.219.224 X-Complaints-To: abuse@earthlink.net X-Trace: newsread2.news.pas.earthlink.net 1086979781 66.81.219.224 (Fri, 11 Jun 2004 11:49:41 PDT) NNTP-Posting-Date: Fri, 11 Jun 2004 11:49:41 PDT Organization: EarthLink Inc. -- http://www.EarthLink.net Xref: g2news1.google.com comp.lang.ada:1401 Date: 2004-06-11T18:49:41+00:00 List-Id: "Warren W. Gay VE3WWG" wrote in message news:Nplyc.52642$8k4.1169496@news20.bellglobal.com... > Richard Riehle wrote: > > > "I R T" 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