[comp.lang.fortran] FORTRAN vs. "PC languages"

ldl6737@rouge.usl.edu (Lafleur L Dwynn) (05/25/91)

Most of us physicists, mathematicians, and engineers educated in the '60s and
'70s cut our programming teeth on mainframe computers using FORTRAN.  Many have
since moved from mainframes to personal computers and have found that there are
other languages much more convenient for the PC platform, especially those which
come packaged in a friendly, efficient programming environment (e.g., QuickBASIC
or Turbo Pascal). Also, manufacturers of circuit boards that interface PCs to
laboratory instrumentation (e.g., the Hewlett-Packard HPIB interface card) tend
to write the interface software in these newer "PC languages", but not in
FORTRAN.  Some schools of engineering are, in fact, replacing FORTRAN with
others as the language of choice.

Now, I for one find it very difficult to program almost daily in two different
languages.  Maybe that's a sign of age, but I suspect most scientists would
prefer to stick to just one language if they could.  Putting aside the question
of the effort involved, why don't most of us leave FORTRAN for one of the newer
languages?  In discussions with others, I seem to find two primary reasons for
sticking to FORTRAN: (1) there exists a large stockpile of numerical subroutines
and packages written over the decades, and (2) many of us do computation
involving expressions with lots of operations on and functions of complex
variables, a variable type not allowed in binary operations in such languages as
BASIC, Pascal, and C.

If you are a big user of existing FORTRAN software packages, the first of these
reasons is sufficient for staying with FORTRAN and the question is decided.
However, the second reason is beginning to erode.  The recent appearance of C++
and other object oriented languages gives the programmer the use of complex
operations with the almost the same ease as in FORTRAN.  In fact, I understand
the rather popular Turbo C++ includes a library defining essentially all the
complex operations and functions appearing in FORTRAN.

I am posting this message to stimulate an exchange of opinions between FORTRAN
users about the advisability and experiences of switching to other languages.
What do you think?


L. Dwynn Lafleur
Professor of Physics
University of Southwestern Louisiana
lafleur@usl.edu

rfinch@caldwr.water.ca.gov (Ralph Finch) (05/26/91)

I hope this doesn't deteriorate into another argument about:  Fortran
stinks; no it doesn't; yes it does; etc.  Well here goes anyway.

First of all, I think it's quite possible to know and use 2 or 3
languages.  Around here we use Fortran, shell scripts, awk, and IDL
pretty often.  Each has their place, and what's easy to do in one is
difficult in the other.  Rather than junk Fortran for the latest
new-fangled language, I would much rather see Fortran updated more
frequently, at least once every 5 years.
-- 
Ralph Finch			916-445-0088
rfinch@water.ca.gov		...ucbvax!ucdavis!caldwr!rfinch
Any opinions expressed are my own; they do not represent the DWR

john@spectre.unm.edu (John Prentice) (05/26/91)

In article <31746@rouge.usl.edu> ldl6737@rouge.usl.edu (Lafleur L Dwynn) writes:
>
>I am posting this message to stimulate an exchange of opinions between FORTRAN
>users about the advisability and experiences of switching to other languages.
>What do you think?
>

There are lots of valid arguments pro and con concerning Fortran, but I think
if you want to perfectly honest about it, the main reason scientists don't
switch from Fortran is twofold.  First, most scientists know virtually 
nothing about computers (though alot talk a great line).  So they use what
they have been led to believe is the language of scientists, namely Fortran.
For those few who seem to actually know more about computers than just how
to use the mail utility, I think alot of them stay with Fortran because their
needs are simple and Fortran suits them fine.  For the minority who are
doing serious computational science, there is considerable ferment over
whether Fortran is now or will the future be the language to use.  But those
people doing really serious work with computers are a minority, at least
in physics (mind you, I am talking about people >really< doing work, not
the many who talk about it but actually no next to nothing other than the
jargon).  None of this says anything about whether Fortran is a good or
a bad language, it says loads about scientists however.

John


-- 
John K. Prentice    john@unmfys.unm.edu (Internet)
Dept. of Physics and Astronomy, University of New Mexico, Albuquerque, NM, USA
Computational Physics Group, Amparo Corporation, Albuquerque, NM, USA

vsnyder@jato.jpl.nasa.gov (Van Snyder) (05/30/91)

