wtwolfe@hubcap.clemson.edu (Bill Wolfe) (04/11/90)
In the April 1990 issue of _Communications of the ACM_, the
"viewpoint" section contains an article from Geoffrey Hunter
of the York University Chemistry Department, which contends
(in response to major flaws in the Fortran-8x proposal):
"...Fortran-77 should be retained as the *last* ANSI/ISO
Standard dialect, and its deficiencies should be remedied
by selection of an established block-structured language
(probably Ada, possibly Algol-68) as an alternative to
Fortran-8x. Fortran programmers should be advised to
switch to this alternative language for their future
programming projects. Translation of existing programs
should be automated with a Fortran-77 to Ada/Algol-68
pre-processor."
Clearly there is some lack of understanding here as to the
general advisability of opting for automatic translation, and
the important alternate strategy of applying pragma Interface
has been overlooked. But the response by David Bailey of the
NASA Ames Research Center at Moffett Field is even worse:
"I simply do not believe that it is realistic to hope that
serious Fortran application programs could be automatically
translated to Ada or Algol-68."
This will certainly come as a surprise to the companies and
projects which have done exactly this on a fairly large scale,
to Richard Waychoff (who has implemented the Fortran-to-Ada
translator which is available in the Ada Software Repository),
and to companies such as Lexeme which are in the business of
providing automatic Fortran-to-Ada translation services!! Bailey
continues:
"We in the large-scale scientific computation community are
now moving ahead very seriously with plans to use the highly
parallel teraflops-class systems that will be available before
the year 2000. In a fairly wide range of applications that
we wish to map to these systems, the central time-intensive
computations can be expressed easily as array operations.
This class of computations certainly includes the large-grid
PDE codes that are the mainstay of centers such as ours. The
array constructs of the proposed Fortran standard are perfectly
suited for this type of computation. They represent the first
serious step to prividing standard parallel programming constructs
that can be efficiently supported across a variety of parallel
systems, including both SIMD and MIMD designs."
Is there anyone in NUMWG or 9XWG who'd like to take on this issue?
"Hunter summarizes by saying "the only technically rational way
of advancing the art of scientific and engineering programming
is to abandon Fortran in favor of a modern block-structured
language such as Algol-68 or Ada." This suggestion will simply
not be taken seriously by the heavy-duty scientific computation
community. These users simply cannot walk away from large
application programs with 100,000+ lines of code. Also, this
suggestion will not be taken seriously by those of us who are
exploring highly parallel scientific computation, since at
present, there is no prospect of standardizing array computation
constructs in any major language except Fortran-8x."
Again, the applicability of pragma Interface has been overlooked!
Such inaccurate or incomplete information on Ada, *especially* in
a publication like CACM, needs to be straightened out very quickly;
I hope that in addition to any discussion that might take place
here in comp.lang.ada, someone from the SEI will write to CACM to
straighten out these two regarding the feasibility (yes) and the
general advisability (no) of automatic Fortran-to-Ada translation,
as well as the alternative strategy of using pragma Interface, and
that someone from NUMWG, 9XWG, or both will write CACM regarding
the other technical points raised by Bailey.
Bill Wolfe, wtwolfe@hubcap.clemson.eduhirchert@ux1.cso.uiuc.edu (Kurt Hirchert) (04/12/90)
In fairness to Bailey, I would note o Saying that some people have found the results of automatic translation to be acceptable is quite different from saying the automatic translation of Fortran programs is good enough to impose on the entire Fortran community. o Citing services such as Lexeme's ignores the fact that the use of their service is not economically realistic for much of the Fortran community. o Automatically translated programs won't necessarily produce an acceptable level of performance. (Fortran's inbuilt restictions to allow high performance are hard to mimic in a language which doesn't have them. Certainly an Ada processor could have pragmas to assert similar restrictions, but I am not aware of any that have such pragmas today.) I'm not saying you shouldn't respond to Bailey's comments, but try to avoid looking like language bigots or reactionaries. -- Kurt W. Hirchert hirchert@ncsa.uiuc.edu National Center for Supercomputing Applications
jcallen@Encore.COM (Jerry Callen) (04/12/90)
In article <1990Apr11.190324.27161@ux1.cso.uiuc.edu> hirchert@ux1.cso.uiuc.edu (Kurt Hirchert) writes: >In fairness to Bailey, I would note > >o Saying that some people have found the results of automatic translation > to be acceptable is quite different from saying the automatic translation > of Fortran programs is good enough to impose on the entire Fortran > community. I'll say, and I'm not even a "Fortran person." See below. > [stuff deleted] > >o Automatically translated programs won't necessarily produce an acceptable > level of performance. (Fortran's inbuilt restictions to allow high > performance are hard to mimic in a language which doesn't have them. I recently worked on an Ada "benchmark" that was obviously a Fortran program that had been machine translated to Ada. Fortran statement numbers were changed to labels that looked like <<L005>>, looping constructs were converted to if tests and gotos and in general the code was real garbage. The labels and gotos will cause any reasonable optimizer to have fits and give up. Unless an automatic translation system can do a MUCH better job, it's useless. I can't IMAGINE trying to maintain this sort of crap. >I'm not saying you shouldn't respond to Bailey's comments, but try to avoid >looking like language bigots or reactionaries. I don't have a strong opinion regarding Fortran 8X (or 90, or whatever it ends up being called). I do have a good friend who's been very heavily involved with X3J3 and he has expressed occasional disgust with the whole process; it IS at least somewhat political, and even he isn't completely convinced that updating Fortran is a great idea. Geez, can't ANY programming language be allowed to die in its sleep of old age? :-) In any case, I can't think of any good reason to translate perfectly functional code to Ada or Modula or Algol 68 (Algol 68?!? Get real...); leave it in Fortran, and use pragma interface if you need to access it from Ada. It certainly makes sense to use a more recent language for NEW code, though, IF a compiler with suitable performance is available. >Kurt W. Hirchert hirchert@ncsa.uiuc.edu >National Center for Supercomputing Applications -- Jerry Callen jcallen@encore.com Speaking from, but certainly not for, Encore Computer Corporation.