Why Fortran?
Kenneth Mays
I learned Fortran many moons ago, but I still have this
thought..."WHY FORTRAN?!?!?"
Why are we still using this language? Are there better languages that
can replace it? Is it still the best language for the job? Job
security?
Let me know your thoughts. I heard Ada95 was going to mop
up this old dog. Any truth to this or should I pack up the old MS
Powerstation and call it quits.
Ken (km...@msn.com)
-USAF-
Kent Paul Dolan
A few reasons from a near infinite list:
1) If you are in an engineering curriculum, and you are going to
teach/learn only one programming language, it must be FORTRAN, because the
engineer needs to be able to read/understand/modify/interface-with the
huge existing engineering software base in FORTRAN. [Market momentum
counts for a lot, or Microsoft couldn't stay in business.]
2) FORTRAN 90 provides direct expressions of linear algebra operations
that make vectorization / parallelization opportunities easy for the
compiler to find and exploit.
3) Most of the world's executing linear algebra and differential/integral
equation code is probably written in FORTRAN; see 1).
4) The extant literature of many disciplines has code examples in FORTRAN;
see 1).
5) The FORTRAN 90 upgrade to the FORTRAN standard patched many problems in
the language and added several constructs that make software engineering
easier than in the past; the language is a better language than the one
you and I learned when core memory was a hot technology to replace the
vacuum tube.
6) Better languages struggle to find an audience; Sather is deliberately
crafted to solve many of the same problems as is FORTRAN, and supply
"objectness" as well, yet probably only a small fraction of FORTRAN
programmers have ever even heard of the language.
7) In particular, Ada83's teething problems and the really horrid first
batch of compilers poisoned the well for a lot of folks who tried it once
and swore never again. Ada 95 repeats the problems of Ada83 in leaving
too much to the language lawyers that is completely unintuitive to the
garden variety programmer. Any language whose printed standard spans >
500 pages is already pretty well doomed.
[For my money, Modula-2 is probably a near ideal compromise language:
simple enough to write, powerful enough to make big projects
straightforward to implement, fairly intuitive everywhere, blindingly fast
to compile and link. Its big weakness "out of the box" is I/O, but usual
implementations extend the standard enough to make it workable, at the
expense of perfect portability. The copy of the reference manual I have
weighs maybe a pound or two.]
--
Xanthian. | "..want the consequences of what you want.." |
Kent, the man from xanth. | Neil A. Maxwell, LDS Apostle |
Kent Paul Dolan ------------------------------------------------
xanthian@{well,qualcomm}.com Jobhunting? Check www.qualcomm.com!
Loren Meissner
were going to "mop up" Fortran. Anyway ADA95 has some
object-oriented features; such things may or may not be in
some future version of Fortran.
At least you should look at Fortran 90/95: it is a "better language
that can replace ... " Fortran 77.
Fortran is "still the best language for the job" if you are
into number crunching, parallelism, heavy-duty optimization, etc.
--Loren Meissner
CHI Research, Inc.
>
>Hi,
>
>I learned Fortran many moons ago, but I still have this
>thought..."WHY FORTRAN?!?!?"
>
>Why are we still using this language? Are there better languages that
>can replace it? Is it still the best language for the job? Job
>security?
>
>Let me know your thoughts. I heard Ada95 was going to mop
>up this old dog. Any truth to this or should I pack up the old MS
>Powerstation and call it quits.
>
>-USAF-
My $.02 is that language wars are meaningless. There are only compiler
wars. DEC (VMS) Fortran compiler produces very different code from,
say, MS Fortran. Dec Fortran is remarkably efficient. Time and again
I find it is impossible for me to write better Assembly that the code
that Dec Fortran compiles into.
Every so often, we get a snot-node in here who insists (loudly) that he
will write in C because he gets better control on the machine. He ends
up writing code that is, in a word, lousy and difficult to maintain.
The final answer will be dtermined by the market place, however. And I
think Fortran is probably not the best language to learn for the
future. I feel stuck with the experience I have.
Dom
Jim Glass
|> Hi,
|>
|> I learned Fortran many moons ago, but I still have this
|> thought..."WHY FORTRAN?!?!?"
|>
|> Why are we still using this language? Are there better languages that
|> can replace it? Is it still the best language for the job? Job
|> security?
|>
|> Let me know your thoughts. I heard Ada95 was going to mop
|> up this old dog. Any truth to this or should I pack up the old MS
|> Powerstation and call it quits.
|>
|> Ken (km...@msn.com)
|> -USAF-
I'll tell you why.
- Because the human race has invested too much in Fortran to ever abandon it.
- Because Fortran is the ultimate portable language--no matter what these new-
age hippies say.
- Because more brain-hours have been invested in optimizing Fortran compilers
than in all the other compilers on Earth.
- Because Fortran is the lingua franca of Science and Engineering.
- Because Fortran is elegant. [Yes, I am serious]
- Because Fortran is easy to learn, program and read. Unlike newer languages
like APL and "C" which promote "write-only" coding, you can actually UNDERSTAND
a Fortran programmer's intent even if the original progammer is DEAD.
- Because Real Programmers program in Fortran (and/or Assembly Language)
- If the human race is ever invited to join the Galactic Federation, under
'significant achievements' on the membership form, you will find:
-fire
-wheel
-J.S. Bach
-Fortran
-Silly Putty
Good enuf for yeh? Then harken ye to Glass' Theorem:
"On any planet where a High-Level language is invented, the very first one
to be of any use whatsoever will become immortal, outliving races, civilizations,
and species. On -THIS- planet, that language is Fortran."
Corollary: If we blow ourselves to oblivion, the cockroaches, having evolved
sufficiently, will find themselves programming in Fortran.
Languages come; languages go; only FORTRAN is for the ages!
Jim Glass
Phortran Phanatic
John Turner
> - Because Fortran is easy to learn, program and read. Unlike newer languages
> like APL and "C" which promote "write-only" coding, you can actually UNDERSTAND
> a Fortran programmer's intent even if the original progammer is DEAD.
While I am a Fortran (esp. 90) fan, I must insist that although it is
*possible* to write nice Fortran that anyone can understand, it is also
possible to write unintelligible gobbledygook. Of course, this is also
possible in other languages.
But just because it's in Fortran doesn't mean it's crystal clear.
And yes, the authors of some of the code I look at *are* dead.
+---------------------------------------------------------------+
| John A. Turner |
| Los Alamos National Laboratory, MS B226, Los Alamos, NM 87545 |
| Group: XTM (Radiation Transport Methods) |
| Location: TA-3, Bldg. 43, Rm. D150 |
| Phone: 505-665-1303 e-mail: tur...@lanl.gov |
+---------------------------------------------------------------+
rag...@merlin.arc.nasa.gov
>Let me know your thoughts. I heard Ada95 was going to mop
>up this old dog. Any truth to this or should I pack up the old MS
>Powerstation and call it quits.
Ada !?!?!??!?!?!?
Ha! Ha! Ha!
That's a good one. All my engineers program FORTRAN. They would quit if I
required them to program in Ada.
ar
Craig Burley
Corollary: If we blow ourselves to oblivion, the cockroaches, having evolved
sufficiently, will find themselves programming in Fortran.
Some would claim this has already happened, that we are really
the "cockroaches" left over from a previous dynasty, in which
intelligent warm-blooded reptiles programmed in Fortran 64MBC.
--
James Craig Burley, Software Craftsperson bur...@gnu.ai.mit.edu
Kenneth Plotkin
Craig Burley <bur...@gnu.ai.mit.edu> wrote:
>Some would claim this has already happened, that we are really
>the "cockroaches" left over from a previous dynasty, in which
[snip]^^^^^^^^^^^
Aha! So all those folks who keep calling me a dinosaur are wrong!
Life is good. Or at least not so bad.
Ken Plotkin
Craig C. Tierney
In article <1996Apr23.1...@nb.rockwell.com>,
Jim Glass <gl...@mrbig.rockwell.com> wrote:
>In article <00001a89...@msn.com>, KM...@msn.com (Kenneth Mays) writes:
..stuff deleted...
>
>I'll tell you why.
>
.....
>- Because Fortran is the ultimate portable language--no matter what these new-
>age hippies say.
On what basis do you make this claim. (I am not saying you are wrong I just
want to know the answer).
>- Because more brain-hours have been invested in optimizing Fortran compilers
>than in all the other compilers on Earth.
Yes, but the techniques developed to optimize Fortran compilers be used to
optimize other languages. Just because more brain-hours have been invested
this does not imply the Fortran compiliers are significantly better than
other compilers.
>- Because Fortran is easy to learn, program and read. Unlike newer languages
>like APL and "C" which promote "write-only" coding, you can actually UNDERS
>a Fortran programmer's intent even if the original progammer is DEAD.
Isn't this more a function of the coder and not the language. For C, yes
it is possible to write code that only the author will understand, that
implies a problem with the author, not the language. Is it your belief that
you cannot write readable code at all in C?
I am not trying to start any flame wars, just want to understand.
Craig
Craig Tierney (tie...@orbit.colorado.edu)
Department of Aerospace Engineering Sciences
University of Colorado at Boulder
Shirley Miller
I read your post on FORTRAN and wonder if you could help me. I am taking a
class and need to get some very basic introductory instructions on it. Can
you help me? Thanks-Shirley
Shirley Miller
Dan Pop
>In article <1996Apr23.1...@nb.rockwell.com>,
>Jim Glass <gl...@mrbig.rockwell.com> wrote:
>>In article <00001a89...@msn.com>, KM...@msn.com (Kenneth Mays) writes:
>
>..stuff deleted...
>
>>
>>I'll tell you why.
>>
>
>.....
>>- Because Fortran is the ultimate portable language--no matter what these new-
>>age hippies say.
>
>On what basis do you make this claim. (I am not saying you are wrong I just
>want to know the answer).
The claim is dead wrong. Writing portable code in Fortran is as difficult
as in most other languages.
>>- Because more brain-hours have been invested in optimizing Fortran compilers
>>than in all the other compilers on Earth.
>
>Yes, but the techniques developed to optimize Fortran compilers be used to
>optimize other languages. Just because more brain-hours have been invested
>this does not imply the Fortran compiliers are significantly better than
>other compilers.
Fortran compilers can do more aggressive optimizations than compilers for
other languages, because the semantics of the language allow more aggressive
optimizations.
>>- Because Fortran is easy to learn, program and read. Unlike newer languages
>>like APL and "C" which promote "write-only" coding, you can actually UNDERS
>>a Fortran programmer's intent even if the original progammer is DEAD.
>
>Isn't this more a function of the coder and not the language. For C, yes
>it is possible to write code that only the author will understand,
This is perfectly possible in Fortran, as well. Any language can be
abused, and Fortran is probably the most abused language (judging by the
codes I've seen).
>that
>implies a problem with the author, not the language. Is it your belief that
>you cannot write readable code at all in C?
More often than not, those displaying this kind of bigotry don't know C.
Few of them actually know any other programming language.
Dan
--
Dan Pop
CERN, CN Division
Email: dan...@mail.cern.ch
Mail: CERN - PPE, Bat. 31 R-004, CH-1211 Geneve 23, Switzerland
Mike Lay
Dan Pop wrote:
>
> In <4lr637$4...@lace.colorado.edu> tie...@Agrabah.Colorado.EDU (Craig C. Tierney) writes:
>
> >In article <1996Apr23.1...@nb.rockwell.com>,
> >Jim Glass <gl...@mrbig.rockwell.com> wrote:
> >>In article <00001a89...@msn.com>, KM...@msn.com (Kenneth Mays) writes:
> >
> >..stuff deleted...
> >
> >>
> >>I'll tell you why.
> >>
> >
> >.....
> >>- Because Fortran is the ultimate portable language--no matter what these new-
> >>age hippies say.
> >
> >On what basis do you make this claim. (I am not saying you are wrong I just
> >want to know the answer).
>
> The claim is dead wrong. Writing portable code in Fortran is as difficult
> as in most other languages.
>
other languages, but only because there exists a formal standard. If you code
to the ANSI standard, your code is likely to be portable (with the exception
of a few annoying bits of i/o).
Of course, this only applies if you avoid using your favourite compilers little
bits of chrome.....
Code written in languages where there is no machine independant standard will be
inherently more difficult to port to a different platform.
--
Mike Lay | Brevis esse laboro, obscuras fio
SubDepartment of Nuclear and Particle Physics| (I struggle to be brief, and
University of Oxford | become obscure)
"My words, not theirs" | ....... Quintus Horatius Flaccus
Dan Pop
In <3184AD...@uk.ac.ox.physics> Mike Lay <m.l...@uk.ac.ox.physics> writes:
>Code written in languages where there is no machine independant standard will be
>inherently more difficult to port to a different platform.
1. Most high level languages are defined in a machine independent way,
whether they're covered by an (inter)national standard or not.
2. Most high level languages in current use today are covered by
international standards. This includes Fortran, C, C++, Ada and
even COBOL. BASIC and Pascal also have standards, but the different
pre-standardization flavours were too many and too divergent, so the
standards could only cover a subset which wasn't large enough to make
the standardized language interesting/useful enough for developing
real applications. Hence, their standards never caught on and people
program today in Borland Pascal or Visual BASIC, generating 100%
non-portable code.
There are two kinds of portability problems:
a. Those caused by the usage of vendor-specific extensions. They are
easy to avoid, even by inexperienced programmers, if they use a
platform independent reference manual instead of the compiler
documentation. Many vendors document their extensions using a
different colour, thus facilitating the task of the programmer who
wants two write portable code using the compiler documentation as a
reference manual. Unfortunately, way too many people don't care at
all about the portability of their code.
b. Those caused by implicit assumptions about the compiler behaviour
and the underlying platform (both hardware and operating system).
It takes a bit of experience, on multiple platforms, to be aware of
this class of problems and to know how to avoid them in a reasonably
efficient way.
Class 'a' problems have the advantage that they're obvious when the code
is ported. If the target compiler implements the same extension, chances
are that it implements it in the same way as the original compiler.
If it doesn't implement it, one or more compiler diagnostics will tell
the bad news to the unfortunate programmer who is doing the port. The
problem is obvious, the solution may or may not be.
Class 'b' problems are the real headache at port time. The code will
usually compile without any diagnostic, but the output of the program
will be wrong (hopefully in an obvious way!). It takes a lot of time,
experience, patience and effort to find these problems in a non-trivial
program. Once found, they're usually easy to fix.
WRT to this discussion about portability, Fortran is neither better nor
worse than most other languages.
Craig Burley
In article <1996Apr23.1...@nb.rockwell.com>,
Jim Glass <gl...@mrbig.rockwell.com> wrote:
>- Because Fortran is the ultimate portable language--no matter what these new-
>age hippies say.
On what basis do you make this claim. (I am not saying you are wrong I just
want to know the answer).
I don't know about Jim, but it's probably true. Although for about
a decade there, perhaps C could claim portability to a significant
number of machines that couldn't handle Fortran, it seems that
the opposite has been true for most of the time they have both existed.
Almost any "real" machine had better support both languages, but
_fast_ machines have to support Fortran in any case; and, Fortran
demands less of a machine as far as its architecture to get high
performance in typical benchmarks, at least for the most part.
(At this point the reasoning gets into fine distinctions among
languages, but C, and lots of code written in semi-portable
C, makes lots more assumptions about sizes of data types plus
the behavior of the underlying OS than Fortran code does. One
notable exception is Fortran's requirement that a DOUBLE PRECISION
datum can be placed anywhere a REAL can in memory -- some modern
RISC machines don't allow this at all, or disallow it if you
use the faster instructions to access them. But byte-addressability
as found in C and depended upon by most C code is positively obnoxious
to handle speedily on many high-end machines that are designed to
run Fortran code very fast. And as a practical matter, it seems
lots less Fortran code depends on the ability to align a DOUBLE
PRECISION to a REAL boundary than C code depends on int's and
pointers being the same size, etc.)
>- Because more brain-hours have been invested in optimizing Fortran compilers
>than in all the other compilers on Earth.
Yes, but the techniques developed to optimize Fortran compilers be used to
optimize other languages. Just because more brain-hours have been invested
this does not imply the Fortran compiliers are significantly better than
other compilers.
Not generally, but there are enough specific cases where this is
true to make it significant. E.g. given:
SUBROUTINE X(A,B,C,N)
DO I=1,N
C(I)=A(I)*B(I)
END DO
END
Fortran optimizing compilers for many high-end machines know
how to schedule the above loop so it can do things like read
A(J) and B(J) _before_ it writes C(J-1) or even "earlier"
elements in the loop. C optimizing compilers, even "generic"
back ends such as gcc's, don't have this kind of knowledge because
they are not built around Fortran, which guarantees that writing
C(J-1) cannot possibly change A(J) or B(J). Yet this kind of
scheduling is _crucial_ to obtaining significant percentages
of a system's potential Operations-Per-Second rating (e.g. FLOPS,
MOPS, etc.), sometimes even crucial to making certain sensitive
applications work in the first place (e.g. reading and processing
data received continuously in real time). There's simply _no way_
to express the above semantics in C, or even C++, though I gather
NCEG is working on these kinds of things.
Yes, in this case, Fortran is placing restrictions on the programmer.
But these restrictions do serve a documentation purpose as well --
the above subroutine does not need to have comments attached saying
whether overlapping arrays is allowed, because it isn't. Of course,
if you _need_ overlapping arrays, Fortran makes doing them rather
painful in the general case (but I don't see much need to this in
applications I write, usually).
>- Because Fortran is easy to learn, program and read. Unlike newer languages
>like APL and "C" which promote "write-only" coding, you can actually UNDERS
>a Fortran programmer's intent even if the original progammer is DEAD.
Isn't this more a function of the coder and not the language. For C, yes
it is possible to write code that only the author will understand, that
implies a problem with the author, not the language. Is it your belief that
you cannot write readable code at all in C?
You can write readable code in C, but C does prevent you from writing
at the higher level Fortran does. E.g., there's no way in C to write
this in Fortran:
IF (X() .AND. Y()) ...
(Assuming X and Y are LOGICAL external functions.) In C, you'd see
either "if (x() & y()) ..." or "if (x() && (y()) ...", in either case,
the programmer has been forced to say something more specific than
necessary -- therefore, the _reader_ who comes along and reads the
code could easily conclude (in the first instance) "both of these
functions _must_ be invoked for this code to work, then the if tests
the ANDing of their results" or (in the second instance) "for this
code to work, x() must be invoked first, then IF AND ONLY IF it
returns a nonzero result, y() must be invoked second...". C forces
the programmer to write something more specific than necessary --
Fortran allows more flexibility here, while still allowing (via slightly
more verbose expressions) the programmer to express _both_ of the
examples in C.
There's a general "fight" here between not just Fortran and C, but
between the concept of general expressability and the concept of
clarity of expression. I think Fortran makes more of the right
choices for its target audience than does C, but even C makes
interesting ones (that aren't always popular, or even widely known --
e.g. the fact that "-12 >> 3" isn't defined). The temptations any
language designer has include "make the language so clean and pure
that there's no lower-level crud the programmer must be aware of
to understand the reason the language looks the way it does" AND
"make the language so well-tailored to the actual machines it runs
on that it is fairly easy and natural for the programmer to write
code that will run as fast as possible". Fortran and C are among
many languages that balance these two, each in their own ways for
their own original target applications and programmer camps.
Note that I'm not about to start picking on things C allows programmers
to do that Fortran doesn't -- I program in C almost all the time,
and most people already seem to know about these, so I don't even
worry about it. So, I'm not saying Fortran is _always_ superior to
C; I sure prefer writing my Fortran compiler in ANSI C (actually GNU C
in a few rare instances) to writing it in FORTRAN 77. Having not
tried writing much real code in either C++ or Fortran 90, I'm not
sure which I'd prefer, but while F90 might be a lot closer to C++,
I will say that Fortran's advantages tend to cater to scientific
and numeric programming, not tool programming (e.g. compilers), so
C++ might still have an edge if I was to restrict myself to an
intelligible subset of the language (as I would with F90).
Maybe not much of an edge, though.
William Clodius
I would change some of Dan Pop's statement 2 to
2. Many of the most commonly used high level languages are covered by
international standards. This includes Fortran, C, Scheme, Ada and
even COBOL. BASIC and Pascal also have standards, but the different
pre-standardization flavours were too many and too divergent, so the
standards initially could only cover a subset which wasn't large
enough to make the standardized language interesting/useful
enough for developing real applications. Hence, their standards
never caught on, although more recent standards are useable.
People program today in Borland Pascal or Visual BASIC,
generating 100% non-portable code. Other portable languages are
defined in terms of an implementation, e.g., Perl, the Gnu C and
C++ compilers, Python, etc, defined using another portable
language, typically C. Greater care must be taken in such
languages to achieve portability. C++ is currently a
combination of the two types of portable languages as it was
initially defined in terms of an implementation, and currently
has a draft, but not final, standard.
I would also note that there are certain applications that are
inherently non-portable. Operating systems and other applications
requiring interfacing to hardware or operating systems. For Fortran
programmers nowadays this typically involves graphics or other human
interface issues, but there are still some who use Fortran to control
instruments. In such cases portability problems can be reduced, but not
eliminated, by isolating the non-portable code in a few routines.
Fortran has one advantage over most other language in terms of
portability. Its long history means that lots of people have a vested
interest in porting code so that it has a larger number of vendors
than most other languages and also compilers for a larger variety of
machines. However, becaus of C's association with most current
operating systems, C undoubtably has even greater flexibility in this
regard.
--
William B. Clodius Phone: (505)-665-9370
Los Alamos National Laboratory Email: wclo...@lanl.gov
Los Alamos, NM 87545
Paul Schopf
Dan Pop wrote:
>
> In <4lr637$4...@lace.colorado.edu> tie...@Agrabah.Colorado.EDU (Craig C. Tierney) writes:
>
> >In article <1996Apr23.1...@nb.rockwell.com>,
> >Jim Glass <gl...@mrbig.rockwell.com> wrote:
[snip]
>
> >>- Because more brain-hours have been invested in optimizing Fortran compilers
> >>than in all the other compilers on Earth.
> >
> >Yes, but the techniques developed to optimize Fortran compilers be used to
> >optimize other languages. Just because more brain-hours have been invested
> >this does not imply the Fortran compiliers are significantly better than
> >other compilers.
In abstract principle this might be right, but in practice, I think it
DOES imply that they are better.
>
> Fortran compilers can do more aggressive optimizations than compilers for
> other languages, because the semantics of the language allow more aggressive
> optimizations.
This, I believe gets to the fundamental point. If you take a complex problem
and try to optimize it for a machine, you have a lot of work to do. You can
make things easier for the code writer (by having a richer, looser language structure)
or make things easier for the compiler writer (by enforcing some restraints on
the programmer). In the end, someone has to do the work. With Fortran, we already
see that fortran 90 generates slower code than Fortran77 on our machines, which I
largely attribute to the extra work that the compiler development teams have to
put in to getting highly optimized versions for all the new things you can do
with fortran 90. While other compilers and languages "can" be made more efficient,
institutional inertia is a big factor, both at the programmer level and at the
compiler development level.
It is also true that highly complex numerical models for the oceans and atmosphere
are written (coded) by oceanographers and meteorologists, and (perhaps surprisingly) not
by programmers. This is largely due to the very subtle kinds of errors that can
crop up and the need to be very sure of the quality of the results. These people
have historically trained in Fortran, and although models have been coded in other
languages, they just don't "sell" to the rest of the community, and sharing modules
like those used to solve the radiative transfer equations in an atmospheric GCM is
now commonplace. If you propose research into new and better algorithms but no one
wants to use them because they are not used to C**, then you don't get funded.
So just like English might be a harder language to learn than French (or less suitable
for expressing ...) , I would recommend using English when in Chicago and French when
in Paris.
--
Paul Schopf mailto://sch...@gsfc.nasa.gov
Coupled Climate Dynamics Group/971 http://ccdg.gsfc.nasa.gov/~paul
NASA Goddard Space Flight Center
Greenbelt, MD 20771
ESSoft
For many reasons, here are two:
y = 1/x
Who wants to be bothered by extending the code volume by declaring "type"
for x and y, much less appending the obvious with semicolons and similar
junk... We don't find that sort of appendages in papers from Riemann,
Hilbert and the likes - not to mention adding a period to the number. The
mixed mode arithmetic was never supposed to be obvious to the green grocer
anyway...
Nobody in his right mind would ever think of attributing to Fortran the
colorful narrative as found in reference to other languages such as PCWeek
11/27/95 article on Visual C++...
" Microsoft's VisualC++4.0 can't make a silk purse
out of a sow's ear, but it does put a pretty dress
on an unwieldy pig of a language."
I rest my case.
Peter Shenkin
In article <danpop.8...@news.cern.ch>,
Dan Pop <dan...@mail.cern.ch> wrote:
>There are two kinds of portability problems:
>
>a. Those caused by the usage of vendor-specific extensions. They are
>b. Those caused by implicit assumptions about the compiler behaviour
...
>Class 'a' problems have the advantage that they're obvious when the code
>
>Class 'b' problems are the real headache at port time. The code will
>usually compile without any diagnostic, but the output of the program
....
>WRT to this discussion about portability, Fortran is neither better nor
>worse than most other languages.
Two comments. First, I recently heard someone say, "There is no
such thing as portable software; there is only software that has
been ported." I would have to respond, "And I am two and twenty,
and Oh, 'tis true, 'tis true."
Second, Fortran is indeed neither better nor worse than other
languages in this regard, but Fortran programmers seem, on the whole,
to be less cognizant than, say, C programmers of the difference between
a standard and an implementation, or even of the existence of a
standard and what it means to have a standard. It is, in my experience,
much more common for a Fortran programmer than for a C programmer to
say, "The code works on platform X (which I've been using for 20
years), but not on platform Y (which my boss insisted on buying);
therefore, something must be wrong with the compiler on platform Y
(and it serves that idiot of a boss right for listening to the
salesman)."
-P.
--
********************* (Note new snail-mail address.) **********************
* Peter S. Shenkin, Chemistry, Columbia U., 3000 Broadway, Mail Code 3153,*
** NY, NY 10027; she...@columbia.edu; (212)854-5143; FAX: 678-9039 ***
** MacroModel home page: www.cc.columbia.edu/cu/chemistry/mmod/mmod.html***
Craig C. Tierney
In article <4m4clq$a...@newsbf02.news.aol.com>, ESSoft <ess...@aol.com> wrote:
>For many reasons, here are two:
>
> y = 1/x
>
>Who wants to be bothered by extending the code volume by declaring "type"
>for x and y, much less appending the obvious with semicolons and similar
>junk... We don't find that sort of appendages in papers from Riemann,
>Hilbert and the likes - not to mention adding a period to the number.
The computer makes the distinction between integer and real. I haven't read
all of Riemann's and Hilbert's so I don't know if they dealt with properties
of integer math. Fortran is better than other languages(ie. C) because
you don't need a semi-colon?
> The
>mixed mode arithmetic was never supposed to be obvious to the green grocer
>anyway...
huh?
>
>
>Nobody in his right mind would ever think of attributing to Fortran the
>colorful narrative as found in reference to other languages such as PCWeek
>11/27/95 article on Visual C++...
>
> " Microsoft's VisualC++4.0 can't make a silk purse
> out of a sow's ear, but it does put a pretty dress
> on an unwieldy pig of a language."
>
>I rest my case.
You have rested a weak case.
Yes, C++ can generate bloated code. The above statement may be true about
Microsoft's compiler. You have never used it before though? Do you understand
VC++ and MFC, and why the above statement is true. You have argued against
the use of VC++, not C++ in general.
There have been alot more intellegent replies than this one.
And yes, I want to be bothered by having to declare the types of my operators.
You probably have never typed one of your variable names wrong, instantly
creating a new variable and wasted time trying to find out why your code
didn't work. There is a fine line between efficient and lazy.
Craig
Roger Glover
In article <BURLEY.96A...@tweedledumb.cygnus.com>, Craig Burley
<bur...@gnu.ai.mit.edu> writes:
> In article <4lr637$4...@lace.colorado.edu> tie...@Agrabah.Colorado.EDU
> (Craig C. Tierney) writes:
>
> In article <1996Apr23.1...@nb.rockwell.com>,
> Jim Glass <gl...@mrbig.rockwell.com> wrote:
[[ stuff omitted by me -- rg ]]
This is among the best layman's explanations of the argument aliasing
problem that I have ever heard. Do you mind if I steal it, Craig?
> There's simply _no way_
> to express the above semantics in C, or even C++, though I gather
> NCEG is working on these kinds of things.
I am not sure what this "NCEG" you mention means, but the ANSI/ISO
committee for C++ is addressing the problem through a class template
called "valarray." Check this URL for more details:
http://www.cygnus.com/misc/wp/draft/lib-numerics.html#lib.numarray
Since there are no optimized implementations of "valarray" yet, it is
hard to judge whether it has successfully solved the aliasing problem.
If "valarray" *does* solve the aliasing problem, that will make two OO
programming languages (Sather being the other) that allow implementations
to optimize like Fortran, by assuming that array arguments are fully
independent of each other.
On the other hand, I have yet to see an implementation of Sather that
actually *uses* the array-independence assumption in its optimization
process...
----------------------------------------------- Roger Glover
XXXX\ \ / \ /XXX \ / \ X \ /\\\ X///X /\\\ Cray Research, Inc.
/ \ / \/ /\ / \ / \X /\ X \ / \ X\ \ X DISCLAIMER HAIKU:
//X/ X\\\X //X/ X \ X X\\ / \ X/X \ X \\\ C R I ^H^H^H^H^H^HS G I may not
/ \ X///X / \/ X//XX X \ / \ X \\ X \ Share these opinions with me
/ \ X X /\\\/ X X X///X /XXX/ X///X /XXX/ This is not my fault
----------------------------------------------- http://home.cray.com/~glover
Wclodius
ess...@aol.com (ESSoft) wrote:
"For many reasons, here are two:
y = 1/x
Who wants to be bothered by extending the code volume by declaring "type"
for x and y, much less appending the obvious with semicolons and similar
junk... We don't find that sort of appendages in papers from Riemann,
Hilbert and the likes - not to mention adding a period to the number. The
mixed mode arithmetic was never supposed to be obvious to the green grocer
anyway..."
There are so many problems with this argument as a support for Fortran
that I hardly know where to begin in addressing it.
First, Fortran only lets you get by without declaring any aspect of what
is usually thought of as the type of an entity only in very limited
circumstances, i.e., scalar variables. Parameters, arrays, etc. have to
have at least part of what is best thought of as their type declared.
Even for scalars it is usually used only for the default intrinsic types
integer and real, although the IMPLICIT statement can be used to extend
this capability.
Second, implicit typing is particularly prone to typographical errors. As
a result IMPLICIT NONE became one of the most popular extensions to F77,
and one of the most popular additions in F90.
Third, useage of implicit typing restricts the first letter of identifiers
in ways that are awkward. If I want TOTAL to be an integer sum, I cannot
(normally) use implicit typing for TOTAL.
Fourth, many languages offer the capability you attribute to Fortran in a
more flexible form, e.g., essentially all Lisp descendents. A few of them
also offer that additional capability in a safer and more efficiently
compiled form, e.g., the inferred strong typing of SML. That capability
is at best an argument against some well known languages, e.g., Pascal,
Ada, C, not an argument in favor of Fortran.
William B. Clodius
Wclodius
glo...@hikimi.cray.com (Roger Glover) wrote:
"Since there are no optimized implementations of "valarray" yet, it is
hard to judge whether it has successfully solved the aliasing problem.
If "valarray" *does* solve the aliasing problem, that will make two OO
programming languages (Sather being the other) that allow implementations
to optimize like Fortran, by assuming that array arguments are fully
independent of each other."
I thought Ada also allowed such assumptions (for in out arguments), and I
wouldn't be surprised if there were other OO languages that allow such
assumptions.
William B. Clodius
Harold Stevens
In article <4m5cfl$c...@lace.colorado.edu>, tie...@Agrabah.Colorado.EDU (Craig C. Tierney) writes:
[Snip...]
|> didn't work. There is a fine line between efficient and lazy.
[Snip...]
Hardly... :) "Lazy" people demand "efficient" compilers. A person isn't
"lazy" simply because they choose a highly optimized compiler to ease a
tedious computational task. Or should we have students revisit the good
old days of handwiring patchboards driving vacuum tube circuits so they
could appreciate "efficiency" tools, including compilers? That'll teach
those "lazy" slackers. Redemption through arduous effort. :)
The original thread asserted an opinion: fortran is the preeminent tool
for scientific and engineering computation largely by dint of optimized
compiler techniques developed over *decades*. Some would deride this as
"inertia" or "complacency" but frankly who gives a hoot? When you frame
most engineering computations using less writing, less syntax, and less
runtime using vanilla fortran than C++ or Ada or whatever, what would a
"lazy" person choose? I wouldn't call that lazy; rather, intelligent. I
also call it intelligent not trying to write serial port I/O in fortran
or COBOL. That might require, say, the breathless naivety of Basic. :)
Just because a magazine opinion of C++ as "a pig of a language" is used
to bolster arguments that fortran is "better" shouldn't deter any of us
from accepting the responsiblity for *creating* the best codes from the
tools available. That's an important distinction, because it defines an
"efficient" tool as whatever is *appropriate*, and a "lazy" person just
someone choosing to avoid creativity. Not someone who has better things
to do with themselves than create a Rosetta stone engineering app using
Lisp on company time. :)
Doncha just love these language jihads? :)
Regards, Weird
(Harold Stevens)
wy...@ti.com
US (214) 952-3293
Craig Burley
In article <BURLEY.96A...@tweedledumb.cygnus.com>, Craig Burley
<bur...@gnu.ai.mit.edu> writes:
[...]
This is among the best layman's explanations of the argument aliasing
problem that I have ever heard. Do you mind if I steal it, Craig?
Not at all.
> There's simply _no way_
> to express the above semantics in C, or even C++, though I gather
> NCEG is working on these kinds of things.
I am not sure what this "NCEG" you mention means, but the ANSI/ISO
committee for C++ is addressing the problem through a class template
called "valarray." Check this URL for more details:
http://www.cygnus.com/misc/wp/draft/lib-numerics.html#lib.numarray
(Someday I'll learn to use these things called URL. I'll have to --
most standards organizations have stopped sending me copies of
their documents punched on paper tape. ;-)
Between my possible typos (NCEG == Numerical C Extensions Group?)
and out-of-date information, don't take my statement too seriously.
Perhaps all that stuff moved into the C++ field.
On the other hand, I have yet to see an implementation of Sather that
actually *uses* the array-independence assumption in its optimization
process...
Sather's is Yet Another Thing I have to look into someday. I have
quite a long list.
ESSoft
>huh?
>
Making a point is much like cracking a joke - if you need to explain it
they tend
to get lost...
By the way, would you mind saving your barn manners for your buddies,
HUH??
Sergio Gelato
In article <4m4clq$a...@newsbf02.news.aol.com>, ESSoft <ess...@aol.com> wrote:
>For many reasons, here are two:
> y = 1/x
>Who wants to be bothered by extending the code volume by declaring "type"
>for x and y, much less appending the obvious with semicolons and similar
>junk... We don't find that sort of appendages in papers from Riemann,
>Hilbert and the likes - not to mention adding a period to the number. The
>mixed mode arithmetic was never supposed to be obvious to the green grocer
>anyway...
I'd like to challenge the notion that mathematical papers don't contain
type information. This just might be true for Riemann's (I'd have to check),
but is plain false for most of the current mathematical literature.
You can't reasonably enunciate a theorem without specifying the conditions
under which it is applicable (e.g. all square complex matrices can be
diagonalised by a unitary transformation, but the same does not hold for
real matrices and orthogonal (== real unitary) transformations).
I open Abramowitz & Stegun's well-known _Handbook_ at random, and read things
such as "r, rho, theta, lambda arbitrary complex" or "(m, n positive integers)".
Sergio Gelato
In article <4m9fc8$5...@newsbf02.news.aol.com>,
The relevant passage in the Ada 95 standard is 6.2(12).
It doesn't single out "in out" formal parameters, but rather states
that _if the argument passing mechanism is not specified [by the standard]_
(that is, if one can't be sure a priori whether the object will be passed
by reference or by copy) then it is a "bounded error" to assign
to it through one access path and then read it through another path while
the first path is in place. A bounded error is defined as one in which the
set of possible outcomes is finite; in this case: "The possible consequences
are that Program_Error is raised, or the newly assigned value is read, or
some old value of the object is read." Apart from Program_Error, this matches
what one is accustomed to in Fortran.
Note that Ada also makes it tempting to write array-valued functions.
Unfortunately, the no-aliasing assumption does not apply to the result
of such a function since (unlike in Fortran) the decision about what
value is to be returned is made when the return statement is executed,
not when the result variable is assigned to. That more or less forces
copy semantics for the function result, unless the compiler has enough
information to optimize away unnecessary copies.
Roger Glover
In article <4m9fc8$5...@newsbf02.news.aol.com>, wclo...@aol.com (Wclodius) writes:
> glo...@hikimi.cray.com (Roger Glover) wrote:
>
> "Since there are no optimized implementations of "valarray" yet, it is
> hard to judge whether it has successfully solved the aliasing problem.
> If "valarray" *does* solve the aliasing problem, that will make two OO
> programming languages (Sather being the other) that allow implementations
> to optimize like Fortran, by assuming that array arguments are fully
> independent of each other."
>
> I thought Ada also allowed such assumptions (for in out arguments), and I
> wouldn't be surprised if there were other OO languages that allow such
> assumptions.
No doubt you are right. I am still not used to thinking of Ada as an
OOPL. Ada 83 is not an OOPL by most definitions, but Ada 95
definitely is, and it definitely solves the argument aliasing problem.
----------------------------------------------- Roger Glover
XXXX\ \ / \ /XXX \ / \ X \ /\\\ X///X /\\\ Cray Research, Inc.
/ \ / \/ /\ / \ / \X /\ X \ / \ X\ \ X DISCLAIMER HAIKU:
//X/ X\\\X //X/ X \ X X\\ / \ X/X \ X \\\ C R^H^H^H^H S G I may not
Roger Glover
In article <1996May7.1...@walter.cray.com>, glo...@hikimi.cray.com (Roger Glover) writes:
>
> In article <4m9fc8$5...@newsbf02.news.aol.com>, wclo...@aol.com (Wclodius) writes:
> > glo...@hikimi.cray.com (Roger Glover) wrote:
> >
> > "Since there are no optimized implementations of "valarray" yet, it is
> > hard to judge whether it has successfully solved the aliasing problem.
> > If "valarray" *does* solve the aliasing problem, that will make two OO
> > programming languages (Sather being the other) that allow implementations
> > to optimize like Fortran, by assuming that array arguments are fully
> > independent of each other."
> >
> > I thought Ada also allowed such assumptions (for in out arguments), and I
> > wouldn't be surprised if there were other OO languages that allow such
> > assumptions.
>
> No doubt you are right. I am still not used to thinking of Ada as an
> OOPL. Ada 83 is not an OOPL by most definitions, but Ada 95
> definitely is, and it definitely solves the argument aliasing problem.
It appears that my statement that William is right... may be wrong :^).
See Sergio Gelato's earlier posting on this subject (article
<4mflsr$m...@ictpsp10.ictp.trieste.it>), which quote the relevant
passage of the Ada 95 standard.