Absolutely not!!! NASA uses it to slam probes into Mars.
If you BOTHER TO READ the report of the navigation failure of the Mars climate orbiter, you'll see that it had several causes unrelated to the fact that the software is written in Fortran.
1. Lockheed and Martin, now one, have done business with JPL for decades. They well know that everything is metric. Inexplicably, when the spacecraft did attitude maneuvers (which because of imbalances can change the trajectory) they reported the results of their "small forces" model in pound seconds, not Newton seconds, so they were off by a factor of 4.4.
2. A member of the navigation operations team, which was overworked, understaffed and undertrained, noticed an anomaly in the trajectory several weeks before encounter. He didn't have the expertise to understand what it was (read the part about "undertrained" above), his boss told him "you don't have time to worry about that" (read the part about "overworked understaffed" above), and because the JPL senior management has been hard at work for a decade demolishing the institutional infrastructure of experts, there was nobody he could return to.
3. When it became obvious, even to managers, that there was something wrong with the trajectory, a "tiger team" meeting was called, with engineering, propulsion, operations, software, managers, etc. After much discussion, it was decided to do a fifth trajectory correction maneuver, since by that time the uncertainty in the spacecraft position exceeded 60 kilometers. After the meeting, the managers went back to their castle and decided not to do it.
Absolutely not!!! NASA uses it to slam probes into Mars.
If you BOTHER TO READ the report of the navigation failure of the Mars climate orbiter, you'll see that it had several causes unrelated to the fact that the software is written in Fortran.
1. Lockheed and Martin, now one, have done business with JPL for decades. They well know that everything is metric. Inexplicably, when the spacecraft did attitude maneuvers (which because of imbalances can change the trajectory) they reported the results of their "small forces" model in pound seconds, not Newton seconds, so they were off by a factor of 4.4.
2. A member of the navigation operations team, which was overworked, understaffed and undertrained, noticed an anomaly in the trajectory several weeks before encounter. He didn't have the expertise to understand what it was (read the part about "undertrained" above), his boss told him "you don't have time to worry about that" (read the part about "overworked understaffed" above), and because the JPL senior management has been hard at work for a decade demolishing the institutional infrastructure of experts, there was nobody he could return to.
3. When it became obvious, even to managers, that there was something wrong with the trajectory, a "tiger team" meeting was called, with engineering, propulsion, operations, software, managers, etc. After much discussion, it was decided to do a fifth trajectory correction maneuver, since by that time the uncertainty in the spacecraft position exceeded 60 kilometers. After the meeting, the managers went back to their castle and decided not to do it.
All that the world needs is a good way to call FORTRAN functions from within C++ - and we already have that.
Ermmm, I don't know how to create a Fortran pointer in C++, let alone pass it to a Fortran procedure. Fortran pointers drag around bounds and stride information for arrays, but then this isn't important for a language that doesn't actually have arrays.
Speaking of which, how do I pass an assumed-shape array from C++ to Fortran. OOPS, I almost forgot that C++ doesn't really have arrays.
Gee, I sure would like to use that Fortran library code that has optional arguments, but I don't know how C++ could represent an absent optional argument.
The point of all this sarcasm is that there's lots of useful stuff in Fortran that you can't do in C++ or get at from C++.
It is really hard for them to avoid the impression that they are behind the times when the DRAFT of the Fortran 2000 specification comes out in 2002.
I mean when the final specification is released in what, 2004, everyone is going to say "Hey look, Fortran is a really up-to date language?"
Would Ford show the prototype of the 2000 Focus in 2002 and then actually sell the 2000 Focus starting in 2005?
Ford didn't have the guts to announce the specifications for the 2005 model year Focus in 1997, and announce that it would be shown as a concept car in 2000.
Fortran 2000 is called that because in 1995 its first public review was originally scheduled to be in 2000. By the time the feature set was nailed down in 1997, it was clear that the first public review would be in 2002. You wouldn't even know if Ford slipped their first public review.
Perhaps Captain Albert hasn't noticed that Eisenhower is no longer president. There have been four editions of Fortran standards since its introduction in 1956, each one providing useful additional functionality. The next one does the same.
Fortran isn't less expressive than C, it's differently expressive. Fortran lacks bit-level fields of structs, but it provides for array operations. The target of Fortran is scientific and engineering computing, not games or dishwasher controllers. When some people say that Fortran is less expressive than C, they mean that C has pointers. Well, Fortran has had pointers for a decade. But Fortran doesn't allow arithmetic with them. Some might say this means C is more expressive, but it was shown in the 1970's that C's allowing arithmetic on pointers causes C pointer optimization to be NP-hard. So you pay for C's "expressive pointers" by subverting any possibility to do a good job of optimizing them.
Leslie Hatton has been studying software defects and their causes (look for his work in IEEE Computer Society publications). He found that the defect density in C++ programs is 2-3 times higher than in equivalent Fortran or Ada programs, and their cost-per-defect to repair is 2-3 times higher too, resulting in a six-fold increase in cost to "own" a C++ program. So you pay for C++ expressiveness with unreliable expensive-to-own programs.
Hatton found C to be sufficiently fragile that he wrote "Safer C," to give some guidance to practitioners who insist on writing "mission critical" applications using an assembler designed for the PDP-11.
When Rational and Verdix merged in 1994 Stephen Ziegler noticed that they both had developed equivalent products in C and Ada, and had kept very careful diaries. He observed that C programs have an "ownership" cost roughly twice the "ownership" cost of Ada programs. See http://www.rational.com/products/whitepapers/ 337.j sp
One should use the correct tool for each job. Fortran remains the correct tool for computational mathematics. Additions to Fortran since 1966 have addressed difficulties in software engineering, making Fortran more suitable for other applications -- but not more suitable than other languages would be if there were no need for high-performance computation.
J. Chrysostom wrote "The good ol' F77 LAPACK is a haven... there is a f2c'd version of LAPACK for C, but it involves playing all sorts of obnoxious memory games, as F77 doesn't support dynamic memory allocation. I don't like allocating tremendous arrays to pass to FORTRAN routines for work space...." Are you aware that Carter is no longer president? There have been two Fortran standards since the 1977 standard. Have a look at Fortran 95. Michel Olagnon has compiled a nice set of links at http://www.rz.uni-karlsruhe.de/~Fortran90/olagnon- faq.html. To address Chrysostom's complaint more directly, dynamic storage allocation was provided in the 1990 Fortran standard. Indeed, there are separate forms to provide Java allocatable semantics when that is adequate (preferable from the optimization point of view), and something more like C pointer semantics (but without pointer arithmetic) when you need a sharper knife (with which to cut your own throat, that is).
In a rant, karzan wrote "I simply don't see the point in any language that takes more than 10 pages to document." Sorry to disillusion you, but the C standard is 550 pages. Simplicity is the usual reason given to prefer C over Fortran 95 or Ada 95. The Fortran 95 standard is 406 pages (including the index). The Ada standard's pages aren't consecutively numbered, but it looks to be about 500 pages. These pages are smaller, however, than the 8.5 x 11 inch pages of the C and Fortran standards. So, by the objective but perhaps misleading metric of the number of pages in their standards, C is the most complicated among C 9x, Ada 95 or Fortran 95.
Slashdot Mirror
Absolutely not!!! NASA uses it to slam probes into Mars.
If you BOTHER TO READ the report of the navigation failure of the Mars climate orbiter, you'll see that it had several causes unrelated to the fact that the software is written in Fortran.
1. Lockheed and Martin, now one, have done business with JPL for decades. They well know that everything is metric. Inexplicably, when the spacecraft did attitude maneuvers (which because of imbalances can change the trajectory) they reported the results of their "small forces" model in pound seconds, not Newton seconds, so they were off by a factor of 4.4.
2. A member of the navigation operations team, which was overworked, understaffed and undertrained, noticed an anomaly in the trajectory several weeks before encounter. He didn't have the expertise to understand what it was (read the part about "undertrained" above), his boss told him "you don't have time to worry about that" (read the part about "overworked understaffed" above), and because the JPL senior management has been hard at work for a decade demolishing the institutional infrastructure of experts, there was nobody he could return to.
3. When it became obvious, even to managers, that there was something wrong with the trajectory, a "tiger team" meeting was called, with engineering, propulsion, operations, software, managers, etc. After much discussion, it was decided to do a fifth trajectory correction maneuver, since by that time the uncertainty in the spacecraft position exceeded 60 kilometers. After the meeting, the managers went back to their castle and decided not to do it.
Absolutely not!!! NASA uses it to slam probes into Mars.
If you BOTHER TO READ the report of the navigation failure of the Mars climate orbiter, you'll see that it had several causes unrelated to the fact that the software is written in Fortran.
1. Lockheed and Martin, now one, have done business with JPL for decades. They well know that everything is metric. Inexplicably, when the spacecraft did attitude maneuvers (which because of imbalances can change the trajectory) they reported the results of their "small forces" model in pound seconds, not Newton seconds, so they were off by a factor of 4.4.
2. A member of the navigation operations team, which was overworked, understaffed and undertrained, noticed an anomaly in the trajectory several weeks before encounter. He didn't have the expertise to understand what it was (read the part about "undertrained" above), his boss told him "you don't have time to worry about that" (read the part about "overworked understaffed" above), and because the JPL senior management has been hard at work for a decade demolishing the institutional infrastructure of experts, there was nobody he could return to.
3. When it became obvious, even to managers, that there was something wrong with the trajectory, a "tiger team" meeting was called, with engineering, propulsion, operations, software, managers, etc. After much discussion, it was decided to do a fifth trajectory correction maneuver, since by that time the uncertainty in the spacecraft position exceeded 60 kilometers. After the meeting, the managers went back to their castle and decided not to do it.
All that the world needs is a good way to call FORTRAN functions from within C++ - and we already have that.
Ermmm, I don't know how to create a Fortran pointer in C++, let alone pass it to a Fortran procedure. Fortran pointers drag around bounds and stride information for arrays, but then this isn't important for a language that doesn't actually have arrays.
Speaking of which, how do I pass an assumed-shape array from C++ to Fortran. OOPS, I almost forgot that C++ doesn't really have arrays.
Gee, I sure would like to use that Fortran library code that has optional arguments, but I don't know how C++ could represent an absent optional argument.
The point of all this sarcasm is that there's lots of useful stuff in Fortran that you can't do in C++ or get at from C++.
It is really hard for them to avoid the impression that they are behind the times when the DRAFT of the Fortran 2000 specification comes out in 2002.
I mean when the final specification is released in what, 2004, everyone is going to say "Hey look, Fortran is a really up-to date language?"
Would Ford show the prototype of the 2000 Focus in 2002 and then actually sell the 2000 Focus starting in 2005?
Ford didn't have the guts to announce the specifications for the 2005 model year Focus in 1997, and announce that it would be shown as a concept car in 2000.
Fortran 2000 is called that because in 1995 its first public review was originally scheduled to be in 2000. By the time the feature set was nailed down in 1997, it was clear that the first public review would be in 2002. You wouldn't even know if Ford slipped their first public review.
Perhaps Captain Albert hasn't noticed that Eisenhower is no longer president. There have been four editions of Fortran standards since its introduction in 1956, each one providing useful additional functionality. The next one does the same.
/ 337.j sp
Fortran isn't less expressive than C, it's differently expressive. Fortran lacks bit-level fields of structs, but it provides for array operations. The target of Fortran is scientific and engineering computing, not games or dishwasher controllers. When some people say that Fortran is less expressive than C, they mean that C has pointers. Well, Fortran has had pointers for a decade. But Fortran doesn't allow arithmetic with them. Some might say this means C is more expressive, but it was shown in the 1970's that C's allowing arithmetic on pointers causes C pointer optimization to be NP-hard. So you pay for C's "expressive pointers" by subverting any possibility to do a good job of optimizing them.
Leslie Hatton has been studying software defects and their causes (look for his work in IEEE Computer Society publications). He found that the defect density in C++ programs is 2-3 times higher than in equivalent Fortran or Ada programs, and their cost-per-defect to repair is 2-3 times higher too, resulting in a six-fold increase in cost to "own" a C++ program. So you pay for C++ expressiveness with unreliable expensive-to-own programs.
Hatton found C to be sufficiently fragile that he wrote "Safer C," to give some guidance to practitioners who insist on writing "mission critical" applications using an assembler designed for the PDP-11.
When Rational and Verdix merged in 1994 Stephen Ziegler noticed that they both had developed equivalent products in C and Ada, and had kept very careful diaries. He observed that C programs have an "ownership" cost roughly twice the "ownership" cost of Ada programs. See
http://www.rational.com/products/whitepapers
One should use the correct tool for each job. Fortran remains the correct tool for computational mathematics. Additions to Fortran since 1966 have addressed difficulties in software engineering, making Fortran more suitable for other applications -- but not more suitable than other languages would be if there were no need for high-performance computation.
J. Chrysostom wrote "The good ol' F77 LAPACK is a haven ... there is a f2c'd version of LAPACK for C, but it involves playing all sorts of obnoxious memory games, as F77 doesn't support dynamic memory allocation. I don't like allocating tremendous arrays to pass to FORTRAN routines for work space...." Are you aware that Carter is no longer president? There have been two Fortran standards since the 1977 standard. Have a look at Fortran 95. Michel Olagnon has compiled a nice set of links at http://www.rz.uni-karlsruhe.de/~Fortran90/olagnon- faq.html. To address Chrysostom's complaint more directly, dynamic storage allocation was provided in the 1990 Fortran standard. Indeed, there are separate forms to provide Java allocatable semantics when that is adequate (preferable from the optimization point of view), and something more like C pointer semantics (but without pointer arithmetic) when you need a sharper knife (with which to cut your own throat, that is).
In a rant, karzan wrote "I simply don't see the point in any language that takes more than 10 pages to document." Sorry to disillusion you, but the C standard is 550 pages. Simplicity is the usual reason given to prefer C over Fortran 95 or Ada 95. The Fortran 95 standard is 406 pages (including the index). The Ada standard's pages aren't consecutively numbered, but it looks to be about 500 pages. These pages are smaller, however, than the 8.5 x 11 inch pages of the C and Fortran standards. So, by the objective but perhaps misleading metric of the number of pages in their standards, C is the most complicated among C 9x, Ada 95 or Fortran 95.