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!news2.google.com!news.germany.com!feed.xsnews.nl!feeder.xsnews.nl!news.astraweb.com!newsrouter-eu.astraweb.com!border1.nntp.ams.giganews.com!nntp.giganews.com!news-in.ntli.net!newsrout1-win.ntli.net!ntli.net!news.highwinds-media.com!newspeer1-win.ntli.net!newsfe4-gui.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 13:39:44 GMT NNTP-Posting-Host: 82.10.238.153 X-Trace: newsfe4-gui.ntli.net 1148477984 82.10.238.153 (Wed, 24 May 2006 14:39:44 BST) NNTP-Posting-Date: Wed, 24 May 2006 14:39:44 BST Organization: NTL Xref: g2news2.google.com comp.lang.ada:4409 comp.lang.fortran:10195 Date: 2006-05-24T13:39:44+00:00 List-Id: 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: >> >>> Hello, >>> >>> Dr. Adrian Wrigley wrote: >>> >>> >>> >>>> Isn't this a bit more like MPI? >>> Well, it's like MPI minus the rubbish. >>> >>>> In Ada, these concurrency features are very robust and streamlined. >>>> This is because tasking was a primary goal of the language design. >>>> >>>> For a typical Fortran application like weather forecasting, this >>> ^^^^ >>>> is exactly the architecture you might choose. It may be >>>> hardcore numerical code. >>> I'm not sure which antecedent "this" references, >>> but the meteorological folks are one of the main >>> forces behind co-arrays. >> >> In a weather forecasting program you want to have data >> acquisition (real-time), prediction (computation) and display >> (real-time GUIs) running on a continuous, high uptime basis >> across a network of machines. >> >> If Fortran had strong multitasking, real-time and distributed >> capabilities, these goals would be reasonable and achievable >> within the language. Absence of these features means such >> systems would often (I guess) be multi-language setups, with things >> like Java, C++, Tcl/Tk, shell scripts, cron jobs etc. playing a part. >> Has anyone here worked on a big meteorological system? Am I right? >> > > 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