Re: Ada vs Fortran for scientific applications

["Dr. Adrian Wrigley" <amtw@linuxchip.demon.co.uk.uk.uk>]

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