In article <31746@rouge.usl.edu> ldl6737@rouge.usl.edu (Lafleur L Dwynn) writes:
>Most of us physicists, mathematicians, and engineers educated in the '60s and
>'70s cut our programming teeth on mainframe computers using FORTRAN.  Many have
>since moved from mainframes to personal computers and have found that there are
>other languages much more convenient for the PC platform, especially those which
>come packaged in a friendly, efficient programming environment (e.g., QuickBASIC
>or Turbo Pascal). Also, manufacturers of circuit boards that interface PCs to
>laboratory instrumentation (e.g., the Hewlett-Packard HPIB interface card) tend
>to write the interface software in these newer "PC languages", but not in
>FORTRAN.  Some schools of engineering are, in fact, replacing FORTRAN with
>others as the language of choice.
>
>Now, I for one find it very difficult to program almost daily in two different
>languages.  Maybe that's a sign of age, but I suspect most scientists would
>prefer to stick to just one language if they could.  Putting aside the question
>of the effort involved, why don't most of us leave FORTRAN for one of the newer
>languages?  In discussions with others, I seem to find two primary reasons for
>sticking to FORTRAN: (1) there exists a large stockpile of numerical subroutines
>and packages written over the decades, and (2) many of us do computation
>involving expressions with lots of operations on and functions of complex
>variables, a variable type not allowed in binary operations in such languages as
>BASIC, Pascal, and C.
>
>If you are a big user of existing FORTRAN software packages, the first of these
>reasons is sufficient for staying with FORTRAN and the question is decided.
>However, the second reason is beginning to erode.  The recent appearance of C++
>and other object oriented languages gives the programmer the use of complex
>operations with the almost the same ease as in FORTRAN.  In fact, I understand
>the rather popular Turbo C++ includes a library defining essentially all the
>complex operations and functions appearing in FORTRAN.
>
>I am posting this message to stimulate an exchange of opinions between FORTRAN
>users about the advisability and experiences of switching to other languages.
>What do you think?
>
>
>L. Dwynn Lafleur
>Professor of Physics
>University of Southwestern Louisiana
>lafleur@usl.edu

When the Fortran 77 standard was promulgated, Fortran was the only standardized
and widely available language that got arrays right.  Pascal still doesn't
allow open arrays.  Modula-2 allows open arrays of one dimension.  PL\I and Ada
aren't widely available.  Arrays in C are a bogus pointer manipulation that has
a few quirks that make arrays not quite right.

Fortran 90 improves on Fortran 77 arrays by making whole arrays and array
sections first class objects.  And now machine inquiry is standardized as well.

There are lots of things in Fortran 90 that I would have done differently
(mostly more regularly), but on the whole, nothing compares yet for numerical
work.
-- 
vsnyder@jato.Jpl.Nasa.Gov
ames!elroy!jato!vsnyder
vsnyder@jato.uucp

jlg@cochiti.lanl.gov (Jim Giles) (05/30/91)

In article <1991May29.205700.27104@jato.jpl.nasa.gov>, vsnyder@jato.jpl.nasa.gov (Van Snyder) writes:
|> 
|> Fortran 90 improves on Fortran 77 arrays by making whole arrays and array
|> sections first class objects.  And now machine inquiry is standardized as well.
|> 
|> There are lots of things in Fortran 90 that I would have done differently
|> (mostly more regularly), but on the whole, nothing compares yet for numerical
|> work.

Well, there is, but I doubt it will ever be implemented.  There was some
talk about revising the standard more often (like every 5 years) in the
last couple of weeks.  Well, 5 years from Fortran 77 (1982) a document
was published by the DOE called the LWG Fortran Manual.  It was the result
of the DOE Language Working Group effort to propose useful extensions to
Fortran 77.  The committee was small and exclusive with representatives
from only the 8 DOE labs.

In every respect, the LWG Fortran proposal is superior to the Fortran 90
proposed standard.  Not only does it beat Fortran 90 on a feature by 
feature basis, it also has the obvious features that Fortran 90 left out:
variant records, recursive data types, asynchronous I/O, BIT type, Cray
style pointers, conditional compilation, macros, and compiler directives
for listing and optimizataion control.  And yes, it also has machine
inquiry functions.

There are things in the LWG document I would have done differently if
it were solely up to me.  But, I would support it as a proposed standard
and I oppose the Fortran 90 proposal (which is a decade later and not as
good).

J. Giles

sjc@borland.com (Steve Correll) (05/31/91)

Prof. Lafleur asks an interesting question: essentially, "If you had to write a
numerical application entirely from scratch, would you use Fortran or C++?"

