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=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,c4cb2c432feebd9d X-Google-Thread: 1094ba,c4cb2c432feebd9d X-Google-Thread: 101deb,15c6ed4b761968e6 X-Google-Attributes: gid103376,gid1094ba,gid101deb,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news2.google.com!news3.google.com!newshub.sdsu.edu!newscon04.news.prodigy.net!prodigy.net!newsdst01.news.prodigy.net!prodigy.com!postmaster.news.prodigy.com!newssvr12.news.prodigy.com.POSTED!4988f22a!not-for-mail From: Newsgroups: comp.lang.ada,comp.lang.fortran,comp.lang.pl1 References: <0ugu4e.4i7.ln@hunter.axlog.fr> <%P_cg.155733$eR6.26337@bgtnsc04-news.ops.worldnet.att.net> <6H9dg.10258$S7.9150@news-server.bigpond.net.au> <1hfv5wb.1x4ab1tbdzk7eN%nospam@see.signature> <2006052509454116807-gsande@worldnetattnet> Subject: Re: Ada vs Fortran for scientific applications X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-RFC2646: Format=Flowed; Original Message-ID: NNTP-Posting-Host: 70.134.98.164 X-Complaints-To: abuse@prodigy.net X-Trace: newssvr12.news.prodigy.com 1152638489 ST000 70.134.98.164 (Tue, 11 Jul 2006 13:21:29 EDT) NNTP-Posting-Date: Tue, 11 Jul 2006 13:21:29 EDT Organization: SBC http://yahoo.sbc.com X-UserInfo1: FKPGW^WETZSMB_DX]BCBNWX@RJ_XPDLMN@GZ_GYO^RR@ETUCCNSKQFCY@TXDX_WHSVB]ZEJLSNY\^J[CUVSA_QLFC^RQHUPH[P[NRWCCMLSNPOD_ESALHUK@TDFUZHBLJ\XGKL^NXA\EVHSP[D_C^B_^JCX^W]CHBAX]POG@SSAZQ\LE[DCNMUPG_VSC@VJM Date: Tue, 11 Jul 2006 17:21:29 GMT Xref: g2news2.google.com comp.lang.ada:5623 comp.lang.fortran:11950 comp.lang.pl1:1990 Date: 2006-07-11T17:21:29+00:00 List-Id: "robin" wrote in message news:TfPsg.3094$tE5.2436@news-server.bigpond.net.au... > adaworks@sbcglobal.net wrote in message ... >> >>"Gordon Sande" wrote in message >>news:2006052509454116807-gsande@worldnetattnet... >>> >>> How many Ada systems can match the undefined variable checking of the >>> old WatFor or the current Salford CheckMate or the Lahey/Fujitsu >>> global checking? It seems to be a thing associated with places that >>> run student cafteria computing on mainframes. Not much used anymore. >>> There was a similar student checkout PL/I from Cornell if I recall >>> correctly. >>> >>The default for Ada is to do thorough range checking on all numeric >>types. > > Range checking is not a substitute for detection > of uninitialized variables. > See my example on how Ada supports this in a different post under this thread topic. An Ada compiler can certainly check for unitialized variables. It can also check for misplaced artifacts of all kinds, thereby assisting the developer with program organization improvement. As stated earlier, the fundamental design goal of Ada is provide the maximum amount of error detection as early in the development process as possible. Errors, of course, are at different levels. Sometimes the compiler provides advisory error messages, and other times the error prevents compilation. I have used a lot of programming languages during my 40+ years in software and I have not found a language that is as dependable in this respect as Ada. That being said, I sometimes prefer to use other languages when Ada is too strict. Currently, I enjoy Python. In the past I have liked Smalltalk. Long, long ago, when PL/I was new (during the 1960's and one project during the 1970's), I did some coding in it, but I am certainly not current with modern PL/I. It did seem to be an improvement over Fortran and COBOL at that time. Every language has its good and bad points, its weak points and its strong points. Ultimately, it is about choosing the right tool for the right job. I have tried to find information on PL/I that would encourage me to recommend it. I queried this forum for that kind of information and received much verbal abuse (except from Tom, who was helpful) for it. I would like to see PL/I continue to evolve and receive good support. I would like to see it have a good model for objec-oriented programming so it would be more attractive to a larger audience. Fortran has continued to evolve nicely. The current standard has much that is commendable. Even COBOL has evolved with an OOP capability. In fact, COBOL, for all its faults, continues to evolve rather well. A language does not stay current with emerging concepts in program design is not going to retain a following. PL/I has a good fundamental model. There is no reason why it should lose its place as a popular programming language. So instead of being defensive about PL/I, or haranguing against those who see potential for improvements, it is probably worthwhile to work toward making those improvements. Richard Riehle