Dea Readers:
Van Snyder, a voting member of J3, sent this excellent critique of
the "PETITION TO RETIRE FORTRAN" to the author last night, with a copy
to the J3 Mailing List <[log in to unmask]>. I thought that readers of
comp-fortran-90 might like to have a copy.
-------- Original Message --------
From: - Fri Feb 20 07:08:40 2004
X-UIDL: 4112107725186023
X-Mozilla-Status: 0001
X-Mozilla-Status2: 00000000
Received: by pop5.mx.voyager.net (mbox [log in to unmask]) (with
voyager.net's vgrpop Fri, 20 Feb 2004 08:07:59)
Received: from envelope.rose-hulman.edu (envelope.rose-hulman.edu
[137.112.8.21]) by mx13.mx.voyager.net (8.12.9/8.10.2) with ESMTP id
i1K4bd5U008716 for <[log in to unmask]>; Thu, 19 Feb 2004 23:37:39
-0500 (EST)
Received: from dev.rose-hulman.edu
(IDENT:[log in to unmask] [137.112.50.48]) by
envelope.rose-hulman.edu (8.11.6/8.11.6) with ESMTP id i1K4bP503680;
Thu, 19 Feb 2004 23:37:26 -0500 (EST)
Received: (from mail@localhost) by dev.rose-hulman.edu (8.9.3/8.9.3) id
XAA29667 for j3-list; Thu, 19 Feb 2004 23:36:17 -0500
Received: from math.jpl.nasa.gov (math.jpl.nasa.gov [137.79.7.57]) by
dev.rose-hulman.edu (8.9.3/8.9.3) with ESMTP id XAA29661 for
<[log in to unmask]>; Thu, 19 Feb 2004 23:36:16 -0500
Received: from math.jpl.nasa.gov (localhost.localdomain [127.0.0.1]) by
math.jpl.nasa.gov (8.12.8/8.12.8) with ESMTP id i1K4Zdd3004359; Thu, 19
Feb 2004 20:35:39 -0800
Received: from math.jpl.nasa.gov (vsnyder@localhost) by
math.jpl.nasa.gov (8.12.8/8.12.8/Submit) with ESMTP id i1K4ZcXt004355;
Thu, 19 Feb 2004 20:35:39 -0800
Message-Id: <[log in to unmask]>
X-Mailer: exmh version 2.5 01/15/2001 with nmh-1.0.4
X-Exmh-Isig-CompType: comp
X-Exmh-Isig-Folder: inbox
Reply-to: [log in to unmask]
From: [log in to unmask]
Errors-To: [log in to unmask]
X-Sequence: [log in to unmask] 2004-464
To: [log in to unmask]
cc: [log in to unmask]
Subject: (j3.2004-464) Comment on PETITION TO RETIRE FORTRAN
Mime-Version: 1.0
Content-Type: text/plain
Date: Thu, 19 Feb 2004 20:35:38 -0800
Sender: [log in to unmask]
Status: U
Comments on PETITION TO RETIRE FORTRAN
http://www.fortranstatement.com/cgi-bin/petition.pl
The Fortran standard hasn't spelt Fortran with all capital letters for
fourteen years.
The petition page doesn't suggest an alternative, but I'll assume the
ones in mind are C and C++. Ada would be far better, but has an even
narrower market then Fortran. Eiffel is even less widely used. Java is
generating interest, but compiler writers are maybe a decade from having
compilers that come within a factor of two of the performance of decent
Fortran compilers. Also see "Why Java floating-point hurts everybody all
the time" by W. Kahan (http://http.cs.berkeley.edu/~wkahan/JAVAhurt.pdf).
C# has a lot of the defects of C and C++, and still isn't as widely used
as either of them.
Item 1 is wrong: The Fortran 95 standard is 386 pages, not 700 pages.
The C99 standard is 556 pages. Tell me again that Fortran 95 is more
complex than C. The draft Fortran 2003 standard is 569 pages and it's
unlikely the published standard will be more than 570 pages. The C++
standard is 783 pages. Tell me again that Fortran 2003 is more complex
than C++. If you're talking about textbooks, consider that the most
frequently-recommended Fortran 95 textbook, "Fortran 90/95 Explained," is
392 pages. "Teach yourself C++ Programming in 21 Days" is 814 pages.
"Problem Solving in C Including Breadth & Laboratories" is 973 pages plus
Appendices A through K and an index that don't have pages consecutively
numbered with the body of the text. This disparity may be partly due to
the fact that Jesse Liberty and Angela Schiflet just aren't as talented
authors as John Reid and Mike Metcalf, but a large chunk of it is due to
the inherent difference in complexity of the material.
Item 2 is misleading: C and C++ compilers also require hundreds of man
years. Despite investing far more effort in C and C++ optimizers than is
typically invested in entire Fortran compilers, they still don't generate
code that's as good as Fortran compilers do. This is caused by the
differences in semantics of the languages -- especially the difference in
the semantics of C and C++ pointers as compared to Fortran pointers.
Item 3 is misleading. A few vendors have told me that although the
market share is decreasing, the market is increasing. Nonetheless, some
vendors are struggling.
Item 4 is largely the fault of language bigots at universities, who think
that Fortran is FORTRAN 66. Many computer science professors proudly
proclaim that they haven't looked at a Fortran standard newer than
FORTRAN 66, yet they claim to be sufficiently expert to pontificate about
what they see as Fortran's failings. I've been told that many university
Engineering departments are returning to teaching their own Fortran
courses because they prefer it, and the Computer Science departments
refuse to teach it.
If by "adds no new functionality" in item 5 you mean "adds no new
functionality to Fortran," item 5 is wrong. See
ftp://ftp.nag.co.uk/sc22wg5/N1551-N1600/N1579.pdf. If it means "adds no
new functionality that can't be gotten in any language" it's still wrong,
or at least misleading. No other widely-used languages have the kind of
built-in optimized array support that Fortran provided in 1990, at least
not with comparable expressive power and efficiency.
Item 6 is wrong on both counts. I get SMP code from my Fortran compiler
simply by putting --parallel on the command line. The main thrust of the
extension from Fortran 90 to Fortran 95 was to add HPF (High Performance
Fortran) features. Item 6 is also an elephant. C and C++ programmers
resort to language extensions and toolkits, too. One of the proposals on
the table for the next revision after Fortran 2003 is Co-Array Fortran
(http://www.co-array.org), which will only make SMP better in Fortran.
Fortran has provided for direct-access input/output since 1977. Fortran
2003 will provide stream (i.e., not record oriented) input/output (see
comment on item 5).
Item 7 is a half truth, and most of the disadvantages cited are actually
advantages. Fortran does have an official preprocessor: ISO/IEC 1539-3
-- but it doesn't do macros, so Item 7 has a grain of truth in it. In
any case, it's not common to really really need a preprocessor because
Fortran programs are inherently more portable than C programs. Most
"portable" C and C++ programs consist almost entirely of preprocessor
macros and ifdef's. I have a 300,000 line Fortran 95 program that runs
on several platforms, and it doesn't have even one preprocessor directive
anywhere.
Item 8 is misleading; Fortran wasn't designed just to write toy
programs. If that's all you want, use BASIC, don't whine that Fortran
was designed for serious work. Modules are exceedingly useful in large
programs. They lead to more reliable programs for the same reason that
Ada programs are more reliable than C programs: The processor checks
references to module procedures against their definitions. Sure, C
processors check references to functions against their prototypes, but
the prototype is separate from the function body; I don't know of any C
processor that checks prototypes against function bodies.
Although item 9 is sort-of true (Fortran 77 programs are frequently
faster than equivalent Fortran 90 programs), it's also misleading;
Fortran 95 programs are usually a bit faster than equivalent C programs,
and frequently much faster than equivalent C++ programs -- especially
ones that exploit all of the "cool" features of C++.
Item 10 is misleading. The semantics of pointers in Fortran are much
better, from the point of view of an optimizer writer, than the semantics
of C pointers, optimizing which has been shown to be NP hard. So the
fact that there's a feature of Fortran that is subtly different from C
pointers and has even better semantics for optimization is an elephant.
Every organization that has a style guide for Fortran programming, i.e.,
everybody who writes real programs, recommends to use "implicit none".
Many processors have an option to assume it.
It would be a greater service to retire C++. Leslie Hatton (see
http://www.cs.kent.ac.uk/people/staff/lh8/pubs.html, and do a Google
search for more) has actually done some quantitive studies, and finds
that on average a C++ program has 2 to 3 times the statically detectable
defect density as an equivalent program in C, FORTRAN 77 or Ada, and the
cost-to-repair per defect is also 2 to 3 times higher, resulting in an
ownership cost for C++ programs that is roughly six times greater.
Here's an example. After teaching C++ numerous times, I was discussing a
simple laboratory exercise that I gave the students: Construct a package
to do complex arithmetic. I remarked that they repeatedly made the same
mistake, even though I warned them of it explicitly several times: They
returned a pointer or reference to a local struct or length-2 array. Of
course, as soon as the function returned -- BANG -- the local variable
was gone. My colleague got very quiet, and called me the next day to
tell me that he had had a C program for about twelve years that
occasionally got a bizarrely wrong answer. It turned out that one
function was returning a pointer to a local variable. He didn't know
precisely how many hundreds of hours he'd spent searching for that
problem. This guy is no naive beginner. He wrote the powered-descent
code for the Apollo Lunar Lander, tons of Shuttle code in Hal S, and was
called out of retirement to write the powered-descent code for Mars
Exploration Rover after the Mars Polar Lander crashed because its
powered-descent code failed.
This problem isn't unique to complex arithmetic. Even sophisticated C
and C++ programmers occasionally make this mistake in functions intended
to return a composite result. Even if they do remember to malloc the
result, the caller might forget to free it, resulting in a memory leak.
Fortran functions can return composite results without resorting to
pointers. There is therefore no temptation to return a pointer to a
local variable, and no chance for a memory leak.
Here's another example. In early stages of the Cassini project (a
spacecraft now on its way to Saturn), JPL was having trouble finding a
"rad hard" processor. One day, the armed forces and CIA decided there
was no really good reason to keep their rad hard processors under wraps,
and suddenly we found dozens of really good ones. We looked at the specs
and said "That one is perfect." So we froze the processor spec and
started designing around it. When it came time to start the flight
software, the developers found that the only available programming
environment was Ada (why were they surprised?). They were hopping mad,
because they had hoped to write the flight software in C++. Then, they
noticed the COMPILER was finding bugs that they might NEVER have found if
they had used C++. As with most religions, the most recently converted
are the most zealous advocates. The same is true of these guys.
Here's another example. The Mars Pathfinder flight software *was*
written in C and C++. The authors knew of a priority inversion involving
interrupts from the modem, but chose to ignore it. Well, on Mars, the
poor little machine rebooted hundreds of times every day because the
priority inversion kept the processor from getting around to updating the
heartbeat clock -- which was the interrupt frozen out by the inversion.
Of course, if they hadn't sent any data back, there wouldn't have been
any modem interrupts to cause the inversion w.r.t. the heartbeat clock,
but.... Ignoring the priority inversion would have been impossible in
Ada.
Here's another example. JPL management decided that maintenance costs
for the six-million-line spacecraft navigation suite would be reduced if
it were re-written in C++. In 1996, the estimated cost of the project
was 120 work years. Since there were at the time seven work years per
year being invested in maintaining the Fortran suite, the project would
have broken even in 2023 if maintenance costs were reduced to zero. Now,
after investing -- guess how many (hint: 120) -- work years, the
estimated cost to complete the project is -- TA DA! -- 126 work years.
One guy worked on the interface for the integrator for the initial-value
problem for ordinary differential equations -- the bread and butter of
celestial navigation -- for 18 months, and didn't even finish designing
the interface! The plan now is to continue to use the Fortran 77
version, from which a C version is derived automagically. Don't say
"Just use numerical recipes!" There is no other ODE integrator in the
world, in any language, that is up to the standard of performance,
features and accuracy necessary for this job.
Stephen Zeigler (see http://sunnyday.mit.edu/16.355/cada_art.html) has
measured ownership costs for equivalent C and Ada programs, and found his
C programs to cost twice as much as Ada programs. Fortran 95 programs
are more reliable and less expensive to own than FORTRAN 77 programs, so
the disparity between C++ and Fortran 95 programs is probably greater
than the disparity between C++ and FORTRAN 77 programs.
--
Van Snyder | What fraction of Americans believe
[log in to unmask] | Wrestling is real and NASA is fake?
Any alleged opinions are my own and have not been approved or disapproved
by JPL, CalTech, NASA, Sean O'Keefe, George Bush, the Pope, or anybody else.
--
Sincerely,
Craig T. Dedo
17130 W. Burleigh Place E-mail: [log in to unmask]
Brookfield, WI 53005-2759 Voice Phone: (262) 783-5869
USA Fax Phone: (262) 783-5928
"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety." -- Benjamin Franklin
(1759)
|