I wouldn't use Pascal, C, or Modula-2, because each has at least one of these
defects:

 1. Can't declare a true multidimensional array with arbitrary lower bounds.

 2. Can't reshape an array by passing it as an actual argument, or design a
  single function to operate automatically on arrays of varying shape.

 3. Can't use intrinsic functions and operators on doubleprecision and complex
  data.

 4. Can't control the precision and order of evaluation of arithmetic
   expressions.

The good news? C++ can do all of these. Examples in Stroustrup's book provide a
starting point for (1) and (2); as noted, Borland C++ provides a library for
(3) (actually, it's for doublecomplex, but complex is an easy extension).

Fortran remains much more convenient with regard to (4). Whereas Fortran says
"parentheses are sacrosanct", C++ permits the compiler to use arithmetic
identities which create or destroy parentheses, so the user may need to break
an expression into multiple assignment statements to prevent reordering.

Fortran 90 has raised the goalposts somewhat by adding dynamic allocation,
array sectioning, and intrinsic functions and operators on arrays, but these
are all clearly possible with C++: somebody just has to spend time writing
class libraries to implement them.

So what's the bad news?

The C++ compiler has a tougher time generating efficient code, because it knows
less about the program. For example, confront a hypothetical Fortran 90 compiler
with a statically indexed array copy:

	X(1:10) = X(11:20) + X(21:30)

It can observe at compilation time that the source and target are disjoint and
emit special-case code that avoids using an intermediate temporary array. The
C++ compiler sees a bunch of operators overloaded with library functions which
were written to handle the general case, where copying is required. If the
author of the functions was careful, s/he tests the source and target for
disjoint-ness and branches to special-case code which avoids the temporary--but
that test occurs at execution time, every time you invoke the operation.

(Other examples involving dynamically indexed arrays are equally problematical
for both compilers, of course.)

In time, I expect the best C++ implementations will inline the function calls,
analyze the dependencies, eliminate the test, discard the unreachable code, and
thus generate the same code as our hypothetical Fortran 90 compiler does in the
special case (and better code in the general case, unless the Fortran 90
compiler adopts similar optimizations).

But the C++ implementor must solve a bunch of general problems in optimization
(a lot of work, at the end of which everything runs faster) whereas the
Fortran 90 implementor can use heuristics to optimize specific common cases
(only the common cases improve, but you can deliver sooner).

A rash prediction: early Fortran 90 compilers will be so lousy that the best
current C++ implementations with carefully written class libraries would beat
them at execution time. Later Fortran 90 compilers will step ahead via
heuristics. Then C++ will catch up by implementing more sophisticated general
optimizations sooner (Fortran 90 compilers are handicapped by a late start, and
will spend a lot of time shaking out semantics-versus-optimizer bugs due to
their complicated source language). In the long run, if Fortran 90 is popular,
its compilers should come out ahead in performance both because some things
just aren't visible to C++ at compilation time, and because the Fortran
market values numerical performance more highly than the C++ market does.

fitz@mml0.meche.rpi.edu (Brian Fitzgerald) (06/02/91)

Lafleur L Dwynn writes:

>Some schools of engineering are, in fact, replacing FORTRAN with
>others as the language of choice.

Why would a dean of engineering declare a language of choice?  :-)

Brian

userAKDU@mts.ucs.UAlberta.CA (Al Dunbar) (06/04/91)

In article <a=rhbw+@rpi.edu>, fitz@mml0.meche.rpi.edu (Brian Fitzgerald) writes:
>Lafleur L Dwynn writes:
> 
>>Some schools of engineering are, in fact, replacing FORTRAN with
>>others as the language of choice.
> 
>Why would a dean of engineering declare a language of choice?  :-)
> 
>Brian
 
Indeed! And while in the process of forcing a "language of choice"
on the students, why would they settle on "others" to be this
language? This must certainly be a generic school! I would go
there if I could -- the answer to every exam question would be
"none of the above". It would be hard to get a job, though, if
you had to write "other" or "not applicable" to indicate your
major or specialization. Of course, it might be impressive to
put "varying" for "degrees". "salary expectation" could be made
more specific, with "certainly".
 
 -------------------+-------------------------------------------
 Al Dunbar          | 
 Edmonton, Alberta  |  Disclaimer: "not much better than
 CANADA             |                  datclaimer"    
 -------------------+-------------------------------------------