So why do we still have to use Fortran?
John Rowe
still use Fortran" flame war and I'm sorry if this is a subject that's
been done to death, I certainly haven't seen it adequately explained
although on the face of it it does sound like a "Why can't they make a
computer that does what I want" level of question. I've posted this to
a pretty horrifying list of news groups but I've narrowed the
followups.
Our codes are all written in Fortran because we believe Fortran tends
to run faster for many traditional array orientated number crunching
applications. And when your codes take several days to run and the
limiting factor to the amount of work you can do is your cpu time that
becomes very VERY significant. And don't even try the "But I think you
will find the improvements in programmer productivity will pay for the
extra cpu time taken" line; we're not fools and for people like us
it isn't true. I'm currently trying to port 64000 lines of code onto
a Cray 3D, and we poor UK academics can't afford very many of those!
Contrary to some Computer Scientists' belief, Fortran will NEVER go
away while it is still believed to be fastest.
So, I ask myself: "Why do we feel we have to use Fortran?" Why can't
people doing our type of work have a decent language that is just as
fast? From what I can see of Fortran 90 it's essentially trying to
graft C/C++ type features onto Fortran 77. IMHO if they had put a
fraction of the effort that went into f90 into defining a few
numerical extensions to C/C++ Fortran would die almost overnight. f2c
has solved the installed base problem. (If there are people out there
with as much C experience as Fortran who feel that f90 is as good as
C/C++ please tell us but answers starting "I don't know much about C
but.." are not going to add to the debate or enhance your reputation.)
Why do I think Fortran optimises some mathematical codes faster? Well:
No aliasing:
It's illegal to have two ways of referencing the same data,
eg. by passing the same array reference twice: call foo(bar,bar)
True arrays
foo(i,j,k) only needs one pointer.
The compiler can make assumptions about where data is that you
can't do with foo[k][j][i].
This makes it much easier for the compiler to optimise vector type
operations.
Fixed loops:
The number of loop iterations is calculated on entry to the loop
and the loop index is not allowed to be changed.
Some mathematically equivalent transformations allowed.
Complex numbers as standard.
The compiler doesn't need to call a routine to handle, say,
complex multiplication but can optimise it.
So we have the ironic situation that Fortran speeds things up by
putting restrictions on what the user can do but C/C++ don't allow the
user to tell the compiler things to improve execution
speed. Orthogonal restrictions!
Why haven't the major vendors got together with us customers and the
C/C++ community to agree a small set of optional extensions to C/C++
that would allow their compilers to optimise as efficiently as
Fortran? A simple a[i,j] array syntax, a fixed loop, a few in code
directives (saying this {} block has no aliases (wasn't that
discussed?), expressions involving operators of higher precedence than
&& allowed to be rearranged, etc.) built in complex (particularly
easy in C++) and we're there. And mainstream C types would never have
to see those features. People could probably live with some
restrictions on what those parts of the code could do if there are
language features that are hard to optimise.
Or are we all wrong in thinking that Fortran is still faster for our
kind of stuff? Or is it more difficult than I think it is? These
strike me as the two sensible possibilities. Or does the C community
think the numerical people only use Fortran because they're dinosaurs
or do they think that that whole area is just not worth the bother? I
can't see how any computer scientist could resist helping to kill
Fortran!
If there are no insuperable technical or political objections (!) I
would like to propose that we do get together to define the
appropriate extensions. I know it's a long shot (!!) but I reckon it's
the only hope for numerical computing. I would have thought there
would be immense attractions for vendors - they've gone to all that
trouble to produce all that hardware and all those optimisers and they
would have one less front end to support. Make the floating point
boxes - of all sizes - easier to program efficiently and you'll sell
more. Plus, it's got to be 100 times easier than solving the aliasing
problem.
Well, here's hoping :-)
John
Dr. John Rowe
Dept. Physics
Exeter University
U.K.
Mitchell R Grunes
>First the disclaimers. I'm not looking to start a "Why do people
>So, I ask myself: "Why do we feel we have to use Fortran?" Why can't
>people doing our type of work have a decent language that is just as
>fast?
>IMHO if they had put a
>fraction of the effort that went into f90 into defining a few
>numerical extensions to C/C++ Fortran would die almost overnight.
Disclaimers aside, I probably should ignore such obvious flame bate.
But some of us like Fortran. To me, Fortran is simply easier to debug
than C. Partly because of my history: I am used to making those errors
that Fortran compilers can find for me. And I have written utilities to
help me find some of those that compilers don't find. Partly because C is
much looser, and almost anything that I mistype seems to be a legitimate
C expression.
Given what I have said before, that it is frequently necessary to debug
scientific code by inspection, easy visual debugging is absolutely
necessary. (Yes, you should cross-verify on multiple compilers on
multiple machines, and you can try to put your code through test cases,
when there exist cases that are easy to compute by analytic techniques,
but in many cases, the final test is simply staring at the code,
because you cannot know what the answer SHOULD be.) I personally
consider C inherently difficult to debug by sight:
All those silly ";" marks.
The failure to end a statement by default at the end of line.
The problems if you forget to close off a comment (some C compilers
DO find nested /*'s, and C++ has a better comment construct).
No syntactically distinct enddo vs endif.
The annoying problem of associating "else" clauses right.
The fact that pre-processor processing and nesting is entirely separate
from language processing and nesting (in Fortran, this problem only
exists in the INCLUDE statement).
Perhaps most importantly, the fact that there exist many global and
pre-processor constructs that affect more than one program in a file--
e.g., if you combine many C programs into one file, and compile that
combined file, the results are often very different from compiling
them separately--not true for Fortran, except that it may run faster.
>f2c has solved the installed base problem.
f2c seems to be a rather primitive Fortran, lacking a fair number of
features.
...
>Why do I think Fortran optimises some mathematical codes faster? Well:
...
>True arrays
>
> foo(i,j,k) only needs one pointer.
>
> The compiler can make assumptions about where data is that you
> can't do with foo[k][j][i].
I too was under this mis-impression. C language foo[k,j,i] does not
involve arrays of pointers; the compiler can always choose to make
them contiguous in memory, and optimize accordingly. C isn't quite as
bad as you think.
...
>So we have the ironic situation that Fortran speeds things up by
>putting restrictions on what the user can do but C/C++ don't allow the
>user to tell the compiler things to improve execution
>speed.
Again, there are some things you can do even in C. For example, there
are standard-conforming ways to tell a C compiler that a variable, even
an array or pointer, is actually a constant. And, as with Fortran, you
can (in the case of C, carefully) combine subroutines into a single file,
so that the compiler can look at them and take advantage of various
properties.
In fact, C's systematic default pattern of passing scalars by value, and
the ability to declare all sorts of properties of functions, can sometimes
give it an advantage. Also, you should note that Fortran still lacks
unsigned integer arithmetic, and most importantly for scientific purposes,
in which data must come from many sources, Fortran fails to have a
standardized file format on raw unformatted I/O.
(If you were looking for other numeric advantages of Fortran, you might
have mentioned its more extensive mathematical and scientific function
libraries, both intrinsic and externally available.)
My own opinion now is that the relative efficiencies of the two languages
may have more to do with the particular compiler implementations, than
with the languages themselves. Preferences for one language over the
other can mostly be simply that. In your particular case, since you
prefer C, maybe you should encourage Cray to improve C in the manners
you need. If you gave them fairly carefully written suggestions (such
as optimizing certain loops of array operations, recognizing that a peice
of code does not modify the loop index, including declarations of
variable non-aliasing, etc.), they might take heed. Or write a compiler of
your own!--"it is better to light one candle, than to curse the darkness."
-------------------------------------------------------------------------
(opinions expressed are mine alone)
Mitchell R Grunes (gru...@nrlvax.nrl.navy.mil)
Allied-Signal Tech. Serv. / Naval Research Lab
Edward Luke
Disclaimers aside, I probably should ignore such obvious flame bate.
But some of us like Fortran. To me, Fortran is simply easier to debug
than C. Partly because of my history: I am used to making those errors
that Fortran compilers can find for me. And I have written utilities to
help me find some of those that compilers don't find. Partly because C is
much looser, and almost anything that I mistype seems to be a legitimate
C expression.
I find this observation a bit suprising since I would say just the
same for Fortran. Its combination of implicit typing with lines being
silently truncated at 72 characters can easily lead to well
intentioned code that compiles fine but doesn't work quite as
expected.
I suspect you have had a few bad experiences with a K&R C compiler and
doing things like forgetting to include math.h. Many of the silent
errors that you could have committed in K&R C are reported in ANSI C
and even more so in C++. (Eg. Forgetting to include math.h will cause
errors in ANSI C and C++)
Given what I have said before, that it is frequently necessary to debug
scientific code by inspection, easy visual debugging is absolutely
necessary.
There is nothing unique about scientific code that requires this type
of debugging. Try making sure OS code is hacker proof! Same
difference. In every domain there are bugs that are not found in the
standard test sweep, Intel ought to know this one ;-D. But at any
rate, I've worked with quite a few Scientific Fortran codes and have
found plenty of errors that have been silently lying there for years.
Some of them were not found simply because Fortran is so *loose* about
types, e.g. implicit typing is evil. But at any rate, visual
debugging comes down to coding style and what you're used to seeing.
There isn't anything intrinsic about C that makes this any less an
effective approach.
>f2c has solved the installed base problem.
f2c seems to be a rather primitive Fortran, lacking a fair number of
features.
Those features are also not in the Fortran 77 standard. Cest la vie.
...
>Why do I think Fortran optimises some mathematical codes faster? Well:
...
>True arrays
>
> foo(i,j,k) only needs one pointer.
>
> The compiler can make assumptions about where data is that you
> can't do with foo[k][j][i].
I too was under this mis-impression. C language foo[k,j,i] does not
involve arrays of pointers; the compiler can always choose to make
them contiguous in memory, and optimize accordingly. C isn't quite as
bad as you think.
While it is true that C supports three dimensional arrays, it is
difficult, and not pretty, to pass multidimensional arrays with
run-time specified array bounds without using the array of arrays
technique. This is a significant drawback of C if you are used to
programming in an array based paradigm.
--
On the topic of speed, I have not yet found a case where I couldn't
write C code that was just as fast as any Fortran Code. This is
particularly true on the VLIW super-scalar architectures that are
popular nowdays. It is true, however, that often a different way of
thinking about solving the problem is required to effectively use C,
... or Fortran for that matter.
At any rate, I would rather Fortran programmers write Fortran programs
then write Fortran paradigm programs in C [Fortran-C code Blech].
And of course, in 20 years scientists and engineers will still write
Fortran code, it may not be Fortran 77, but it'll damn sure be
*called* Fortran.
- Ed Luke
--
Mail: segmentation violation -- core dumped
Arne Vajhoej
> In article <grunes.125...@news.nrl.navy.mil> gru...@news.nrl.navy.mil (Mitchell R Grunes) writes:
> I find this observation a bit suprising since I would say just the
> same for Fortran. Its combination of implicit typing with lines being
> silently truncated at 72 characters can easily lead to well
> intentioned code that compiles fine but doesn't work quite as
> expected.
Modern FORTRAN compilers has witches to give warnings on such mistakes.
> I suspect you have had a few bad experiences with a K&R C compiler and
> doing things like forgetting to include math.h. Many of the silent
> errors that you could have committed in K&R C are reported in ANSI C
> and even more so in C++. (Eg. Forgetting to include math.h will cause
> errors in ANSI C and C++)
????
I agree on C++ , but are yoiu sure about ANSI C ?
I have a C compiler claiming ANSI compatibility, which only gives a
warning about the problem, but it do compile th code.
> On the topic of speed, I have not yet found a case where I couldn't
> write C code that was just as fast as any Fortran Code. This is
> particularly true on the VLIW super-scalar architectures that are
> popular nowdays.
VLIW ?
As far as I recall the only VLIW computer being shipped commercial was
Multiflow Trace !
Arne
Arne Vajhøj local DECNET: KO::ARNE
Computer Department PSI: PSI%238310013040::ARNE
Southern Denmark Business School Internet: AR...@KO.HHS.DK
WWW URL: http://www.hhs.dk/~arne/arne.html
Mark Hittinger
was a letter to the editor that went something like this:
"Basic and Fortran are not similar! Basic is just a notch above RPG whereas
Fortran is the time tested language of wisdom. C is the bandwagon language
of hype - well suited to greenhorns."
My former boss accused me of writing the letter under a psuedonym. I had
to admit that I did rather feel Fortran was the time tested language of
wisdom but of course I didn't write the letter.
Now since I left my VAXen behind Fortran dims in the haze of daily C. Then
I saw G77 get put up for beta. OHBOY! 95 is turning into such a good year
- FreeBSD and G77.
Cheers :-)
Mark Hittinger
bu...@win.net
Edward Luke
In article <LUSH.95Fe...@athena.ERC.MsState.Edu>, lu...@athena.ERC.MsState.Edu (Edward Luke) writes:
> In article <grunes.125...@news.nrl.navy.mil> gru...@news.nrl.navy.mil (Mitchell R Grunes) writes:
> I find this observation a bit suprising since I would say just the
> same for Fortran. Its combination of implicit typing with lines being
> silently truncated at 72 characters can easily lead to well
> intentioned code that compiles fine but doesn't work quite as
> expected.
Modern FORTRAN compilers has witches to give warnings on such mistakes.
True, but this is not the default behavior of the compiler, and most
Fortran programmers seem not to use these switches. Every major
Fortran program that I have delt with has used implicit typing,
preventing me from getting anything useful from those switches. And
going back to change >100k lines of Fortran code isn't the answer
because 1) It's time consuming. 2) If you automated the process the
you would never catch the old implicit typing errors. 3) If you did
change the code in this way, the original application developers would
rebel against the change.
> I suspect you have had a few bad experiences with a K&R C compiler and
> doing things like forgetting to include math.h. Many of the silent
> errors that you could have committed in K&R C are reported in ANSI C
> and even more so in C++. (Eg. Forgetting to include math.h will cause
> errors in ANSI C and C++)
????
I agree on C++ , but are yoiu sure about ANSI C ?
I have a C compiler claiming ANSI compatibility, which only gives a
warning about the problem, but it do compile th code.
Semantic difference, end result is the same. You get an error under C++,
a warning under ANSI C, in either case you are informed of the error
you committed.
> On the topic of speed, I have not yet found a case where I couldn't
> write C code that was just as fast as any Fortran Code. This is
> particularly true on the VLIW super-scalar architectures that are
> popular nowdays.
VLIW ?
As far as I recall the only VLIW computer being shipped commercial was
Multiflow Trace !
Perhaps a semantic difference. I view any architecture that has a >64
bit on-chip bus that launches multiple instructions in a single clock
cycle to be a form of VLIW technology. (It is easy to view it in this
light if you consider the multiple instructions launched as one super
instruction.)
- Ed
Rick Castrapel
reason for the continued existence of fortran elsewhere in this thread.
The Reason:
There is a HUGE legacy of fortran programs out there.
I am no longer a fortran bigot. (I can write stream-of-consciousness fortran
that works - but I'm not quite there with C yet). However, I have ported,
prodded, cursed, many millions of lines of other peoples fortran programs.
A couple of examples may help illustrate my point:
PDQ7 is a thirtysomething fortran program of a couple hundred thousand
lines. It performs Nuclear Fuel Cycle Analysis; ie: engineers use this code
to decide how and when to replace, move, etc. fuel rods in nuclear reactors.
This is a very serious and solemn position for a computer program to be in.
The blessing to use this program from the NRC requires a very strict quality
assurance regimen (several man-years) for any given compiler, OS, hardware.
GAUSSIAN nn (nn is an even-numbered year) is a suite of around 80 fortran
programs comprised of well over half a million lines of code. GAUSSIAN
performs quantum chemistry calculations. It is also thirtysomething. Many
of the greatest minds in quantum physics and computational chemistry have
contributed to GAUSSIAN. Nobel prize winners have contributed. It would
trivialize this great effort to say that the output from GAUSSIAN is a single
number (the molecular energy) - it can do much more - but the calculated
energy is significant to eleven or so decimal places.
I think both of these examples show that some fortran programs have had to
earn their place. The trust given their results has come from many years of
successful use. These examples also show how delicate scientific and
engineering programs can be - any non-trivial program has quirks, bugs, etc.
But a program that must be accurate to .0000000001 after running for days, or
a program that requires man-years of effort to certify as trustworthy, is
definitely not a candidate for a Sunday afternoon romp through f2c.
PDQ7 and GAUSSIAN are but two small examples dwarfed by the millions of lines
of fortran and thousands of man-years that are in our pool of scientific and
engineering programs. This legacy won't be disgarded any time soon.
Rick Castrapel
(These days all of my work is in C. Maybe I'll actually have to learn it.)
D'Arcy J.M. Cain
: Modern FORTRAN compilers has witches to give warnings on such mistakes.
Whoa!!! Now there's an incentive to write correct code!
:-)
--
D'Arcy J.M. Cain (da...@druid.com) | Democracy is three wolves and a
Planix, Inc., Toronto, Canada | sheep voting on what's for dinner.
+1 416 424 2871 (DoD#0082) (eNTP) |
-- Info on Planix can be found at http://www.planix.com --
Nick Maclaren
|>
|> >Why do I think Fortran optimises some mathematical codes faster? Well:
|> ...
|> >True arrays
|> >
|> > foo(i,j,k) only needs one pointer.
|> >
|> > The compiler can make assumptions about where data is that you
|> > can't do with foo[k][j][i].
|>
|> I too was under this mis-impression. C language foo[k,j,i] does not
|> involve arrays of pointers; the compiler can always choose to make
|> them contiguous in memory, and optimize accordingly. C isn't quite as
|> bad as you think.
I am afraid that you are under a serious misapprehension. foo[k][j][i]
NEVER uses more than one pointer in C (the language forbids it to).
The problem is that you cannot pass multi-dimensional arrays in a
half-way sensible fashion. Inter alia, the C compiler cannot tell
whether any of its array arguments are aliased to any others (or to
any external array) - and this applies even if the arrays are of
different types :-(
|> Again, there are some things you can do even in C. For example, there
|> are standard-conforming ways to tell a C compiler that a variable, even
|> an array or pointer, is actually a constant. And, as with Fortran, you
|> can (in the case of C, carefully) combine subroutines into a single file,
|> so that the compiler can look at them and take advantage of various
|> properties.
I am afraid that this isn't true, either. There is no way to tell
the compiler that a variable is really a constant, and doing so for
arrays is fraught with problems. The const qualifier does provide
a little extra checking, but is very dubiously helpful to the compiler.
|> In fact, C's systematic default pattern of passing scalars by value, and
|> the ability to declare all sorts of properties of functions, can sometimes
|> give it an advantage. Also, you should note that Fortran still lacks
|> unsigned integer arithmetic, and most importantly for scientific purposes,
|> in which data must come from many sources, Fortran fails to have a
|> standardized file format on raw unformatted I/O.
This is definitely unfair to Fortran! On systems with record-based
I/O, exactly the converse is true .... Just because UNIX-like
systems (including MS-DOS etc.) are taking over the world, don't
think that it was always like that!
Nick Maclaren,
University of Cambridge Computer Laboratory,
New Museums Site, Pembroke Street, Cambridge CB2 3QG, England.
Email: nm...@cam.ac.uk
Tel.: +44 1223 334761 Fax: +44 1223 334679
Warren J. Paul
writes:
>
>I have to add my $0.02 since I didn't see what IMHO is the most
compelling
>reason for the continued existence of fortran elsewhere in this thread.
>
>The Reason:
>
> There is a HUGE legacy of fortran programs out there.
>
Sap-IV, written in 1972 is still used to design structures, and it
includes quite sophisticated methods for earthquake analysis. Most
other structural programs developed from Sap-IV. Those that did not
developed from Stress/Strudl, which originated at the same time, or from
Ansys, ditto or Nastran, ditto. This covers about 99% of structural
analysis program history. Behind everything of steel or concrete that
has been designed since that time is one of these programs or a
derivative. --- Warren
Craig T. Dedo
>From: lu...@athena.ERC.MsState.Edu (Edward Luke)
>Subject: Re: So why do we still have to use Fortran?
>Date: 16 Feb 1995 01:11:34 GMT
[Author's note: some fans of C will fnd the more interesting comments at the
end.]
>I find this observation a bit suprising since I would say just the
>same for Fortran. Its combination of implicit typing with lines being
>silently truncated at 72 characters can easily lead to well
>intentioned code that compiles fine but doesn't work quite as
>expected.
Fortran 90 supports free format source code. With free format
source code, there are no reserved fields. You can start a statement
anywhere on a line and lines can be up to 132 characters in length.
>I suspect you have had a few bad experiences with a K&R C compiler and
>doing things like forgetting to include math.h. Many of the silent
>errors that you could have committed in K&R C are reported in ANSI C
>and even more so in C++. (Eg. Forgetting to include math.h will cause
>errors in ANSI C and C++)
One VERY nice thing about Fortran (especially compared to C) is that you
do NOT have to memorize a long list of *.h files in order to get real work
done. ALL features of the language are automatically included. No problems
with calling an intrinsic function only to find out that you need to include a
certain definition. This saves a LOT of human effort and prevents a lot of
mistakes.
>Some of them were not found simply because Fortran is so *loose* about
>types, e.g. implicit typing is evil. But at any rate, visual
>debugging comes down to coding style and what you're used to seeing.
>There isn't anything intrinsic about C that makes this any less an
>effective approach.
ONLY with the (soon-to-be) defunct F77 standard. F90 supports
IMPLICIT NONE. I use it ALL of the time. More importantly, F90 supports
interface blocks on subroutine and function calls, and modules. BOTH of these
features should provide for much more robust programming.
>Those features are also not in the Fortran 77 standard. Cest la vie.
F90 is the ONLY International Standard. Even in America, F77 is on the
way out. ANSI is currently in the process of withdrawing the F77 standard.
>While it is true that C supports three dimensional arrays, it is
>difficult, and not pretty, to pass multidimensional arrays with
>run-time specified array bounds without using the array of arrays
>technique. This is a significant drawback of C if you are used to
>programming in an array based paradigm.
F90 supports many different paradigms. It even has pointers, so you can
construct dynamic linked structures if you want. It has structured data types
so you can create complex data structures.
One of the things that really bothers me about C is it is VERY MUCH
pointer oriented. You cannot do ANYTHING useful without messing with pointers
A LOT! Pointers are an inherently complex concept and ALWAYS introduce
additional (and unnecessary) complexities into the programming process.
In C, you even have to use pointers to do such conceptually simple things
as reading and writing a file. In fortran, file I/O is MUCH easier.
>On the topic of speed, I have not yet found a case where I couldn't
>write C code that was just as fast as any Fortran Code. This is
>particularly true on the VLIW super-scalar architectures that are
>popular nowdays. It is true, however, that often a different way of
>thinking about solving the problem is required to effectively use C,
>... or Fortran for that matter.
With today's sophisticateed compiler technology, I believe that speed and
efficiency are much more the result of how carefully compilers are designed
rather than the inherent characteristics of the language.
>At any rate, I would rather Fortran programmers write Fortran programs
>then write Fortran paradigm programs in C [Fortran-C code Blech].
So do I. And I would like C to go back to its originally intended purpose
- as a low-level systems programming language. Such things as device drivers,
operating systems kernels, and the like.
C is NOT a one-size-fits-all solution to all programming problems or the
greatest thing since sliced bread, even though many C language fans have
propagandized that idea in the last 10 years (and have been very successful in
doing so).
Those who think C is the greatest programming language ever should read "C
in Education and software Engineering", by R. P. Mody, SIGSE Bulletin 23, no.
3 (September 1991): 45-56. It is an excellent critique of the conceptual gaps
in C, which even trip up the experienced C programmer.
I would like fortran to take its rightful place as second to none as a
general purpose applications development language, especially in creating
windowed applications (any windowing system, not just MS-Windows). Fortran
should NOT be restricted only to high-powered numeric computation, although it
is admirably suited to such applications.
I would like both the Fortran and C fans to work together to create
GENUINE interoperability, so that mixed-language programming can be more than
just a talked-about fantasy, or only restricted to a few well-designed systems.
Finally, I would like those legions of systems programmers, who do most of
their work in C, to design their OS subsystems (e.g., MS-Windows library
calls) to be Fortran friendly. A fortran programmer should not have to go
through intense gyrations just in order to access powerful OS subsystems.
>And of course, in 20 years scientists and engineers will still write
>Fortran code, it may not be Fortran 77, but it'll damn sure be
>*called* Fortran.
Long live Fortran! May it be the premier programming language for the
next 1000 years!
Sincerely,
Craig T. Dedo Voice Phone: (414) 783-5869
Elmbrook Computer Services Internet: Craig...@mixcom.com
17130 W. Burleigh Place
Brookfield, WI 53005 Disclaimer: Any ideas or opinions are mine alone.
USA They do NOT represent any organization.
"Those who would sacrifice their Liberty for a little temporary Safety deserve
neither Liberty nor Safety." -- Benjamin Franklin
Will Morse
Comparing C and Fortran is a little like comparing a screwdriver
and a chisel. They have some superficial similarities, but they
are really different tools.
C should more properly be compared to various assembler languages.
It is intended for system level stuff and places where you have to
get at things that "high level languages" don't normally get to.
Fortran should be compared to "high level languages". The current
crop is better called "very high level languages" and includes
perl, tcl, python, scheme, and quite a few others. Most of these
languages are extremely platform independent and are free.
Will
--
# Gravity, # Will Morse
# not just a good idea, # BHP Petroleum (Americas) Inc.
# it's the law. # Houston, Texas
# # wi...@starbase.neosoft.com
#
# These are my views and do not necessarly reflect the views of BHP !
The Wankmiester
>
>
>Comparing C and Fortran is a little like comparing a screwdriver
>and a chisel. They have some superficial similarities, but they
>are really different tools.
>
Comparing Fortran and C is like comparing an aging poor quality
screw-driver with an all-in one tool (that can also perform that
aging screw-drivers job faster, easier, and more reliably in
addition to numerous other tasks).
>C should more properly be compared to various assembler languages.
>It is intended for system level stuff and places where you have to
>get at things that "high level languages" don't normally get to.
>
Actually C should be compared with assembler AND other high
level languages. C provides all the power that high level
languages offer (if not more) plus the functionality of assembler.
>Fortran should be compared to "high level languages". The current
>crop is better called "very high level languages" and includes
>perl, tcl, python, scheme, and quite a few others. Most of these
>languages are extremely platform independent and are free.
>
Fortran is not even a real high level language. Desinging software
in fortran is a difficult prospect at best. Fortran is a
language that is high level in construct, and low-level in
simplicity. I personally think Fortran is an insult to all
thinking computer programmers.
>Will
>--
Sincerely,
Thomas J. Wank
Peter da Silva
patches on what was originally a decent scientific programming language. C++
is overly complex and excessively terse, the result of decades of patches on
what was originally a fine systems programming language. Neither of them should
be considered the language of the future.
On the other hand, ADA doesn't fill me with warm fuzzies... it's as complex as
C++ and as clumsy as Fortran. I really wish the GNU people would put a bit of
effort into a decent quality Modula.
In the meantime I'll stick with C only because it's still the only language
powerful enough to cover most problems and simple enough to be widely
implemented. Sigh.
--
Peter da Silva `-_-'
Network Management Technology Incorporated 'U`
1601 Industrial Blvd. Sugar Land, TX 77478 USA
+1 713 274 5180 "Hast du Heute schon deinen Wolf umarmt?"
Richard E. Hodges
>In article <3igiad$f...@Starbase.NeoSoft.COM>, wi...@Starbase.NeoSoft.COM (Will Morse) says:
>>
>>
>>Comparing C and Fortran is a little like comparing a screwdriver
>>and a chisel. They have some superficial similarities, but they
>>are really different tools.
>>
>
>Comparing Fortran and C is like comparing an aging poor quality
>screw-driver with an all-in one tool (that can also perform that
>aging screw-drivers job faster, easier, and more reliably in
>addition to numerous other tasks).
I would be interested if you could show the equivalent ANSI standard
C program equivalent of the following simple program:
program test
complex aj, sum, x(10), b(10), A(10,10)
aj = cmplx(0.,1.)
do 10 i=1,10
do 10 j=1,10
10 A(i,j) = cmplx(aj*abs(i-j))
do 20 i=1,10
20 x(i) = ccos(cmplx(real(i),real(j)))
do 30 i=1,10
sum = cmplx(0.,0.)
do 40 j=1,10
40 sum = sum + A(i,j)*x(j)
30 b(i) = sum
do 50 i=1,10
50 write(*,*) b(i)
stop
end
OUTPUT:
(88510.2,-292106.)
(96645.7,-217322.)
(159225.,-167454.)
(230253.,-176861.)
(255968.,-225404.)
(224269.,-256963.)
(175840.,-231033.)
(166747.,-159964.)
(216892.,-97606.5)
(291711.,-89802.1)
[deleted text]
>Fortran is not even a real high level language. Desinging software
>in fortran is a difficult prospect at best. Fortran is a
>language that is high level in construct, and low-level in
>simplicity. I personally think Fortran is an insult to all
>thinking computer programmers.
A few years ago I viewed a seminar at JPL in which the presenter,
a person with a similarly arrogant attitude, proposed to show the
superiority of C over Fortran. She began with a simple matrix
multiply. Maybe 10 lines of Fortran code. It was demonstrated that
on a vector processing computer a simple loop unrolling exercise
would give a certain amount of increase in execution speed.
Then a similarly constructed C routine was tested. It lagged quite
significantly behind the Fortran code. But, never fear, we were told,
it can be made to run faster in C. After an number of enhancements
involving pointers and a number of machine-specific adjustments
she wound up with a five times more lines of code -- utterly
indecipherable as to what the actual function being performed might
be by the time it was all done. Net result, it ran a bit faster --
maybe 10-15%. Was it worth the trouble?
Richard Hodges
William B. Clodius
wrote:
>[deleted]
>
>Has FORTRAN 90 changed so much from what I remember, or is this a troll?
>FORTRAN always struck me as a first (second, I guess, after LISP) attempt
>at a "high-level" language, whatever that might mean.
>
>[deleted]
>
Fortran is commonly considered the first, implemented, "high-level" language
to generate reasonably efficient object code, about 1957?. It was certainly
the first to be implemented on a variety of machines. The first version of
Algol appeared about 58, but was apparently very different from Algol 60.
The first attempt at LISP, FLISP, was written in Fortran around 1960. Other
languages intermediate in capability between assembler and Fortran were in
use before Fortran, some of which might under some definitions be considered
high level, although most of those that approached high level apparently did
not generate efficient object code. A few languages are sometimes mentioned
as possibly approaching Fortran's capabilities and in use before Fortran,
but were apparently only used at single sites and their capabilities are not
well documented.
The first designed "high-level' language, Plankalkul?, was written about
1945, in Germany, but the machine that inspired it was no longer operable
for what should be obvious reasons. It is unsusal in that it had record
types (i.e., structures or user defined types) but everything was defined in
terms of bits. I don't believe Plankalkul was ever fully implemented,
although the "Retrocomputing"? museum hopes to develop an implementation.
Portions of Fortran do show their age, but a bigger problem in its
reputation is the amount of heritage code and coders who do not take proper
advantage of its newer capabilities. Fortran 90 is a significant improvement
on F77 and discussions of Fortran's capabilities, or lack thereof, should at
least reflect familiarity with the only international standard. For those
who complain about the size of Fortran 9x I have some sympathy, eliminating
25% of the language would yield a more efficient and more elegant language
(at the cost of upwards compatibility), but I suggest that they look at the
size of the C++, Ada 9x, and CLOS standards to gain a perspective.
Similarly there are aspects of C, e.g., operators with side effects such as
++, and a large reliance on pointers for certain types of array operations,
that can make some scientific code more difficult to understand or optimize,
but those need not affect the legibility of well written scientific C code,
and a knowledgeable programmer can greatly reduce the impact of pointers on
code efficiency.
Could we try to limit the spread of this thread. It is being posted at too
many news groups. I have reduced my posting to Fortan, C, and C++, as they
are the only ones I consider likely to be interested in language questions.
It is probably best to end this flame thread entirely, as, typically, it
generates a lot of heat and smoke, but little light.
Todd Lee Henderson
> OUTPUT:
>Ok, here is the equivalent C++ code:
>#include <stream.h>
>#include <complex.h>
>main()
>{
> Complex aj(0,1), sum, A[10][10], x[10], b[10] ;
> int i,j ;
>
> for(i=0;i<10;i++)
> for(j=0;j<10;j++)
> A[i][j] = Complex(aj*abs(i-j)) ;
>
> for(i=0;i<10;i++)
> x[i] = cos(Complex(i+1,j+1)) ;
>
> for(i=0;i<10;i++) {
> sum = 0 ;
> for(j=0;j<10;j++)
> sum = sum + A[i][j]*x[j] ;
> b[i] = sum ;
> }
>
> for(i=0;i<10;i++)
> cout << b[i] << "\n" ;
>}
>Output:
>ike% !g++
>g++ c.cc -lm
>ike% a.out
>(88510.2, -292106)
>(96645.7, -217322)
>(159225, -167454)
>(230253, -176861)
>(255968, -225404)
>(224269, -256963)
>(175840, -231033)
>(166747, -159964)
>(216892, -97606.5)
>(291711, -89802.1)
>It looks to be just as simple as the fortran code. Hmmm...
I would much rather read the fortran code, but then again, I've only
done limited C programming.
By the way, why does everyone hate the implicit variable names in
fortran? That's what I hated about C, the fact that every stinking
variable had to be declared, if you wanted to use i for a loop, it had
to be declared right? What a waste of time while you're trying to write...
Just my 2 cents work.
I do like this disccussion, it is interesting.
>- Ed Luke
Dan Pop
>Craig T. Dedo (cd...@uwcmail.uwc.edu) wrote:
>
>> I would like fortran to take its rightful place as second to none as a
>> general purpose applications development language, especially in creating
>> windowed applications (any windowing system, not just MS-Windows). Fortran
>> should NOT be restricted only to high-powered numeric computation, although it
>> is admirably suited to such applications.
>
>Has FORTRAN 90 changed so much from what I remember, or is this a troll?
Minor nit: the name has changed, it's Fortran, not FORTRAN. Before
concluding anything about my mental sanity :-) read this quote from the F90
standard (ISO/IEC 1539:1991):
Note that the name of this language, Fortran, differs from that in
FORTRAN 77 in that only the first letter is capitalized. Both FORTRAN
77 and FORTRAN 66 used only capital letters in the official name of the
language, but Fortran 90 does not continue this tradition.
>FORTRAN always struck me as a first (second, I guess, after LISP) attempt
>at a "high-level" language, whatever that might mean.
It is the first attempt at a high level language, indeed. But it changed
a bit during its 40 years of existence. A piece of F90 code is
incomprehensible even for a F77 programmer (but F77 code is still valid
F90 code).
Dan
--
Dan Pop
CERN, CN Division
Email: dan...@cernapo.cern.ch
Mail: CERN - PPE, Bat. 31 R-004, CH-1211 Geneve 23, Switzerland
Steve Lionel
In article <3ij2on$m...@masala.cc.uh.edu>, Wan...@Umass.Edu
(The Wankmiester) writes:
|>Actually C should be compared with assembler AND other high
|>level languages. C provides all the power that high level
|>languages offer (if not more) plus the functionality of assembler.
Ah, yes. This is a variation of the old joke "C provides all the power
of assembler with all of the ease of use and maintainability features of
assembler." The comparison of C with assembler is more apt than you realize.
--
Steve Lionel Mail: lio...@quark.enet.dec.com
DEC Fortran Development WWW: http://www.digital.com/info/slionel.html
Digital Equipment Corporation CompuServe: 75263,3001
110 Spit Brook Road, ZKO2-3/N30
Nashua, NH 03062-2698 "Free advice is worth every cent"
For a summary of Digital's Internet services, send mail to in...@digital.com
Pete Clinch
I hate Fortran. I usually refer to it as "the F-Language" and avoid it
whenever possible.
I take exception to the comments about C being harder to read than
Fortran, as I just don't find it to be the case (*what* trouble with the
else statement???).
But there's no way you can stamp it out by numerical additions to C!
Apart from the existing code (you think F77 is bad, try COBOL...) which
needs compilers, there is the fact that Fortran is usually easier to
optimise than C/C++, or indeed other more modern languages. Take, for
instance, the way the latest Sun f77 compiler will automatically
parallelise code for multi-processor systems, but the same company's C
and C++ compilers won't...
A lot of this is to do with the language being simpler in many ways, but
there are plenty of occaisions where this is a bonus. If you're doing
*big* number crunches on reasonably simple data sets (usually enormous
multidimensional arrays, that won't benefit a great deal from being made
into Objects), there is little reason to use anything else, because in
the end the program will only take 1 night to run, instead of two nights
and a working day...
Every dog has its day, and Fortran will (quite justifiably) be having its
day where it works best for a long time to come. I do wish though, that
some people in physical sciences would stop using it for *everything*
just because they always have in the past. It might mean learning
something else, but if the argument had that much merit, they'd still be
using PDP-8s...
Pete.
--
Peter Clinch Dundee Teaching Hospitals NHS Trust
voice: 44 1382 660111 x 3637 snail: Directorate of Medical Physics
fax: 44 1382 640177 Ninewells Hospital
email: p.j.c...@dundee.ac.uk Dundee DD1 9SY Scotland UK
OMG
>In article <D4I0G...@seas.ucla.edu> hod...@breeze.seas.ucla.edu (Richard E. Hodges) writes:
>
> C program equivalent of the following simple program:
>Ok, here is the equivalent C++ code:
>It looks to be just as simple as the fortran code. Hmmm...
>
Yeh, but the request was for ANSI `C' code, not C++.
It is just a case of what you are used to. I programmed in Fortran
for 15 years (including on PDP 8's which another poster derided).
I have programmed in ANSI `C' for about 3 years. I prefer C, but
then I know what I am doing. For a novice or occasional user I can
see that the extra support Fortran gives would be important. As for
complex data types, well I have added such a types to ANSI `C', so
it can be done. It is just not easy.
I am puzzled why this language war is going on. You should use the
language which is most appropriate to the problem that you are
attempting to solve. This might be C, C++, Fortran, or Cobol. It's
horses for courses. If you have programmed in only one language,
then how can you know what is best. If you have programmed in many,
then you know that there is no "best".
Regards,
Martin
MLe...@atlantic.cs.unb.ca
Peter Brewer
Steve Lionel <lio...@quark.enet.dec.com> wrote:
>
>In article <3ij2on$m...@masala.cc.uh.edu>, Wan...@Umass.Edu
> (The Wankmiester) writes:
>
>|>Actually C should be compared with assembler AND other high
>|>level languages. C provides all the power that high level
>|>languages offer (if not more) plus the functionality of assembler.
>
>Ah, yes. This is a variation of the old joke "C provides all the power
>of assembler with all of the ease of use and maintainability features of
>assembler." The comparison of C with assembler is more apt than you realize.
>--
>
bare metal; thus it generated highly optimized code.
-- peter brewer
Scott Bayes
> >From: lu...@athena.ERC.MsState.Edu (Edward Luke)
> >Subject: Re: So why do we still have to use Fortran?
> >Date: 16 Feb 1995 01:11:34 GMT
[deleted]
I had no trouble till I got to the following statement:
> I would like fortran to take its rightful place as second to none as a
> general purpose applications development language, especially in creating
> windowed applications (any windowing system, not just MS-Windows). Fortran
> should NOT be restricted only to high-powered numeric computation, although it
> is admirably suited to such applications.
Has FORTRAN 90 changed so much from what I remember, or is this a troll?
FORTRAN always struck me as a first (second, I guess, after LISP) attempt
at a "high-level" language, whatever that might mean.
[deleted]
> Long live Fortran! May it be the premier programming language for the
> next 1000 years!
:-), right? ! ?? !!!
--
Scott Bayes
Hewlett-Packard Company
VXD, Loveland CO
ba...@hpisla.lvld.hp.com
(303) 679-3799
All opinions are my own and do not reflect an official position of HP.
A man, a plan, a canal. Suez.
Edward Luke
OUTPUT:
Ok, here is the equivalent C++ code:
#include <stream.h>
#include <complex.h>
It looks to be just as simple as the fortran code. Hmmm...
- Ed Luke
--
Richard E. Hodges
Earlier I posted a request to see the C language equivalent of the
following simple program, which I cooked up on a lark late at night.
Upon re-reading it I realize it was actually too trivial to be
of any use.
> I would be interested if you could show the equivalent ANSI standard
> C program equivalent of the following simple program:
>
> program test
> complex aj, sum, x(10), b(10), A(10,10)
> aj = cmplx(0.,1.)
> do 10 i=1,10
> do 10 j=1,10
> 10 A(i,j) = cmplx(aj*abs(i-j))
> do 20 i=1,10
> 20 x(i) = ccos(cmplx(real(i),real(j)))
> do 30 i=1,10
> sum = cmplx(0.,0.)
> do 40 j=1,10
> 40 sum = sum + A(i,j)*x(j)
> 30 b(i) = sum
> do 50 i=1,10
> 50 write(*,*) b(i)
> stop
> end
>
Instead of the above, I would prefer to see the C equivalent of
the following. It is more representative of the kind of real world
functions a typical scientific programmer uses.
program test
complex aj, sum, x(10), b(10), A(10,10)
aj = cmplx(0.,1.)
pi = 4.0 * atan(1.0)
do 10 i=1,10
do 10 j=1,10
x(i) = ccos(cmplx(real(i),real(j)))
10 A(i,j) = cexp(aj*(abs(pi*i-j)**2.5))
do 30 i=1,10
sum = cmplx(0.,0.)
do 40 j=1,10
40 sum = sum + A(i,j)*x(j)
30 b(i) = sum
do 50 i=1,10
50 write(*,*) b(i)
stop
end
OUTPUT:
(21524.4,-16084.3)
(-20589.7,-22261.3)
(-41398.8,10069.5)
(-45209.0,11180.4)
(39456.3,-12680.4)
(1797.06,-5101.89)
(-9297.79,-4254.67)
(28928.8,22867.9)
(5776.97,15084.2)
(6501.25,-10585.3)
Richard Hodges
Ira A. Agins
>It is the first attempt at a high level language, indeed. But it changed
>a bit during its 40 years of existence. A piece of F90 code is
>incomprehensible even for a F77 programmer (but F77 code is still valid
>F90 code).
As they say around here, in 20 years we don't know what language we'll be
working in, but it will be called Fortran.
Ira A. Agins
Los Alamos National Laboratory
Ruth Milner
Pete Clinch <pjcl...@dux.dundee.ac.uk> wrote:
>I do wish though, that
>some people in physical sciences would stop using it for *everything*
>just because they always have in the past.
>[...] if the argument had that much merit, they'd still be
>using PDP-8s...
Um ... but some people still *are* using PDP-8's. No, not us (though we do
have a couple of PDP-11's lying around :-) ), but I know a few places that
do. Usually for a reason that can be rationalized, like to support some
piece of equally old hardware that nothing else will handle and that you
can't afford to replace with something modern, and why bother anyway since
it does what you want and never breaks? :-)
--
Ruth Milner NRAO Socorro NM
Manager of Computing Systems rmi...@aoc.nrao.edu
Ruth Milner
The Wankmiester <Wan...@Umass.Edu> wrote:
>>
>Comparing Fortran and C is like comparing an aging poor quality
>screw-driver with an all-in one tool (that can also perform that
>aging screw-drivers job faster, easier, and more reliably in
>addition to numerous other tasks).
Ah, I wondered how long it would take for a C bigot to jump in with
both feet. :-)
>Desinging software in fortran is a difficult prospect at best.
Do you actually "desing [sic] software in Fortran"? Most people I know
either do the designing before writing the Fortran, or else they just
write the Fortran. :-) (The latter technique is hardly unique to Fortran
programmers).
It is entirely possible, and not particularly difficult, to write clean,
structured, easy-to-understand, efficient code in Fortran. But like any
programming language, not everyone bothers.
>I personally think Fortran is an insult to all
>thinking computer programmers.
Of which you no doubt consider yourself to be one ...
(And you can't even spell "wankmeister" correctly! :-) )
Kenneth Plotkin
The Wankmiester <Wan...@Umass.Edu> wrote:
>
>Fortran is not even a real high level language. Desinging software
>in fortran is a difficult prospect at best. Fortran is a
>language that is high level in construct, and low-level in
>simplicity. I personally think Fortran is an insult to all
>thinking computer programmers.
>
You say that like it's a bad thing. I am a big, long time (30+ years)
user of Fortran, and I often think of it as an application program
rather than a programming language. I'd rather think about my problem
than about programming.
(Lest my digital body language not convey intent, I am agreeing with
you.)
Ken Plotkin
Robert Thurlow
Todd Lee Henderson <th9708@glhpx8> wrote:
>I would much rather read the fortran code, but then again, I've only
>done limited C programming.
Being a C programmer, I of course had the reverse preference.
I found it interesting that one poster complained about the
irritating semicolons and trouble matching if's and else's as
if they were language flaws. When I looked at the Fortran code,
I was struck by how damned hard it was (for me) to figure out
where the loops started and ended, and how that was made worse
by the lack of indentation. I think you learn to like what
you're used to, and have to get beyond the initial impressions
and do some real work if you want to compare tools.
The poster who said "choose and use the right tool for the job"
had it exactly right. If you have a numerical analysis problem
that can be expressed easily in Fortran, why use C if you're not
familiar with it? If you have a hot C compiler and the problem
needs to run like hell, a little benchmarking may be needed. If
you're writing 3D graphics code and have an excellent C library,
C might be easier. If you want to do string handling, Pascal or
even Snobol might be better.
>By the way, why does everyone hate the implicit variable names in
>fortran? That's what I hated about C, the fact that every stinking
>variable had to be declared, if you wanted to use i for a loop, it had
>to be declared right? What a waste of time while you're trying to write...
If you're writing something that will have to stand the test of
time in any sense, you want to pay particular attention to how
the compiler treats ALL of your data by declaring is carefully.
It costs much less when you're used to it. If the problem is a
quick and dirty one, maybe something like Perl would be a better
choice.
Rob T
Steve Bellenot
>fortran? That's what I hated about C, the fact that every stinking
>variable had to be declared, if you wanted to use i for a loop, it had
>to be declared right? What a waste of time while you're trying to write...
do 10 i=1,10
do 10 i=1.10
my understanding of fortran is not the best but the two lines above are
the same but for the `.' and `,' are both legal, at least at one time.
The second statement, since fortran, at least at that time, ignores
blanks, is an assignment operator. Implicit typing means that the compiler
silently accepts the code, creating a variable do10i and assigning the
value 1.1 which might even get optimized away.
I seem to remember that we lost a Venus proble for just such an error.
>
>Just my 2 cents work.
>
Just a little typing and you can let the compiler catch more of your
errors. Why not be really lazy and let the computer do more of the
dumb work. It is alot harder to debug, than to type.
Jon Bell
>It is entirely possible, and not particularly difficult, to write clean,
>structured, easy-to-understand, efficient code in Fortran.
And as has been pointed out elsewhere on more than one occasion, it's
possible to write bad Fortran in any language. :-)
I've heard of "obfuscated C" contests, but I don't think I've ever heard
of "fouled-up Fortran" contests, although goodness knows I've seen enough
fouled-up Fortran in my time, especially the pre-F77 variety.
--
Jon Bell <jtb...@presby.edu> Presbyterian College
Dept. of Physics and Computer Science Clinton, South Carolina USA
OMG
...
>By the way, why does everyone hate the implicit variable names in
>fortran? That's what I hated about C, the fact that every stinking
>variable had to be declared, if you wanted to use i for a loop, it had
>to be declared right? What a waste of time while you're trying to write...
Because if you or some other poor sap tries to modify the code, you
will have no idea what the loop variable MEANS. You might think that
you will remember, but after 6 months I guarantee you wont. Meaningful
variable names help to make code maintainable. They also encourage you
to use a variable for only one purpose (by making you list all the
variable names when you declare them). This too helps.
If your code will not have to be maintained (not even by you) then
you are doing a quick and dirty hack, and it does not matter.
Regards,
Martin
MLe...@atlantic.cs.unb.ca
Richard Koehl
Richard E. Hodges <hod...@breeze.seas.ucla.edu> wrote:
[cut]
> Instead of the above, I would prefer to see the C equivalent of
> the following. It is more representative of the kind of real world
> functions a typical scientific programmer uses.
Umm, your example does not appear to be numerically stable. Running
the program on AIX 3.2.5 w/ Fortran 2.03.etc. gives output which
differs in the fourth decimal place from the given output by the
time b(10) is calculated.
(21524.44531,-16084.28711)
(-20589.66016,-22261.36523)
(-41398.75781,10069.49121)
(-45208.90625,11180.12695)
(39456.35547,-12680.35059)
(1796.610962,-5101.974609)
(-9298.405273,-4254.427734)
(28928.56250,22868.03906)
(5782.170410,15082.76367)
(6506.900879,-10584.79590)
STOP
[cut]
> OUTPUT:
>
> (21524.4,-16084.3)
> (-20589.7,-22261.3)
> (-41398.8,10069.5)
> (-45209.0,11180.4)
> (39456.3,-12680.4)
> (1797.06,-5101.89)
> (-9297.79,-4254.67)
> (28928.8,22867.9)
> (5776.97,15084.2)
> (6501.25,-10585.3)
>
> Richard Hodges
>
Richard Koehl
--
/* Richard Koehl rko...@owlnet.rice.edu */
I R A Aggie
+ In article <3il9r3$j...@vixen.cso.uiuc.edu>,
+ Todd Lee Henderson <th9708@glhpx8> wrote:
+ >By the way, why does everyone hate the implicit variable names in
+ >fortran? That's what I hated about C, the fact that every stinking
+ >variable had to be declared, if you wanted to use i for a loop, it had
+ >to be declared right? What a waste of time while you're trying to write...
+
+ do 10 i=1,10
+ do 10 i=1.10
+
+ my understanding of fortran is not the best but the two lines above are
+ the same but for the `.' and `,' are both legal, at least at one time.
+ The second statement, since fortran, at least at that time, ignores
+ blanks, is an assignment operator. Implicit typing means that the compiler
+ silently accepts the code, creating a variable do10i and assigning the
+ value 1.1 which might even get optimized away.
+
+ I seem to remember that we lost a Venus proble for just such an error.
I would have stayed out of this, but for this last comment. To wit,
I reply with:
program testy
do 10 i=1,10
print *, i
10 continue
do 20 i=1.10
print *, i
20 continue
stop
end
Loops *do* things. They are *testable*. One should *do* so, as a routine
practice. My little do-nothing program outputs a series of integers that
range from (1..11). Exactly as it is supposed to, given that the variable
do20i=1.10.
Is that the intended results? Hell, no! So, there's an error, and it has
to be hunted down and killed.
I have to work with surface meteorological data. It's always
amusing how one's carefully-coded, compiles-perfectly, runs-fine,
optimizes-beautifully program will blow chunks sooner-or-later if you
feed it real data.
Can we move this discussion to alt.religion.computers.my.language.is.better?
James - print "Just another Perl hacker,"
Dave Wagner
>In article <3il9r3$j...@vixen.cso.uiuc.edu>,
>Todd Lee Henderson <th9708@glhpx8> wrote:
>>By the way, why does everyone hate the implicit variable names in
>>fortran? That's what I hated about C, the fact that every stinking
>>variable had to be declared, if you wanted to use i for a loop, it had
>>to be declared right? What a waste of time while you're trying to write...
>
>do 10 i=1,10
>do 10 i=1.10
>
>my understanding of fortran is not the best but the two lines above are
>the same but for the `.' and `,' are both legal, at least at one time.
>The second statement, since fortran, at least at that time, ignores
>blanks, is an assignment operator. Implicit typing means that the compiler
>silently accepts the code, creating a variable do10i and assigning the
>value 1.1 which might even get optimized away.
>
>I seem to remember that we lost a Venus proble for just such an error.
>
Come on. There are equivalent "silent errors" in C too..
for (i=0,i<10,i++);
{
some stuff
}
Also, while I'm here.... Someone responded to the above quote about
implicit nameing with a comment about meaningful variable names. I
don't think Todd was saying anything about the names, simply about
the requirement to declare every last one of 'em. Actually, about
the only thing I like about C++ (and mind you, I hate that language
with a passion!), is the fact that I can declare the loop-control-vars
on the "for" statement itself.
Anyway, my 2cents
--
Dave Wagner
da...@cray.com
(612) 683-5393
Warren J. Paul
writes:
<SNIP>
>I personally think Fortran is an insult to all
>thinking computer programmers.
>
>
>Sincerely,
>Thomas J. Wank
>
Typical thoughtless flame from a typical thoughtless CS person. Not
many do the type of engineering that results in physical objects (as
opposed to program objects) getting built by directly using
programs written in C and its derivatives, as opposed to some flavor of
Fortran. There are a multitude of reasons for this. I agree with those
who have stated that ther is a place for C and a distinct place for
Fortran. --- Warren
Robin Vowels
In article <grunes.125...@news.nrl.navy.mil> gru...@news.nrl.navy.mil (Mitchell R Grunes) writes:
| But some of us like Fortran. To me, Fortran is simply easier to debug
| than C. Partly because of my history: I am used to making those errors
| that Fortran compilers can find for me.
---What about the errors it c*a*n*'*t* find for you?
! And I have written utilities to
| help me find some of those that compilers don't find. Partly because C is
| much looser, and almost anything that I mistype seems to be a legitimate
| C expression.
I find this observation a bit suprising since I would say just the
same for Fortran. Its combination of implicit typing with lines being
silently truncated at 72 characters can easily lead to well
intentioned code that compiles fine but doesn't work quite as
expected.
---Have you tried IMPLICIT NONE? This will alleviate most, if not
all, of the problems that you mention. IMPLICIT NONE finds finger
troubles (O instead of 0, l instead of 1, etc, and mis-spelled
variable names). It also finds some type mismatches, expecially
those involving function subprograms and their returned values.
I suspect you have had a few bad experiences with a K&R C compiler and
doing things like forgetting to include math.h. Many of the silent
errors that you could have committed in K&R C are reported in ANSI C
and even more so in C++. (Eg. Forgetting to include math.h will cause
errors in ANSI C and C++)
---Some problems, like including a format specification in
output, but forgetting to include the variable to be printed,
give no warning, but produce silly answers when the program runs.
Given what I have said before, that it is frequently necessary to debug
scientific code by inspection, easy visual debugging is absolutely
necessary.
There is nothing unique about scientific code that requires this type
of debugging.
---Perhaps not, but if the code is clear, bugs can easily be detected
from a visual perusal of the code. In particular, ifyou have to
puzzle over C code, then it is not clear, and a visual inspection
may miss bugs that otherwise would be obvious.
Try making sure OS code is hacker proof! Same
difference. In every domain there are bugs that are not found in the
standard test sweep,
---Yes, but some languages are better than others in this regard.
Intel ought to know this one ;-D. But at any
rate, I've worked with quite a few Scientific Fortran codes and have
found plenty of errors that have been silently lying there for years.
Some of them were not found simply because Fortran is so *loose* about
types, e.g. implicit typing is evil.
---It is not FORTRAN that is loose about typing. It is the programmer!
At least for recent codes (< 5 years). For old codes, your comment
is valid.
But at any rate, visual
debugging comes down to coding style and what you're used to seeing.
---No, anyone should be able to a visual inspection of someone
else's code. This is standard practice in industry.
Byron Bodo
>
> In article <3il9r3$j...@vixen.cso.uiuc.edu> th9708@glhpx8 (Todd Lee Henderson) writes:
Not exactly so. It's been good practice since way back when to
start routines with a commented section of variable definitions &
other information needed to decipher the code.
-bb
Byron Bodo
>
> In article <3il9r3$j...@vixen.cso.uiuc.edu>,
> Todd Lee Henderson <th9708@glhpx8> wrote:
> >By the way, why does everyone hate the implicit variable names in
> >fortran? That's what I hated about C, the fact that every stinking
> >variable had to be declared, if you wanted to use i for a loop, it had
> >to be declared right? What a waste of time while you're trying to write...
>
> do 10 i=1,10
> do 10 i=1.10
>
> my understanding of fortran is not the best but the two lines above are
> the same but for the `.' and `,' are both legal, at least at one time.
> The second statement, since fortran, at least at that time, ignores
> blanks, is an assignment operator. Implicit typing means that the compiler
> silently accepts the code, creating a variable do10i and assigning the
> value 1.1 which might even get optimized away.
>
> I seem to remember that we lost a Venus proble for just such an error.
>
of software failure that makes mention of this in a list of great
all-time blunders. Such errors aren't restricted to any one
language, and the increasingly widespread reliance on increasingly
complex software to control most aspects of daily life & business
keeps upping the potential risks to one and all. Apparently, the
Canadian gov't is moving towards licensing of "software engineers"
and imposing certain reliability / safety standards. Right now,
anyone who can write a few lines of basic, can and do fob themselves
off as software engineers.
-bb
Dan Pop
>Typical thoughtless flame from a typical thoughtless CS person. Not
>many do the type of engineering that results in physical objects (as
>opposed to program objects) getting built by directly using
>programs written in C and its derivatives, as opposed to some flavor of
>Fortran.
I'm affraid you'll have a hard time backing this claim.
Virtually all the CAD software used to design cars, computers, etc is
written in some flavour of C.
R. D. Davis
>just because they always have in the past. It might mean learning
>something else, but if the argument had that much merit, they'd still be
>using PDP-8s...
What, pray tell, is wrong with using PDP-8s? I don't have a PDP-8
yet, but do have some PDP-11s. I'd rather have a PDP-8 than a kludgy
IBM type toy PC... I'm glad that I've gor PDP-11s, PERQs and CP/M (and
MP/M) machines to use instead.
--
R. D. Davis * Eccentrics have more fun! :-) * http://access.digex.net/~rdd
rda...@umbc.edu, ...uunet!mystica!rdd > "Today's busy world" isn't "busy";
Home telephone: 1-410-744-7964 > it's just grossly mismanaged by
Work (play!) telephone: 1-410-744-4900 > idiots, businesses and governments.
Dan Pop
>In article <3il124$p...@dux.dundee.ac.uk>,
>Pete Clinch <pjcl...@dux.dundee.ac.uk> wrote:
>
>>just because they always have in the past. It might mean learning
>>something else, but if the argument had that much merit, they'd still be
>>using PDP-8s...
>
>What, pray tell, is wrong with using PDP-8s? I don't have a PDP-8
>yet, but do have some PDP-11s. I'd rather have a PDP-8 than a kludgy
>IBM type toy PC... I'm glad that I've gor PDP-11s, PERQs and CP/M (and
>MP/M) machines to use instead.
There is absolutely nothing wrong with using PDP-8s. Pete just mentioned
a fact: most people who used PDP-8s sometime in the past (they've been
introduced 30 years ago) are using something else _today_. Do you
disagree? If not, what is your point?
Richard Ottolini
> significantly behind the Fortran code. But, never fear, we were told,
> it can be made to run faster in C. After an number of enhancements
> involving pointers and a number of machine-specific adjustments
> she wound up with a five times more lines of code -- utterly
> indecipherable as to what the actual function being performed might
> be by the time it was all done. Net result, it ran a bit faster --
> maybe 10-15%. Was it worth the trouble?
Your FORTRAN-66 example is difficult to read and prone to error also.
I'd recommend using FORTRAN-77 with clearly bounded loops or FORTRAN-90
that eliminates explicit array indexing iteration for more concise
and less error-prone code. Or any language where multidimensional
arrays is an abstract obstract like APL, Mathematical and certain
C++ libraries.
Richard Ottolini
The holy grail is to have "a best". Some of the better languages never
really became commercially popular.
Mark Charette
: Virtually all the CAD software used to design cars, computers, etc is
: written in some flavour of C.
Not quite. GM/EDS still enhances/supports/develops CGS for GM, and that is
primarily PL/1 (even on Unix workstations). Ford's PDGS is a mixture of
50 % FORTRAN 77, 40 % C, and 10% C++ (Ford's code is about that mixture - third
party libraries being used are primarily C++). There's an awful lot of cars
being built with these packages.
--------------------------------------------------------------------------------
Mark Charette "Don't crush that dwarf; hand me the pliers"
MIKA Systems, Inc. - Firesign Theater
17197 N. Laurel Park Dr Suite 115
Livonia, MI 48152 char...@mika.com
Michael Kraemer
Organization: GSI, Darmstadt, Germany
Subject: Re: So why do we still have to use Fortran?
In article <3il124$p...@dux.dundee.ac.uk>, pjcl...@dux.dundee.ac.uk (Pete Clinch) writes:
|>
|> Every dog has its day, and Fortran will (quite justifiably) be having its
|> day where it works best for a long time to come. I do wish though, that
|> some people in physical sciences would stop using it for *everything*
|> just because they always have in the past. It might mean learning
|> something else, but if the argument had that much merit, they'd still be
|> using PDP-8s...
|>
|> Pete.
|> --
|> Peter Clinch Dundee Teaching Hospitals NHS Trust
|> voice: 44 1382 660111 x 3637 snail: Directorate of Medical Physics
|> fax: 44 1382 640177 Ninewells Hospital
|> email: p.j.c...@dundee.ac.uk Dundee DD1 9SY Scotland UK
There's hope: I'm a physicist in a group of physicists and biologists.
The major programming tasks (including intensive calculations) are done in C.
FORTRAN is only used for a few "legacy" applications. Young people joining
the group often have experience in C/C++ from their home PCs, Amigas, Ataris etc.
As long as they're not spoiled by the "senior" scientists they won't touch
FORTRAN. I'm a somewhere inbetween agewise, I've learned FORTRAN, PL/I and
C and I prefer C over the others any day.
In addition, we have a project with a medical research centre (cancer therapy
using heavy ions) and all new programming for computerized planning is done in C.
Michael.
Scott Bayes
> In article <3ij2on$m...@masala.cc.uh.edu> Wan...@Umass.Edu (The Wankmiester) writes:
> >In article <3igiad$f...@Starbase.NeoSoft.COM>, wi...@Starbase.NeoSoft.COM (Will Morse) says:
[deleted]
> I would be interested if you could show the equivalent ANSI standard
> C program equivalent of the following simple program:
> program test
> complex aj, sum, x(10), b(10), A(10,10)
> aj = cmplx(0.,1.)
> do 10 i=1,10
> do 10 j=1,10
> 10 A(i,j) = cmplx(aj*abs(i-j))
> do 20 i=1,10
> 20 x(i) = ccos(cmplx(real(i),real(j)))
> do 30 i=1,10
> sum = cmplx(0.,0.)
> do 40 j=1,10
> 40 sum = sum + A(i,j)*x(j)
> 30 b(i) = sum
> do 50 i=1,10
> 50 write(*,*) b(i)
> stop
> end
Just for the helluvit, I transcribed this into Rocky Mountain BASIC. Not
relevant to th argument, but here's the transcription:
10 ! program test
20 COMPLEX Aj,Sum,X(10),B(10),A(10,10)
30 Aj=CMPLX(0.,1.0)
40 FOR I=1 TO 10
50 FOR J=1 TO 10
60 A(I,J)=Aj*ABS(I-J) ! CMPLX not needed here
70 NEXT J
80 NEXT I
90 FOR I=1 TO 10
100 X(I)=COS(CMPLX(I,J)) ! REAL casts not needed here
110 NEXT I
120 FOR I=1 TO 10
130 Sum=CMPLX(0.,0.)
140 FOR J=1 TO 10
150 Sum=Sum+A(I,J)*X(J)
160 NEXT J
170 B(I)=Sum
180 NEXT I
190 Cmplx_image:IMAGE "(",DDDDDD.D,",",DDDDDDD.D,")" ! Make it pretty
200 FOR I=1 TO 10
210 PRINT USING Cmplx_image;B(I)
220 NEXT I
230 END
> OUTPUT:
> (88510.2,-292106.)
> (96645.7,-217322.)
> (159225.,-167454.)
> (230253.,-176861.)
> (255968.,-225404.)
> (224269.,-256963.)
> (175840.,-231033.)
> (166747.,-159964.)
> (216892.,-97606.5)
> (291711.,-89802.1)
Here is the output (I couldn't quite figure out your format algorithm):
( 88510.2,-292106.0)
( 96645.7,-217321.7)
(159224.6,-167453.7)
(230252.9,-176860.7)
(255968.4,-225404.1)
(224269.1,-256963.4)
(175840.0,-231033.4)
(166747.4,-159964.1)
(216891.8, -97606.5)
(291711.5, -89802.1)
[deleted]
> A few years ago I viewed a seminar at JPL in which the presenter,
> a person with a similarly arrogant attitude, proposed to show the
> superiority of C over Fortran. She began with a simple matrix
> multiply. Maybe 10 lines of Fortran code. It was demonstrated that
> on a vector processing computer a simple loop unrolling exercise
> would give a certain amount of increase in execution speed.
> Then a similarly constructed C routine was tested. It lagged quite
> significantly behind the Fortran code. But, never fear, we were told,
> it can be made to run faster in C. After an number of enhancements
> involving pointers and a number of machine-specific adjustments
> she wound up with a five times more lines of code -- utterly
> indecipherable as to what the actual function being performed might
> be by the time it was all done. Net result, it ran a bit faster --
> maybe 10-15%. Was it worth the trouble?
Though I code a lot in C (and Pascal and 68K asm), and actually kind of
like C, I have to think that is a good question (I also maintain lots of
"legacy code").
Louis Gascoigne
>> >By the way, why does everyone hate the implicit variable names in
>> >fortran? That's what I hated about C, the fact that every stinking
>> >variable had to be declared, if you wanted to use i for a loop, it had
>> >to be declared right? What a waste of time while you're trying to write...
I think it is considered taboo. I will describe a legitimate use below.
>>
>> Because if you or some other poor sap tries to modify the code, you
>> will have no idea what the loop variable MEANS. You might think that
>> you will remember, but after 6 months I guarantee you wont. Meaningful
>> variable names help to make code maintainable. They also encourage you
>> to use a variable for only one purpose (by making you list all the
>> variable names when you declare them). This too helps.
>>
>> If your code will not have to be maintained (not even by you) then
>> you are doing a quick and dirty hack, and it does not matter.
>>
Actually there is one use of Implicit declarations which I think is
a very noble use. Say you use a program like Maple V to write an
optimized algorithm in Fortran code. (i.e. fortran(z,optimized);) where
z is a function you are interested in putting into a fortran program.
Maple will make the optimization using holding variables which start
with t. so they are (t*). It is VERY nice to be able to say, ok
IMPLICIT DOUBLE PRECISION (t)
The alternative is sitting there for hours making typos trying to
write explicit declarations. I have had Maple generate functions which
have hundreds of holding variables. I think this is probably one of
the reasons why implicit variable declarations are included.
Mark Johnson
>At the opposite pole you have Ada, which came with a lot of publicity,
>the backing of the US DoD and lots of companies implementing it in order
>to be competitive on the military market. 15 years later, virtually
>nobody is really using it and its few fans are still at the stage of
>"but wait for the next version".
Further, a lot of the early Ada projects were not a good fit for the language.
The one I remember best was the US Army's STANFINS-R project, a rewrite of
their standard financial information system. This was essentially the Army
payroll system, and the original was some millions of lines of Cobol. I don't
really think Ada, which was intended for embedded applications, was a
particularly good language choice for the rewrite.
Even at the time, there was lots of controversy over how successful the
project really was. I heard everything from "sterling success" to "miserable
flop - over budget, behind schedule." Never did hear what the final outcome of
the project was.
================
Mark Johnson USnail: Symbios Logic, Inc
E-mail: Mark.J...@WichitaKS.hmpd.COM OEM RAID Business Team
Voice: (316) 636-8189 [V+654-8189] 3718 N. Rock Rd.
(Formerly AT&T GIS/NCR MPD) Wichita, KS 67226
Jeff Drummond
In article <3iofcr$9...@ionews.io.org>, Byron Bodo <bo...@io.org> writes:
> bell...@math.fsu.edu (Steve Bellenot) wrote:
> >
> > do 10 i=1,10
> > do 10 i=1.10
> >
> > my understanding of fortran is not the best but the two lines above are
> > the same but for the `.' and `,' are both legal, at least at one time.
> > The second statement, since fortran, at least at that time, ignores
> > blanks, is an assignment operator. Implicit typing means that the compiler
> > silently accepts the code, creating a variable do10i and assigning the
> > value 1.1 which might even get optimized away.
> >
> > I seem to remember that we lost a Venus proble for just such an error.
> >
> Just read a interesting biz article on the increasing risks & costs
> of software failure that makes mention of this in a list of great
> all-time blunders.
The oft-repeated myth of the Venus probe lost due to a missing Fortran
comma been debunked in alt.folklore.computers and elsewhere.
We now rejoin the irregularily-scheduled C/Fortran flamefest, already in
progress.
-Jeff j...@cray.com
--
Matter: A degenerate, sticky substance which condenses out of low-energy
quarks. If you notice clumps of matter, it's a sure sign that your universe
has exploded. The matter will usually collapse back into a singularity on
its own; but if not, try increasing your gravitational constant.
Rick Thomas
> they just
>write the Fortran. :-) (The latter technique is hardly unique to Fortran
>programmers).
A person I once knew (who shall remain nameless) used to claim that
there were no original programs. When s/he needed a program, s/he would
just start with a blank sheet of paper and debug it til it worked.
Enjoy!
Rick
Byron Bodo
>
> Byron Bodo <bo...@io.org> writes:
>
> >> >By the way, why does everyone hate the implicit variable names in
> >> >fortran? That's what I hated about C, the fact that every stinking
> >> >variable had to be declared, if you wanted to use i for a loop, it had
> >> >to be declared right? What a waste of time while you're trying to write...
Whoa! I didn't write this. Get your attributions straight!
Same for other stuff below.
>
> I think it is considered taboo. I will describe a legitimate use below.
>
> >>
> >> Because if you or some other poor sap tries to modify the code, you
> >> will have no idea what the loop variable MEANS. You might think that
> >> you will remember, but after 6 months I guarantee you wont. Meaningful
> >> variable names help to make code maintainable. They also encourage you
> >> to use a variable for only one purpose (by making you list all the
> >> variable names when you declare them). This too helps.
> >>
> >> If your code will not have to be maintained (not even by you) then
> >> you are doing a quick and dirty hack, and it does not matter.
> >>
>
> Actually there is one use of Implicit declarations which I think is
> a very noble use. Say you use a program like Maple V to write an
> optimized algorithm in Fortran code. (i.e. fortran(z,optimized);) where
> z is a function you are interested in putting into a fortran program.
>
> Maple will make the optimization using holding variables which start
> with t. so they are (t*). It is VERY nice to be able to say, ok
>
> IMPLICIT DOUBLE PRECISION (t)
>
> The alternative is sitting there for hours making typos trying to
> write explicit declarations. I have had Maple generate functions which
> have hundreds of holding variables. I think this is probably one of
> the reasons why implicit variable declarations are included.
>
I'm inclined to agree with you. I've been playing a little with
Maple, but I haven't yet tried to generate fortran code with it.
Looks neat. Will have to try it.
-bb
Bruce Karsh
question is "why do we still use C".
Both languages are ancient. C is ~20 years old and Fortran is ~35 years
old. What kind of high technology is it whose tools have changed so little
over so much time?
These languages are all line-at-a-time based languages, developed so that
programs could be represented manually on punched cards. Over the years,
we've used these tools instead of developing ones that:
use graphics as well as text to represent program structure,
use real human factors data to make programming less error-prone,
use improved user interfaces to make programming more efficient,
reflect both the temporal and the algorithmic properties of programs,
explictly handle concurrency,
incorporate correctness proving techniques.
Interestingly, other engineering disciplines have not been so
backwards. They have developed computerized engineering tools which do
all of these things. While software engineers argue about Fortan vs C,
the other fields continue to use better and better tools. Engineers in
other disciplines regularly use graphical design tools, design rule checkers,
simulations etc., to make sure that their designs are correct. We mostly
use cc, dbx, etc, and then let end-users be the final testers.
Computer Science seems stuck in a rut because of its religious adherence to
ancient software development technologies. The arguments over which aging
programming language is better is a symptom of the problem.
Richard Ottolini
>The best example is C, which became popular without being pushed by
>anybody. People saw it, tried it, liked it. The commercial success
>came by itself.
Part of the reason C became popular was that its compiler source code
was readily available. This was partly because of its link with
UNIX which was also readily available. Therefore C became available
on wide variety of machines of different sizes.
Craig Burley
A person I once knew (who shall remain nameless) used to claim that
there were no original programs. When s/he needed a program, s/he would
just start with a blank sheet of paper and debug it til it worked.
Kind of like "how to write a computer program: treat available RAM as
a single, very large integer; initialize RAM to zero; repeatedly
increment RAM until it contains a program that meets the specifications".
Modification of the above algorithm to produce an optimal version
of the program is left to the reader.
;-)
--
James Craig Burley, Software Craftsperson bur...@gnu.ai.mit.edu
Peter da Silva
Louis Gascoigne <eap...@taurus.oac.uci.edu> wrote:
> Maple will make the optimization using holding variables which start
> with t. so they are (t*). It is VERY nice to be able to say, ok
> IMPLICIT DOUBLE PRECISION (t)
> The alternative is sitting there for hours making typos trying to
> write explicit declarations.
The alternative is for Maple to declare its variables. If it doesn't then
you simply write a little script to extract Maple's variables and write
the declarations. Then send the script in to the people maintaining Maple
with a bug report.
--
Peter da Silva `-_-'
Network Management Technology Incorporated 'U`
1601 Industrial Blvd. Sugar Land, TX 77478 USA
+1 713 274 5180 "Hast du Heute schon deinen Wolf umarmt?"
Mr Robert Byrne
>Arne Vajhoej (ar...@kopc.hhs.dk) wrote:
>: Modern FORTRAN compilers has witches to give warnings on such mistakes.
I thought that was Cabbal / Cobol :)
>Whoa!!! Now there's an incentive to write correct code!
>:-)
Rob
Dan Pop
To become commercially popular a language has to become popular, first.
The best example is C, which became popular without being pushed by
anybody. People saw it, tried it, liked it. The commercial success
came by itself.
At the opposite pole you have Ada, which came with a lot of publicity,
the backing of the US DoD and lots of companies implementing it in order
to be competitive on the military market. 15 years later, virtually
nobody is really using it and its few fans are still at the stage of
"but wait for the next version".
Just my $0.02,
Edward Luke
The question "why do we still have to use Fortran" is a good one. But my
question is "why do we still use C".
Both languages are ancient. C is ~20 years old and Fortran is ~35 years
old. What kind of high technology is it whose tools have changed so little
over so much time?
How old is the technology of wrenches, hammers, or axes? Just because
a technology is old does not mean it is obsolete. Of course there is
also the saying, "If all you have is a hammer, everything looks like a
nail."
-Ed
--
Mail: segmentation violation -- core dumped
John A. Turner
> The oft-repeated myth of the Venus probe lost due to a missing Fortran
> comma been debunked in alt.folklore.computers and elsewhere.
Here's something Dan Pop posted back in September (yeah, I'm an e-mail
packrat). I hope he won't mind me re-posting it (maybe it'll save him
the trouble)...
----------------------- Begin Included Message -------------------------
Newsgroups: comp.lang.fortran
From: dan...@cernapo.cern.ch (Dan Pop)
Subject: Re: Urban myth?
Organization: CERN European Lab for Particle Physics
Date: Mon, 19 Sep 1994 10:56:50 GMT
In <kemidb.779968115@aau> kem...@aau.dk (Dieter Britz) writes:
>Over the years, I have several times seen reference to this piece of code:
>
> DO 10 I = 1.10
> ...
>10 CONTINUE
>
>It is said that this error (which the compiler, of course, interprets as
>the assignment statement DO10I=1.10) was made in a space program program,
>and led to a rocket crash. Is this factual, or is this an urban myth in
>the computer world?
>From the alt.folklore.computers FAQ:
III.1 - I heard that one of the NASA space probes went off course and
had to be destroyed because of a typo in a FORTRAN DO loop.
Is there any truth to this rumor?
As revealed by past discussion in comp.risks (Risks Digest) as well as
alt.folklore.computers and occasionally other newsgroups, this turns
out to be a confusion of two separate events.
The space probe that the DO-loop story has been wrongly attached to is
Mariner I (or 1), which was intended for Venus (not Mars). Several
incorrect or partially correct versions of what really happened were
posted in comp.risks; the best of these cited a NASA publication called
"Far Travelers" by Oran W. Nicks, but still did not have the whole story.
Then in issue 8.75 we found out what really happened...
| Date: Sat, 27 May 1989 15:34:33 PDT
| From: Peter Neumann <neu...@csl.sri.com>
| Subject: Mariner I -- no holds BARred
|
| Paul Ceruzzi has written a truly outstanding book for the new show
| that opened two weeks ago at the Smithsonian National Air and Space
| Museum. The exhibit and the book are both entitled "Beyond the Limits
| -- Flight Enters the Computer Age". Both are superb. Go for it (them).
|
| Paul has dug into several cases treated previously in RISKS and in
| issues of the ACM Software Engineering Notes, and has been able to
| resolve several mysteries. In particular he considers the case of
| Mariner I, about which various inaccurate stories have been told.
| Intended to be the first US spacecraft to visit another planet, it was
| destroyed by a range officer on 22 July 1962 when it behaved
| erratically four minutes after launch. The alleged missing `hyphen'
| was really a missing `bar'. I quote from Paul's book, pp. 202-203:
|
| # During the launch the Atlas booster rocket was guided with the help
| # of two radar systems. One, the Rate System, measured the velocity of
| # the rocket as it ascended through the atmosphere. The other, the
| # Track System, measured its distance and angle from a tracking
| # antenna near the launch site. At the Cape a guidance computer
| # processed these signals and sent control signals back to the
| # tracking system, which in turn sent signals to the rocket. Its
| # primary function was to ensure a proper separation from the Atlas
| # booster and ignition of the Agena upper stage, which was to carry
| # the Mariner Spacecraft to Venus.
| #
| # Timing for the two radar systems was separated by a difference of
| # forty-three milliseconds. To compensate, the computer was instructed
| # to add forty-three milliseconds to the data from the Rate System
| # during the launch. This action, which set both systems to the same
| # sampling time base, required smoothed, or averaged, track data,
| # obtained by an earlier computation, not the raw velocity data
| # relayed directly from the track radar. The symbol for this smoothed
| # data was ... `R dot bar n' [R overstruck `.' and `_' and subscript n],
| # where R stands for the radius, the dot for the first derivative
| # (i.e., the velocity), the bar for smoothed data, and n for the
| # increment.
| #
| # The bar was left out of the hand-written guidance equations. [A
| # footnote cites interviews with John Norton and General Jack Albert.]
| # Then during launch the on-board Rate System hardware failed. That in
| # itself should not have jeopardized the mission, as the Track System
| # radar was working and could have handled the ascent. But because of
| # the missing bar in the guidance equations, the computer was
| # processing the track data incorrectly. [Paul's EndNote amplifies:
| # The Mariner I failure was thus a {\it combination} of a hardware
| # failure and the software bug. The same flawed program had been used
| # in several earlier Ranger launches with no ill effects.] The result
| # was erroneous information that velocity was fluctuating in an
| # erratic and unpredictable manner, for which the computer tried to
| # compensate by sending correction signals back to the rocket. In fact
| # the rocket was ascending smoothly and needed no such correction. The
| # result was {\it genuine} instead of phantom erratic behavior, which
| # led the range safety officer to destroy the missile, and with it the
| # Mariner spacecraft. Mariner I, its systems functioning normally,
| # plunged into the Atlantic.
The DO-loop incident did happen at NASA, and at about the same time.
As told by Fred Webb in alt.folklore.computers in 1990:
| I worked at Nasa during the summer of 1963. The group I was working
| in was doing preliminary work on the Mission Control Center computer
| systems and programs. My office mate had the job of testing out an
| orbit computation program which had been used during the Mercury
| flights. Running some test data with known answers through it, he was
| getting answers that were close, but not accurate enough. So, he
| started looking for numerical problems in the algorithm, checking to
| make sure his tests data was really correct, etc.
|
| After a couple of weeks with no results, he came across a DO
| statement, in the form:
| DO 10 I=1.10
| This statement was interpreted by the compiler (correctly) as:
| DO10I = 1.10
| The programmer had clearly intended:
| DO 10 I = 1, 10
|
| After changing the `.' to a `,' the program results were correct to
| the desired accuracy. Apparently, the program's answers had been
| "good enough" for the sub-orbital Mercury flights, so no one suspected
| a bug until they tried to get greater accuracy, in anticipation of
| later orbital and moon flights. As far as I know, this particular bug
| was never blamed for any actual failure of a space flight, but the
| other details here seem close enough that I'm sure this incident is the
| source of the DO story.
Project Mercury's sub-orbital flights were in 1961, and its orbital
flights began in 1962. I forwarded the above to comp.risks, slightly
abridged, and it appeared there in issue 9.54.
The erroneous claim that the DO-loop bug was the bug that killed Mariner I
apparently originated with, and certainly was propagated by, the book
"Software Reliability: Principles and Practices" by G(lenford) J. Myers
(John Wiley & Sons, 1976). I haven't read it myself; I've seen the page
numbers 7 and 275 attributed to the assertion. I expect both are right.
This book also describes the bug as a "billion-dollar error", which is
too large by a factor of about 50.
In some earlier postings it was suggested that Myers be located and
asked about his sources (the book gives none), but nobody successfully
did this; his employer at the time of publication didn't have his
current address. My guess is that he simply made an error or more
likely accepted someone else's wrong recollection, and didn't feel
it necessary to go to original sources to verify what was only an
illustrative point anyway.
This answer by Mark Brader <m...@sq.com>. Quoted items in it have been
reformatted but not abridged.
--
Dan Pop
CERN, CN Division
Email: dan...@cernapo.cern.ch
Mail: CERN - PPE, Bat. 31 R-004, CH-1211 Geneve 23, Switzerland
----------------------- Begin Included Message -------------------------
+---------------------------------------------------------------+
| John A. Turner |
| Los Alamos National Laboratory, MS B226, Los Alamos, NM 87545 |
| Group: X-6 (Radiation Transport) |
| Location: TA-3, Bldg. 43, Rm. D263 |
| Phone: 505-665-1303 e-mail: tur...@lanl.gov |
+---------------------------------------------------------------+
Jon Bell
>fortran? That's what I hated about C, the fact that every stinking
>variable had to be declared, if you wanted to use i for a loop, it had
>to be declared right? What a waste of time while you're trying to write...
*I* think it's a *much* bigger waste of time to spend hours tracking down
a bug caused by a misspelled variable name. Of course, if you use only
one-letter variable names, maybe that's not much of a problem for you.
:-) :-) :-)
--
Jon Bell <jtb...@presby.edu> Presbyterian College
Dept. of Physics and Computer Science Clinton, South Carolina USA
(who uses "IMPLICIT NONE" religiously)
Richard E. Hodges
>Ok, here is the equivalent C++ code:
>
>#include <stream.h>
>#include <complex.h>
>
>
>main()
>{
> Complex aj(0,1), sum, A[10][10], x[10], b[10] ;
> int i,j ;
>
> for(i=0;i<10;i++)
> for(j=0;j<10;j++)
> A[i][j] = Complex(aj*abs(i-j)) ;
>
> for(i=0;i<10;i++)
> x[i] = cos(Complex(i+1,j+1)) ;
>
> for(i=0;i<10;i++) {
> sum = 0 ;
> for(j=0;j<10;j++)
> sum = sum + A[i][j]*x[j] ;
> b[i] = sum ;
> }
>
> for(i=0;i<10;i++)
> cout << b[i] << "\n" ;
>}
>
>Output:
>ike% !g++
>g++ c.cc -lm
>ike% a.out
>(88510.2, -292106)
>(96645.7, -217322)
>(159225, -167454)
>(230253, -176861)
>(255968, -225404)
>(224269, -256963)
>(175840, -231033)
>(166747, -159964)
>(216892, -97606.5)
>(291711, -89802.1)
>
>
>
>It looks to be just as simple as the fortran code. Hmmm...
>
>- Ed Luke
You're right, Ed. It's really not bad.
I've been reading (in my spare time, such as it becomes available)
a book on C++. My interest is mainly because to "reach" graphics
functions on many machines you need to be in C or C++.
One thing I wonder about (and this is not intended as a loaded
question) is whether you would write the code this way normally.
Or, did you try to "mimick" the style of a Fortran program. Reason
I ask is because the book I've been reading comes up with some
very different (to Fortran) looking code. Also, some discussion
here recently a person mentioned that to get high performance you
wouldn't necessarily follow a Fortran style of code.
Oh, another quick question. Am I correct that in C++ functions
in the math library are "generic" as they are in Fortran. For
instance you write Complex(0,1), but could you write, say,
Complex(0,1.5) without getting numerical problems?
Thanks for showing this example.
Richard Hodges
Richard E. Hodges
contributions to compare the 'look' of an equivalent C program.
Parenthetically, since the issue of performance of C and C++
vs. Fortran has been raised in another thread, it might be of
some interest to see what a "high performance" C (or C++)
equivalent routine might be.
As it turns out, the routine I cooked up has a numerical accuracy
problem in single precision. Someone e-mailed to show an equivalent
Basic program which got a slightly different answer! I converted the
"test" program to double precision and, sure enough, it matched the
Basic program results.
After checking into it, I found out the problem is related to loss
of accuracy in Fortran calculations on transcendental functions.
For instance, the following program computes the correct answer
to within single precision accuracy:
program testfix
complex sum, x(10), b(10), A(10,10)
real*8 pi
complex*16 aj
aj = dcmplx(0.d0,1.d0)
pi = 4.d0 * datan(1.d0)
do 10 i=1,10
do 10 j=1,10
x(i) = ccos(cmplx(real(i),real(j)))
10 A(i,j) = cdexp(aj*(dabs(pi*i-j)**2.5d0))
do 30 i=1,10
sum = cmplx(0.,0.)
do 40 j=1,10
40 sum = sum + A(i,j)*x(j)
30 b(i) = sum
do 50 i=1,10
50 write(*,*) b(i)
stop
end
Here are the calculated results. BTW, these were done on an
Intel 486 DX2-66 processor. Hmm... maybe I try a RISC machine. :-)
ORIGINAL "TEST" "TESTFIX"
(pure single precision) (double precision
transcendentals)
1 (21524.4,-16084.3) (21524.4,-16084.2)
2 (-20589.7,-22261.3) (-20589.7,-22261.4)
3 (-41398.8,10069.5) (-41398.8,10069.7)
4 (-45209.0,11180.4) (-45208.7,11181.4)
5 (39456.3,-12680.4) (39456.0,-12681.8)
6 (1797.06,-5101.89) (1796.78,-5102.55)
7 (-9297.79,-4254.67) (-9298.25,-4254.91)
8 (28928.8,22867.9) (28933.3,22864.2)
9 (5776.97,15084.2) (5779.81,15082.5)
10 (6501.25,-10585.3) (6495.50,-10586.2)
"TEST" (pure double precision)
1 (21524.4178524352,-16084.2319825792)
2 (-20589.7269726545,-22261.4062740334)
3 (-41398.8239970617,10069.7396352541)
4 (-45208.7031986766,11181.3965984123)
5 (39456.0373754397,-12681.7612562908)
6 (1796.77995612275,-5102.55238421848)
7 (-9298.24526970738,-4254.91143536627)
8 (28933.2975751428,22864.2445301139)
9 (5779.81189241316,15082.4675038262)
10 (6495.49979751512,-10586.1806425349)
Richard Hodges
Bob Wells - Tel: (+44) [0]865 272915
ka...@audio.esd.sgi.com (Bruce Karsh) writes:
>
> Both languages are ancient. C is ~20 years old and Fortran is ~35 years
> old. What kind of high technology is it whose tools have changed so little
> over so much time?
>
> These languages are all line-at-a-time based languages, developed so that
> programs could be represented manually on punched cards. Over the years,
> we've used these tools instead of developing ones that:
>
> use graphics as well as text to represent program structure,
> use real human factors data to make programming less error-prone,
> use improved user interfaces to make programming more efficient,
> reflect both the temporal and the algorithmic properties of programs,
> explictly handle concurrency,
> incorporate correctness proving techniques.
>
So why did Bruce use a 1000 year-old language for his message ?
There are plenty of more modern alternatives which have attempted to
address the shortcomings of English.
I doubt a graphical representation would have been more efficient.
Bob (we...@atm.ox.ac.uk)
Richard Ottolini
>In <3iva62$7...@unogate.unocal.com> stg...@sugarland.unocal.COM (Richard Ottolini) writes:
>
>>
>>Part of the reason C became popular was that its compiler source code
>>was readily available. This was partly because of its link with
>>UNIX which was also readily available. Therefore C became available
>>on wide variety of machines of different sizes.
>
>a single machine: the PDP-11. After this, Unix entered its commercial
>life, and many companies made a lot of money selling Unix and C compilers.
No, UNIX made tremendous inroads in the universities as being
almost freeware in the late 70s and early 80s. Almost all computer
manufacturers that survived larger than a PC were forced by newly
graduating users to implement UNIX and C.
>
>OTOH, FORTRAN was available on every single computer, from the "tiny"
>PDP-8 to the big CDC-7600.
Your comment is irrelevant. On most new computers, starting in the
late 70s- especially workstations and PCs- C was implemented before
FORTRAN for the reasons I mentioned.
There are many instances where low cost "shareware" went to dominate
a market- UNIX, C, XWindows, C++ - even were technically inferior to
commercially supported offerings. And there are instances where
the shareware strategy failed.
Dan Pop
> One thing I wonder about (and this is not intended as a loaded
> question) is whether you would write the code this way normally.
> Or, did you try to "mimick" the style of a Fortran program. Reason
> I ask is because the book I've been reading comes up with some
> very different (to Fortran) looking code. Also, some discussion
> here recently a person mentioned that to get high performance you
> wouldn't necessarily follow a Fortran style of code.
You write C/C++ code according to your tastes and style preferences.
Unless your employer enforces a certain coding style.
Performance-wise, you try to optimize the algorithm and don't care too
much about micro-optimizations at coding level. The compiler is usually
better at optimizing code. A code which is hand tuned for a certain
platform, might be horribly inefficient on another platform. If you
make your real intentions clear to the compiler, it will do a good job
optimizing your code.
The techniques for writing high performance codes are common to
C, C++ and Fortran. See, e.g. Kevin Dowd, High Performance Computing.
>
> Oh, another quick question. Am I correct that in C++ functions
> in the math library are "generic" as they are in Fortran. For
> instance you write Complex(0,1), but could you write, say,
> Complex(0,1.5) without getting numerical problems?
The compiler will automatically convert the arguments to the correct
types, according to the function prototype. This is common to both ANSI
C and C++. Additionally, C++ allows Complex(0,1) and Complex(0,1.5) to
invoke two completely different functions (function name overloading).
Dan
Edward Luke
One thing I wonder about (and this is not intended as a loaded
question) is whether you would write the code this way normally.
Or, did you try to "mimick" the style of a Fortran program. Reason
I ask is because the book I've been reading comes up with some
very different (to Fortran) looking code.
Well, as usual that depends. If my only intent was to hack out a
10-100 line program to get a quick answer then most likely the program
would look like the above. There also must be the realization that
with C++ there are a variety of different "levels" at which C++ can be
used. If you are building class libraries (e.g. the complex type)
then the code will look very different from Fortran, which is
reasonable since what you are describing is very different from
anything Fortran can do. On the other hand, if you are using class
libraries, (e.g. the example above) then, hell, there's not that many
ways to write a loop construct.
Also, some discussion
here recently a person mentioned that to get high performance you
wouldn't necessarily follow a Fortran style of code.
In most cases the above C++ code's best performance would probably be
less than the equivalent Fortran code. Some of this gap will be
narrowed as C++ compilers mature, and some of it is intrinsic to the
fact that Complex is not a built-in type for C++. It's hard to say
how this code would be optimized, and at any rate it would be a
function of other constraints in the problem description which a
simple example does not illustrate. If performance really is the
bottom line, on todays compilers it probably will be easiest to
implement complex arithmetic calculations in Fortran.
Oh, another quick question. Am I correct that in C++ functions
in the math library are "generic" as they are in Fortran. For
instance you write Complex(0,1), but could you write, say,
Complex(0,1.5) without getting numerical problems?
The Complex constructor expects two double arguments, if you provide
integers, C++ will convert them to doubles automatically for you. So
Complex(0,1) is equivalent to Complex(double(0),double(1)).
- Ed Luke
Michael G. Phillips
: The question "why do we still have to use Fortran" is a good one. But my
: question is "why do we still use C".
: Both languages are ancient. C is ~20 years old and Fortran is ~35 years
: old. What kind of high technology is it whose tools have changed so little
: over so much time?
: These languages are all line-at-a-time based languages, developed so that
: programs could be represented manually on punched cards. Over the years,
: we've used these tools instead of developing ones that:
: use graphics as well as text to represent program structure,
: use real human factors data to make programming less error-prone,
: use improved user interfaces to make programming more efficient,
: reflect both the temporal and the algorithmic properties of programs,
: explictly handle concurrency,
: incorporate correctness proving techniques.
: Interestingly, other engineering disciplines have not been so
: backwards. They have developed computerized engineering tools which do
: all of these things. While software engineers argue about Fortan vs C,
: the other fields continue to use better and better tools. Engineers in
: other disciplines regularly use graphical design tools, design rule checkers,
: simulations etc., to make sure that their designs are correct. We mostly
: use cc, dbx, etc, and then let end-users be the final testers.
And which languages are *all* those "computerized engineering tools"
written in???
-michael
: Computer Science seems stuck in a rut because of its religious adherence to
: ancient software development technologies. The arguments over which aging
: programming language is better is a symptom of the problem.
--
--------------------------------------------------------------------
Michael G. Phillips mg...@crl.com mg...@atldbs.dbsoftware.com
(404)239-2766 "Just because it worked doesn't mean it works." -- me
Steve Gombosi
<snip>
>Every dog has its day, and Fortran will (quite justifiably) be having its
>day where it works best for a long time to come.
I cannot help but be reminded of a comment I heard back in the '70's, when
we were all told that Pascal would completely supplant the "F language"
Real Soon Now and FORTRAN 66 was still current:
Nobody knows what the premier scientific computing language of the
21st Century will look like, but its name will be "FORTRAN."
I wish I could remember who originally said it.
Steve Gombosi
Cray Computer Corporation
s...@craycos.com
Byron Bodo
>
>
> In article <3iofcr$9...@ionews.io.org>, Byron Bodo <bo...@io.org> writes:
> > bell...@math.fsu.edu (Steve Bellenot) wrote:
> > >
> > > do 10 i=1,10
> > > do 10 i=1.10
> > >
> > > my understanding of fortran is not the best but the two lines above are
> > > the same but for the `.' and `,' are both legal, at least at one time.
> > > The second statement, since fortran, at least at that time, ignores
> > > blanks, is an assignment operator. Implicit typing means that the compiler
> > > silently accepts the code, creating a variable do10i and assigning the
> > > value 1.1 which might even get optimized away.
> > >
> > > I seem to remember that we lost a Venus proble for just such an error.
> > >
> > Just read a interesting biz article on the increasing risks & costs
> > of software failure that makes mention of this in a list of great
> > all-time blunders.
>
> The oft-repeated myth of the Venus probe lost due to a missing Fortran
> comma been debunked in alt.folklore.computers and elsewhere.
>
Mea culpa. The business article doesn't claim the bug was a FORTRAN
error, merely a misplaced comma. However, the point was that
the risks/cost of this sort of thing are growing and no language
has a righteous claim to being fool proof. Indeed, the complexity
of software systems being developed these days, virtually assures
that all bugs and typos cannot be caught.
-bb
Dan Pop
Not quite. Unix was readily available only for a few years and only for
a single machine: the PDP-11. After this, Unix entered its commercial
life, and many companies made a lot of money selling Unix and C compilers.
OTOH, FORTRAN was available on every single computer, from the "tiny"
PDP-8 to the big CDC-7600.
Dan
Thomas Koenig
article <danpop.793999361@rscernix>:
[crossposting to hell and back shortened in F-Up]
>Not quite. Unix was readily available only for a few years and only for
>a single machine: the PDP-11. After this, Unix entered its commercial
>life, and many companies made a lot of money selling Unix and C compilers.
What about BSD?
--
Thomas Koenig, Thomas...@ciw.uni-karlsruhe.de, ig...@dkauni2.bitnet.
The joy of engineering is to find a straight line on a double
logarithmic diagram.
Charles Lasner
Ruth Milner <rmi...@newshost.aoc.nrao.edu> wrote:
!In article <3il124$p...@dux.dundee.ac.uk>,
!Pete Clinch <pjcl...@dux.dundee.ac.uk> wrote:
!
!>I do wish though, that
!>some people in physical sciences would stop using it for *everything*
!>just because they always have in the past.
!>[...] if the argument had that much merit, they'd still be
!>using PDP-8s...
!
!Um ... but some people still *are* using PDP-8's. No, not us (though we do
!have a couple of PDP-11's lying around :-) ), but I know a few places that
!do. Usually for a reason that can be rationalized, like to support some
!piece of equally old hardware that nothing else will handle and that you
!can't afford to replace with something modern, and why bother anyway since
!it does what you want and never breaks? :-)
!--
!Ruth Milner NRAO Socorro NM
!Manager of Computing Systems rmi...@aoc.nrao.edu
Over here on alt.sys.pdp8, our FAQ expands on this very idea. Yes, we
*do* use PDP-8's, and for even more reasons than stated above, etc.
cjl
ps: PDP-8's have versions of FORTRAN.
Warren J. Paul
>
>In <3ipc3j$4...@ixnews2.ix.netcom.com> WJP...@ix.netcom.com (Warren J.
Paul) writes:
>
>>Typical thoughtless flame from a typical thoughtless CS person. Not
>>many do the type of engineering that results in physical objects (as
>>opposed to program objects) getting built by directly using
>>programs written in C and its derivatives, as opposed to some flavor
of
>>Fortran.
>
>I'm affraid you'll have a hard time backing this claim.
>
>Virtually all the CAD software used to design cars, computers, etc is
>written in some flavour of C.
>
>Dan
>--
>Dan Pop
>CERN, CN Division
>Email: dan...@cernapo.cern.ch
>Mail: CERN - PPE, Bat. 31 R-004, CH-1211 Geneve 23, Switzerland
>
Of course. CAD software with all its graphics and data relationships
SHOULD be written in some C varient. But the key is word is engineer
vs. design (or drafting). CAD is a great tool, but the modules used to
do engineering work are often Fortran, or Fortran translated to C. I do
also admit that much engineering is done on spreadsheets, all written in
C varients. Strictly I should limit my comments to numerical analysis,
where Fortran reigns supreme in inverting matrices, or the equivalent.
Dan Pop
>MAny of us on alt.sys.pdp8 still do use PDP-8's as we also use other
>machines for other purposes. If for no other reason, it serves as a good
>basis to understand how other computers work. (BTW, how many people out
>there really don't have a clue how a computer really works, i.e., all
>computers are some sort of magic executor of C source code in compiled
>form by dark grey magic means not important enough for them to bother
>finding out about, etc.)
This is not much different from most of the PDP-8 users of 3 decades ago,
for whom a PDP-8 was some sort of magic executor of FOCAL and FORTRAN
code. How many of them did know even the word length of the machine,
not to mention the addressing model, based on 128 word pages, etc.
Computer architectures change, Joe User doesn't.
Rich R Car
For "readibly available" read "Free". Giving away anything for free is one
of the most *aggressive* ways of pushing it. The idea that C became popular
withoug being pushed is laughable.
Cheers.
Robert A. Zingarelli
|> Todd Lee Henderson <th9708@glhpx8> wrote:
|> >By the way, why does everyone hate the implicit variable names in
|> >fortran? That's what I hated about C, the fact that every stinking
|> >variable had to be declared, if you wanted to use i for a loop, it had
|> >to be declared right? What a waste of time while you're trying to write...
|>
|> *I* think it's a *much* bigger waste of time to spend hours tracking down
|> a bug caused by a misspelled variable name. Of course, if you use only
|> one-letter variable names, maybe that's not much of a problem for you.
|> :-) :-) :-)
I agree, but there is (was?) a solution. DEC's VMS fortran would give you a
very nice alphabetical listing of all variables and their types; others might
as well. Typos stand out nicely in such a listing.
Of course, some compilers accept implicit none, if you want to annoy youself
to death instead of doing physics...
(ok, now I've got to go wade through the SGI fortran man pages. Ugh.
But that's another thread).
-Rob Zingarelli / zi...@navo.navy.mil
Keith Crews
Fortran program posted did not make use of the features of the
language that give it a big advantage over C for numerical
programming. Specifically, Fortran 77 supports assumed size and
adjustable arrays and has strict semantics with regard to aliasing.
As a result, Fortran programmers can easily write libraries that
operate on vectors and matrices of various sizes and Fortran compilers
can aggressively optimize, knowing that in a conforming program there
is no aliasing going on behind its back. The fact that complex is a
datatype supported in the language also means that highly optimized
runtime support for complex operations and built in functions can be
provided by vendors.
In order to see what you have to do in C to simulate these built in
Fortran features, you should refer to chapter 1 of Numerical Recipes
in C. The amount of work you have to do, just to work around
deficiencies in the language, is quite large. And even if you do it,
the performance will never approach that which could be obtained by
writing it in Fortran and using a highly optimizing compiler.
But don't get me wrong - in general, Fortran sucks. I'm much happier
programming almost anything in C or C++. But for certain types of
numerical code, Fortran is vastly superior, especially if you care
about performance.
Disclaimer: My knowledge of Fortran ended with Fortran 77. I don't
know to what extent later versions have made the language better or
worse for these problems.
--
Keith Crews ke...@belmont.com
Belmont Research
84 Sherman St.
Cambridge, Mass. 02140
617-868-6878
Mitchell R Grunes
> of accuracy in Fortran calculations on transcendental functions.
> For instance, the following program computes the correct answer
> to within single precision accuracy:
>
> program testfix
> complex sum, x(10), b(10), A(10,10)
> real*8 pi
> complex*16 aj
> aj = dcmplx(0.d0,1.d0)
> pi = 4.d0 * datan(1.d0)
> do 10 i=1,10
> do 10 j=1,10
> x(i) = ccos(cmplx(real(i),real(j)))
> 10 A(i,j) = cdexp(aj*(dabs(pi*i-j)**2.5d0))
> do 30 i=1,10
> sum = cmplx(0.,0.)
> do 40 j=1,10
> 40 sum = sum + A(i,j)*x(j)
> 30 b(i) = sum
> do 50 i=1,10
> 50 write(*,*) b(i)
> stop
> end
In the line
x(i) = ccos(cmplx(real(i),real(j)))
you lose precision because real yields single precision.
Replace real by dble and cmplx by dcmplx.
-------------------------------------------------------------------------
(opinions expressed are mine alone)
Mitchell R Grunes (gru...@nrlvax.nrl.navy.mil)
Allied-Signal Tech. Serv. / Naval Research Lab
Christian L Claiborn
In article <davew.793771626@hickory422> da...@cray.com (Dave Wagner) writes:
Come on. There are equivalent "silent errors" in C too..
for (i=0,i<10,i++);
{
some stuff
}
What's the 'silent error' here?
[...]
So silent that I didn't even catch it. Next time I'll keep my mouth
shut.
Point well expressed, Mr. Wagner.
christian
--
Christian Longshore Claiborn - Cabletron Systems Inc.
"You mean on top of everything else, this ship is rigged?" -- Stan Freberg
Peter da Silva
Bruce Karsh <ka...@audio.esd.sgi.com> wrote:
> The question "why do we still have to use Fortran" is a good one. But my
> question is "why do we still use C".
> These languages are all line-at-a-time based languages, developed so that
> programs could be represented manually on punched cards.
oh(); really =
how + do + you; come();
to=that[conclusion]+it?looks:like; C=is &
free &
form; to(me);
> Over the years,
> we've used these tools instead of developing ones that:
> use graphics as well as text to represent program structure,
I've used a couple of those. They do not provide any significant advantage
and are cumbersome to use.
> use real human factors data to make programming less error-prone,
There are any number of languages that purport to do that.
> use improved user interfaces to make programming more efficient,
Improved user interfaces are a matter of data entry. The actual program
structure can as well be represented as flat text.
The last one I used displayed the program as Warnier-Orr diagrams, though
conventional flowcharts are more common. So far I haven't found one that
doesn't inhale.
> reflect both the temporal and the algorithmic properties of programs,
Explain.
> explictly handle concurrency,
Concurrent Euclid, C*?
> incorporate correctness proving techniques.
Do you mean things like assert, or implementing the algorithm twice?
> Interestingly, other engineering disciplines have not been so
> backwards. They have developed computerized engineering tools which do
> all of these things.
So has the software industry.
> While software engineers argue about Fortan vs C,
> the other fields continue to use better and better tools. Engineers in
> other disciplines regularly use graphical design tools, design rule checkers,
> simulations etc., to make sure that their designs are correct. We mostly
> use cc, dbx, etc, and then let end-users be the final testers.
lint, purify, energize, ...
> Computer Science seems stuck in a rut because of its religious adherence to
> ancient software development technologies.
Like object orientation, functional programming, etc?
> The arguments over which aging
> programming language is better is a symptom of the problem.
I suggest you examine the literature and get back to us.
Michael G. Phillips
: In article <CLAIBORN.9...@ojnklet.ctron.COM>, clai...@ctron.COM (Christian L Claiborn) writes:
: |> In article <davew.793771626@hickory422> da...@cray.com (Dave Wagner) writes:
: |>
: |> Come on. There are equivalent "silent errors" in C too..
: |>
: |> for (i=0,i<10,i++);
: |> {
: |> some stuff
: |> }
: |>
: |> What's the 'silent error' here?
: See that semi-colon at the end of the for(...); ?
: How many times does the programmer/reader expect "some stuff" to be executed?
Is the point that "i=0;i<10;i++" was probably intended too *obvious* ?
^ ^
-michael
: --
: Anil A. Pal
: p...@sgi.com (415)-390-5279
Makoto Shimojima, Univ of Tsukuba/CDF
I don't know what the language of the year 2000 will look like,
but I know it will be called FORTRAN. --- Tony Hoare
Richard E. Hodges
PC Week (you can read it on the Ziff-Davis WWW site) regarding C++
that may be of interest to those reading this thread. Here's the
"meat" of it:
Excerpt from Peter Coffee's article:
> To those who say that it's all over, that C++ has already won,
> I say "piffle." During the Software Development show, I also chaired
> a panel on dynamic object-oriented programming. Panelist Stephen
> McClure, of International Data Corp., presented the results of a
> survey of more than 600 companies with more than 500 employees,
> of whom more than half had not yet begun their evaluation of
> object-oriented technologies.
>
> Only a tenth of those companies had adopted an object-oriented
> language in production applications. Not only has the fat lady yet
> to sing, she hasn't even started to learn the music.
Anil A. Pal
|> Anil A. Pal (p...@xanadu.engr.sgi.com) wrote:
|> : In article <CLAIBORN.9...@ojnklet.ctron.COM>, clai...@ctron.COM (Christian L Claiborn) writes:
|> : |> In article <davew.793771626@hickory422> da...@cray.com (Dave Wagner) writes:
|> : |>
|> : |> Come on. There are equivalent "silent errors" in C too..
|> : |>
|> : |> for (i=0,i<10,i++);
|> : |> {
|> : |> some stuff
|> : |> }
|> : |>
|> : |> What's the 'silent error' here?
|>
|> : See that semi-colon at the end of the for(...); ?
|> : How many times does the programmer/reader expect "some stuff" to be executed?
|>
|> Is the point that "i=0;i<10;i++" was probably intended too *obvious* ?
Well, it's obvious enough that the compiler will complain, so it's not
a 'silent' error. I read it as you did : "i=0;i<10;i++", with an
inadvertent ; causing a null for loop.
Peter da Silva
Rich R Car <rich...@beep.roadrunner.com> wrote:
> Peter da Silva (pe...@nmti.com) wrote:
> : C was already popular by the early '80s, before the "free" compilers had
> : any significant impact on the market.
> I never saw a C compiler that anyone charged for until nearly 1980.
What were you working on in the '70s? C compilers for microcomputers were
popping up all over the place, because there simply wasn't an alternative
for low level programming. PL/M was sort of a holy grail, but Intel
charged a bomb for it... and if they hadn't you'd probably be bitching
about how crummy a language *it* was. There was Small-C, but it wasn't
really useful for much of anything... the best shot at writing portable
code on CP/M systems was Forth or BDS-C, and BDS was commercial. There
was also Marc Williams and Whitesmiths. Whitesmiths was about as expensive
as CP/M, but it produced bloody good code and with a little care you could
write your stuff in BDS and port it to Whitesmiths after you got some
revenue and could afford it.
What other systems level languages were there? Forth (flavor of the month),
Pascal (try getting two compilers on the same platform eat the same code),
Fortran (plus lots and lots of assembly), PL/M (if you want to marry Intel),
or assembler. PL/I and other big system languages were unworkable on machines
with a 48K TPA.
Getting a UNIX system in this market was laughable. Even if it was available,
who could afford the PDP-11s and the like?
But it's this pool of talent that developed into the MS-DOS world, and it's
these people that are responsible for C being popular there.
Anyway, this is getting more appropriate for alt.folklore.computers so I'm
pointing it back there.
Charles Lasner
!In <3irbj2$s...@umbc8.umbc.edu> rda...@umbc.edu (R. D. Davis) writes:
!
!>In article <3il124$p...@dux.dundee.ac.uk>,!>>just because they always have in the past. It might mean learning
!>>something else, but if the argument had that much merit, they'd still be
!>>using PDP-8s...
!>
!>What, pray tell, is wrong with using PDP-8s? I don't have a PDP-8
!>yet, but do have some PDP-11s. I'd rather have a PDP-8 than a kludgy
!>IBM type toy PC... I'm glad that I've gor PDP-11s, PERQs and CP/M (and
!>MP/M) machines to use instead.
!
!There is absolutely nothing wrong with using PDP-8s. Pete just mentioned
!a fact: most people who used PDP-8s sometime in the past (they've been
!introduced 30 years ago) are using something else _today_. Do you
!disagree? If not, what is your point?
!
!Dan
!--
!Dan Pop
!CERN, CN Division
!Email: dan...@cernapo.cern.ch
!Mail: CERN - PPE, Bat. 31 R-004, CH-1211 Geneve 23, Switzerland
MAny of us on alt.sys.pdp8 still do use PDP-8's as we also use other
machines for other purposes. If for no other reason, it serves as a good
basis to understand how other computers work. (BTW, how many people out
there really don't have a clue how a computer really works, i.e., all
computers are some sort of magic executor of C source code in compiled
form by dark grey magic means not important enough for them to bother
finding out about, etc.)
cjl
Mark Hedley
: In article <davew.793771626@hickory422> da...@cray.com (Dave Wagner) writes:
: Come on. There are equivalent "silent errors" in C too..
: for (i=0,i<10,i++);
: {
: some stuff
: }
: What's the 'silent error' here?
: Not that I think this war has any merit, but I don't understand what's
: not clear about this fragment.
: christian
: --
: Christian Longshore Claiborn - Cabletron Systems Inc.
: "You mean on top of everything else, this ship is rigged?" -- Stan Freberg
Not so silent to any C programmer! Misplaced semi-colon aside, the
two commas are also screamingly apparent....
I agree that this war is getting boring
Peter da Silva
> of the most *aggressive* ways of pushing it. The idea that C became popular
> withoug being pushed is laughable.
C was already popular by the early '80s, before the "free" compilers had
any significant impact on the market.
C really became popular because it was easy enough to implement, with the
compiler technology of its day, and it was complete enough by the standards
of the day that really badly incompatible variants didn't take root. Pascal
was simpler (it was designed so a one-pass compiler was possible), but too
much was unspecified. Fortran didn't really address system programming, and
besides was a more complex language. PL/M was another "small" high level
language, but Intel played it pretty close to its chest.
Mike Van Der Meulen
>In article <D4I0G...@seas.ucla.edu> hod...@breeze.seas.ucla.edu (Richard E. Ho
>dges) writes:
>
> I would be interested if you could show the equivalent ANSI standard
> C program equivalent of the following simple program:
>
> program test
> complex aj, sum, x(10), b(10), A(10,10)
> aj = cmplx(0.,1.)
> do 10 i=1,10
> do 10 j=1,10
> do 20 i=1,10
> 20 x(i) = ccos(cmplx(real(i),real(j)))
> do 30 i=1,10
> sum = cmplx(0.,0.)
> do 40 j=1,10
> 40 sum = sum + A(i,j)*x(j)
> 30 b(i) = sum
> do 50 i=1,10
> 50 write(*,*) b(i)
> stop
> end
>
>
> (88510.2,-292106.)
> (96645.7,-217322.)
> (159225.,-167454.)
> (230253.,-176861.)
> (255968.,-225404.)
> (224269.,-256963.)
> (175840.,-231033.)
> (166747.,-159964.)
> (216892.,-97606.5)
> (291711.,-89802.1)
>
(someone reponded with the following C++ code):
>Ok, here is the equivalent C++ code:
>
>#include <stream.h>
>#include <complex.h>
>
>
>main()
>{
> Complex aj(0,1), sum, A[10][10], x[10], b[10] ;
> int i,j ;
>
> for(i=0;i<10;i++)
> for(j=0;j<10;j++)
> A[i][j] = Complex(aj*abs(i-j)) ;
>
> for(i=0;i<10;i++)
> x[i] = cos(Complex(i+1,j+1)) ;
>
> for(i=0;i<10;i++) {
> sum = 0 ;
> for(j=0;j<10;j++)
> sum = sum + A[i][j]*x[j] ;
> b[i] = sum ;
> }
>
> for(i=0;i<10;i++)
> cout << b[i] << "\n" ;
>}
>
>Output:
>ike% !g++
>g++ c.cc -lm
>ike% a.out
>(88510.2, -292106)
>(96645.7, -217322)
>(159225, -167454)
>(230253, -176861)
>(255968, -225404)
>(224269, -256963)
>(175840, -231033)
>(166747, -159964)
>(216892, -97606.5)
>(291711, -89802.1)
(then the following BASIC program showed up):
>Just for the helluvit, I transcribed this into Rocky Mountain BASIC. Not
>relevant to th argument, but here's the transcription:
>
>10 ! program test
>20 COMPLEX Aj,Sum,X(10),B(10),A(10,10)
>30 Aj=CMPLX(0.,1.0)
>40 FOR I=1 TO 10
>50 FOR J=1 TO 10
>60 A(I,J)=Aj*ABS(I-J) ! CMPLX not needed here
>70 NEXT J
>80 NEXT I
>90 FOR I=1 TO 10
>100 X(I)=COS(CMPLX(I,J)) ! REAL casts not needed here
>110 NEXT I
>120 FOR I=1 TO 10
>130 Sum=CMPLX(0.,0.)
>140 FOR J=1 TO 10
>150 Sum=Sum+A(I,J)*X(J)
>160 NEXT J
>170 B(I)=Sum
>180 NEXT I
>190 Cmplx_image:IMAGE "(",DDDDDD.D,",",DDDDDDD.D,")" ! Make it pretty
>200 FOR I=1 TO 10
>210 PRINT USING Cmplx_image;B(I)
>220 NEXT I
>230 END
> OUTPUT:
>Here is the output (I couldn't quite figure out your format algorithm):
>( 88510.2,-292106.0)
>( 96645.7,-217321.7)
>(159224.6,-167453.7)
>(230252.9,-176860.7)
>(255968.4,-225404.1)
>(224269.1,-256963.4)
>(175840.0,-231033.4)
>(166747.4,-159964.1)
>(216891.8, -97606.5)
>(291711.5, -89802.1)
I promised myself that I'd never get sucked into a flame war again on the
topic of what's the best programming language, but since this has been a
somewhat civil discussion so far and there are concrete examples involved,
I thought I'd take a few moments and offer another language solution to
add to the Fortran, C++, and BASIC programs above, to remind us that there
are some other functional array-based languages around that may offer a
different programming paradigm for parallel processing (for those who feel
that all three of the solutions shown above look essentially the same... just
wearing slightly different make-up ;-).
As a user of several different programming languages, I would never try to
defend any one language as the best solution for all problems. As my great
great granddaddy said:
- if it feels good, wear it
- live and let live
- use the right tool for the job
- sometimes forget about the previous rule... and just get the job done!
- "FOR" all cows 1 to 40, "DO" milk them (maybe I remember this one wrong)
- variety is the spice of life
- if everyone's likes were the same, it'd be harder to find a date Friday night
In the example below, minor changes were made to avoid use of special APL
characters for the assignment arrow and comment symbol. The functions
interval, abs, cos, and sum are simply defined cover functions that map
directly to the primitive APL function symbols. The function "x" represents
the APL times (multiply) symbol. "table" is a defined operator that takes
the function "-" (subtract) to produce a derived function that applies "-" to
all elements on the left (I) with all elements on the right (I)... an
all-to-all operation (this again is just a cover for the primitive operator
called outer-product in APL, which has its own special symbol).
The function was written to handle variable-size arrays, as is natural in APL.
When I first translated the Fortran code above and ran the function, I found
that it produced a different result. This was because I originally used "N"
instead of "(N+1)" in line 6 below. I forgot that Fortran had bumped the "j"
counter to 11 before exiting the previous loop (a fairly subtle side-effect
for those of us with aging memory cells). One might argue that use of direct
array operations helps to eliminate accidents with explicit loop counters (not
to mention the programmer productivity issues) - I believe that Fortran 90
and HPF offer at least a step in the right direction in this regard.
...and, finally, before someone jumps in and asks why I wasted 4 lines to
write a simple APL one-liner, let me just say that my great great granddaddy
used to say that just because you CAN do something...
[0] B <- Test N
[1] # APL2 version of simple FORTRAN/C++/BASIC program shown above
[2] # N = (input) size of array to calculate
[3] # B = (output) vector (of length N) of complex numbers generated
[4] I <- interval N # generate interval vector... i.e. [1,N]
[5] A <- 0J1 x abs I (- table) I # generate complex number table (matrix)
[6] X <- cos I + (N+1) x 0J1 # create the vector of complex cosines
[7] B <- sum A x[2] X # row-wise (axis 2) multiply and summation
# The following statement executes the Test function for an array size of 10
# and displays the vector result as a one-column matrix in a form similar to
# the other examples (print precision was set to 6 to match the Fortran output)
,[1.5] Test 10
88510.2J-292106
96645.7J-217322
159225 J-167454
230253 J-176861
255968 J-225404
224269 J-256963
175840 J-231033
166747 J-159964
216892 J -97606.5
291711 J -89802.1
As for performance, with all of the cross-breeding going on these days
between the interpreter and compiler folks, there may be a couple of
little surprises yet to come in future parallel computing races...
Charles Lasner
!In article <3il124$p...@dux.dundee.ac.uk>,
!
!>just because they always have in the past. It might mean learning
!>something else, but if the argument had that much merit, they'd still be
!>using PDP-8s...
!
!yet, but do have some PDP-11s. I'd rather have a PDP-8 than a kludgy
!IBM type toy PC... I'm glad that I've gor PDP-11s, PERQs and CP/M (and
!MP/M) machines to use instead.
!
!--
!R. D. Davis * Eccentrics have more fun! :-) * http://access.digex.net/~rdd
!rda...@umbc.edu, ...uunet!mystica!rdd > "Today's busy world" isn't "busy";
!Home telephone: 1-410-744-7964 > it's just grossly mismanaged by
!Work (play!) telephone: 1-410-744-4900 > idiots, businesses and governments.
Most of us on alt.sys.pdp8 do have PDP-8's in one form or another, and
many also have -8 simulators. Curiously, some run on PC's and MAC's.
cjl
Nick Maclaren
The Wankmiester <Wan...@Umass.Edu> wrote:
>In article <3igiad$f...@Starbase.NeoSoft.COM>, wi...@Starbase.NeoSoft.COM (Will Morse) says:
>>
>>Comparing C and Fortran is a little like comparing a screwdriver
>>and a chisel. They have some superficial similarities, but they
>>are really different tools.
>
>Comparing Fortran and C is like comparing an aging poor quality
>screw-driver with an all-in one tool (that can also perform that
>aging screw-drivers job faster, easier, and more reliably in
>addition to numerous other tasks).
As I say in some of my talks about C, this is quite true. What the
C fanatics do not say is that all the safety devices have been
removed and the manual is in Japanese :-) This usually gets a
laugh, and occasionally people think about what I mean by it.
>>C should more properly be compared to various assembler languages.
>>It is intended for system level stuff and places where you have to
>>get at things that "high level languages" don't normally get to.
>>
>
>Actually C should be compared with assembler AND other high
>level languages. C provides all the power that high level
>languages offer (if not more) plus the functionality of assembler.
This is either facile (i.e. any Turing machine can do anything) or
nonsense. On systems where the operating system interface is not
C (such as IBM MVS), it is necessary to go down into assembler to
reach those facilities that C doesn't provide.
Also, try doing EFFICIENT multi-length integer arithmetic in C.
Where is BCPL's muldiv() function, for example?
Nick Maclaren,
University of Cambridge Computer Laboratory,
New Museums Site, Pembroke Street, Cambridge CB2 3QG, England.
Email: nm...@cam.ac.uk
Tel.: +44 1223 334761 Fax: +44 1223 334679
Christian L Claiborn
Rich R Car
: Rich R Car <rich...@beep.roadrunner.com> wrote:
: > For "readibly available" read "Free". Giving away anything for free is one
: > of the most *aggressive* ways of pushing it. The idea that C became popular
: > withoug being pushed is laughable.
: C was already popular by the early '80s, before the "free" compilers had
: any significant impact on the market.
I never saw a C compiler that anyone charged for until nearly 1980. C/UNIX
was distributed free (OK, a negligable tape copy fee was sometimes charged)
to universities and such throughout the mid '70s. That free distribution
amounts to the most aggressive of ad campaigns I've ever seen. The Free
compilers were the *only* impact on the C market in the '70s - nobody was
buying any C compilers.
I have more to say, but this is crossposted beyond belief. The rest is
in comp.lang.fortran.
Cheers.
Anil A. Pal
|>
|> Come on. There are equivalent "silent errors" in C too..
|>
|> for (i=0,i<10,i++);
|> {
|> some stuff
|> }
|>
|> What's the 'silent error' here?
See that semi-colon at the end of the for(...); ?
How many times does the programmer/reader expect "some stuff" to be executed?
--
Dan Pop
>In article <davew.793771626@hickory422> da...@cray.com (Dave Wagner) writes:
>
> Come on. There are equivalent "silent errors" in C too..
>
> for (i=0,i<10,i++);
> {
> some stuff
> }
>
>What's the 'silent error' here?
>
>Not that I think this war has any merit, but I don't understand what's
>not clear about this fragment.
Well, if you replace the commas by semicolons :-) it's the C equivalent of
DO 10 I = 0. 9
some stuff
10 CONTINUE
The only difference is that the Fortran version doesn't change the value
of I (assuming that such a variable exists in the Fortran program).
Dan
--
Dan Pop
CERN, CN Division
Email: dan...@cernapo.cern.ch
Del Cecchi
|> In <3iva62$7...@unogate.unocal.com> stg...@sugarland.unocal.COM (Richard Ottolini) writes:
|>
|> >In article <D4o1w...@news.cern.ch>, Dan Pop <dan...@cernapo.cern.ch> wrote:
|> >>The best example is C, which became popular without being pushed by
|> >>anybody. People saw it, tried it, liked it. The commercial success
|> >>came by itself.
|> >
|> >Part of the reason C became popular was that its compiler source code
|> >was readily available. This was partly because of its link with
|> >UNIX which was also readily available. Therefore C became available
|> >on wide variety of machines of different sizes.
|>
|> a single machine: the PDP-11. After this, Unix entered its commercial
|> life, and many companies made a lot of money selling Unix and C compilers.
|>
|> PDP-8 to the big CDC-7600.
|>
|> Dan
|> --
|> Dan Pop
|> CERN, CN Division
|> Email: dan...@cernapo.cern.ch
|> Mail: CERN - PPE, Bat. 31 R-004, CH-1211 Geneve 23, Switzerland
universities for many years by ATT/Bell Labs?
--
Del Cecchi
cec...@vnet.ibm.com
Burak Bayramli
>
>In article <3iugtn$3...@gazette.engr.sgi.com> ka...@audio.esd.sgi.com (Bruce Karsh) writes:
>
> The question "why do we still have to use Fortran" is a good one. But my
> question is "why do we still use C".
>
> old. What kind of high technology is it whose tools have changed so little
> over so much time?
>
>How old is the technology of wrenches, hammers, or axes? Just because
>a technology is old does not mean it is obsolete.
Of course it does, especially in 1995 after 20 years of rapid growth
in technology in all areas. At 14th century, fifty years might not
matter but at 20th century, even *days* are important.
>
>-Ed
>
>--
>Mail: segmentation violation -- core dumped
*****************************************************************
* *
* Burak Bayramli *
* *
* Stevens Institute of Technology *
* *
*****************************************************************
Burak Bayramli
>
>
>: Interestingly, other engineering disciplines have not been so
>: backwards. They have developed computerized engineering tools which do
>: all of these things. While software engineers argue about Fortan vs C,
>: the other fields continue to use better and better tools. Engineers in
>: other disciplines regularly use graphical design tools, design rule checkers,
>: simulations etc., to make sure that their designs are correct. We mostly
>: use cc, dbx, etc, and then let end-users be the final testers.
>
>
> And which languages are *all* those "computerized engineering tools"
> written in???
>
> -michael
You can use the tool to write the tool itself. It might sound kind of
recursive there, but after you get the first version with whatever
crappy language you use, your second version will
be developed with the help of your tool.
For example ISE Eiffel compiler and its GUI environment was written
in Eiffel.
I can give you more info how this is being done.
>
>: Computer Science seems stuck in a rut because of its religious adherence to
>: ancient software development technologies. The arguments over which aging
>: programming language is better is a symptom of the problem.
>--
> --------------------------------------------------------------------
> Michael G. Phillips mg...@crl.com mg...@atldbs.dbsoftware.com
> (404)239-2766 "Just because it worked doesn't mean it works." -- me
*****************************************************************