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-Attributes: gid103376,gid1094ba,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news2.google.com!news4.google.com!border1.nntp.dca.giganews.com!nntp.giganews.com!newsfeed-east.nntpserver.com!nntpserver.com!statler.nntpserver.com!news2.euro.net!62.253.162.218.MISMATCH!news-in.ntli.net!newsrout1-win.ntli.net!ntli.net!news.highwinds-media.com!newspeer1-win.ntli.net!newsfe2-win.ntli.net.POSTED!53ab2750!not-for-mail From: "Dr. Adrian Wrigley" Subject: Re: Ada vs Fortran for scientific applications User-Agent: Pan/0.14.2 (This is not a psychotic episode. It's a cleansing moment of clarity.) Message-Id: Newsgroups: comp.lang.ada,comp.lang.fortran References: <0ugu4e.4i7.ln@hunter.axlog.fr> <_iHcg.5599$oa3.1506@trnddc08> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Date: Wed, 24 May 2006 18:08:20 GMT NNTP-Posting-Host: 82.10.238.153 X-Trace: newsfe2-win.ntli.net 1148494100 82.10.238.153 (Wed, 24 May 2006 19:08:20 BST) NNTP-Posting-Date: Wed, 24 May 2006 19:08:20 BST Organization: NTL Xref: g2news2.google.com comp.lang.ada:4422 comp.lang.fortran:10210 Date: 2006-05-24T18:08:20+00:00 List-Id: On Wed, 24 May 2006 16:49:10 +0000, J.F. Cornwall wrote: > Dr. Adrian Wrigley wrote: >> On Wed, 24 May 2006 12:56:29 +0000, J.F. Cornwall wrote: >> >>> Dr. Adrian Wrigley wrote: >>>> On Tue, 23 May 2006 17:07:06 +0000, Dan Nagle wrote: ... >>> In my US Air Force days, I worked at a large global >>> weather-forecasting facility. We had multiple data input systems (a >>> variety of comm links talking to several Univac mainframes), multiple >>> number-crunching systems (a couple more Univacs and a Cray), and an >>> cluster of 40 or so Vax 11/780s for interactive tweaking of the >>> forecasts. The majority of the software for the comm was in >>> assembler, just about all of the remainder was Fortran (IV and 77, >>> this was back in the early 80's...). >>> >>> We also used Fortran mixed with assembly code for a new comm front-end >>> machine that was implemented in '88. Fortran was used for comm, >>> utility programs, forecasting models, database >>> input/output/maintenance, and just about everything else in that >>> system. Worked fine. >> >> Interesting. >> >> I *think* you are supporting my view that in practice, Fortran requires >> additional support or coding outside of the language to tie together >> the different parts of a complex system. You speak of utility programs, >> forecasting programs, database I/O programs. Invoking these in the >> right order, at the right time, on the right files at the right >> terminals is always done outside of the pure Fortran application. At >> the very least it requires an OS command interpreter. It probably >> involves scripts to delete old files or do other housekeeping. >> >> In Ada, the separate program components can form a *single* running >> application program entity, with a single invocation - even if the >> program is running across several loosely connected machines and >> consists of many different executable files. The program execution is >> a network of cooperating processes and shared data stores. Parts of >> the program can even be recompiled as it runs - without affecting the >> shared data stores or other executing tasks. In fact Ada supports >> persistent variables with hold their values even if the program is >> stopped completely and restarted later. No mainstream language comes >> even close to this program execution model. >> -- >> Adrian > > Actually, in that particular environment, everything was tied together > in a complicated web of cross-ties. The Fortran code couldn't do > everything, the assembly code couldn't do everything, the scripting and > batch control languages couldn't do everything. etc... That would have > been the case had we been using Ada, as well. You're quite right. But one thing apparent in this discussion is that the Ada programmer's view of Fortran is the FORTRAN 77 many learned in college, but the Fortran programmer's view of Ada is of Ada 83, when that was hot technology. Neither view has much relevance in determining the technical suitability of the contemporary languages for new projects. I'd be overselling the features of modern Ada to say that the scripting and batch control 'glue' can *all* be done within the language - but a huge part of it can be. And this brings a major benefit to system portability, complexity and integrity. -- Adrian