Fortran - Is FORTRAN a dying language? (not a troll)

Author

Is FORTRAN a dying language? (not a troll)

Curious

2004-05-12, 9:08 pm

This is a serious question. Is FORTRAN a dying language?

I ask, because today at work (I'm an engineer) we were briefly debating
the merits of two software packages for systems engineering, in
preparation for adopting one for our work. The older package was
written in FORTRAN, while the newer package was written in C. They are
both equivalent in features -- in fact, the newer, C-based code was
pretty much a direct copy of the elder FORTRAN code, and had some of the
original FORTRAN developers behind it.

My boss (who is an engineer in his 60's) was in favor of the older
FORTRAN based program, because it's the incumbent, basically. I
favored the newer code, arguing that since "all else is equal, why
should we pick a code written in a dying language? We're going to be
writing our own code to work with it, that will need to be used for
DECADES."

My boss immediately attacked me, saying that FORTRAN is NOT a dying
language, that is alive and well, and that it will be viable in 2030,
like it was in 1970. "You ever hear of COBAL? It's the worst
language ever invented, and your banks STILL run software written in it
-- COBAL will never die."

Personally, I think my boss hasn't been on a college campus in decades,
and has no idea of the extent to which FORTRAN has been on the decline.
The industry we work in is very specialized and there aren't a lot of
young engineers in it, so we aren't exposed to the changes going on in
the computer science field. And we don't write or update much code...
MOST of the codes we use were written before I was born!!

I'm not here to attack FORTRAN. I'm just trying to make a good
business decision, because it will impact our industry for several
decades at least. To me, it's a very simple equation: in computers,
technology is either growing, or it's DYING. Just because there are
people running OS/2 doesn't mean it's not dying. So, the question to
me is: are there more people programming in FORTRAN today than there
were five years ago? And, will many engineering graduates in 2020 be
proficient in FORTRAN?

kia

2004-05-12, 9:08 pm

Curious wrote:
>
> This is a serious question. Is FORTRAN a dying language?

You bet, just last month several million folks went checking how dead is
dead. See the obituaries in "netlib 04" post!

Phillip Helbig---remove CLOTHES to reply

2004-05-12, 9:08 pm

In article <Xns94E2E1FC7371Default664@199.45.49.11>, Curious
<Curious@person.net> writes:

> This is a serious question. Is FORTRAN a dying language?
>
> I ask, because today at work (I'm an engineer) we were briefly debating
> the merits of two software packages for systems engineering, in
> preparation for adopting one for our work. The older package was
> written in FORTRAN, while the newer package was written in C. They are
> both equivalent in features -- in fact, the newer, C-based code was
> pretty much a direct copy of the elder FORTRAN code, and had some of the
> original FORTRAN developers behind it.
>
> My boss (who is an engineer in his 60's) was in favor of the older
> FORTRAN based program, because it's the incumbent, basically. I
> favored the newer code, arguing that since "all else is equal, why
> should we pick a code written in a dying language? We're going to be
> writing our own code to work with it, that will need to be used for
> DECADES."

Let me ask the following question: If you are talking about running the
code for decades, how certain are you that C will be around that far in
the future?

Apparently, the port has already been done. I think the argument "port
to language B since language A is dying" is bogus: if language A really
does die, you can port later, with the same (or less) effort.

> My boss immediately attacked me, saying that FORTRAN is NOT a dying
> language, that is alive and well, and that it will be viable in 2030,
> like it was in 1970. "You ever hear of COBAL? It's the worst
> language ever invented, and your banks STILL run software written in it
> -- COBAL will never die."

First, COBOL is not necessarily a bad language. Second, it is true that
not only are COBOL programs still running the financial world, but NEW
CODE is being written in COBOL as well.

> Personally, I think my boss hasn't been on a college campus in decades,
> and has no idea of the extent to which FORTRAN has been on the decline.
> The industry we work in is very specialized and there aren't a lot of
> young engineers in it, so we aren't exposed to the changes going on in
> the computer science field. And we don't write or update much code...
> MOST of the codes we use were written before I was born!!

Personally, I wouldn't take the opinion du jour of college campuses as
an indicator of what will be good future business practices.

> I'm not here to attack FORTRAN. I'm just trying to make a good
> business decision, because it will impact our industry for several
> decades at least. To me, it's a very simple equation: in computers,
> technology is either growing, or it's DYING.

False dichotomy. It can be extraordinarily stable as well.

> Just because there are
> people running OS/2 doesn't mean it's not dying. So, the question to
> me is: are there more people programming in FORTRAN today than there
> were five years ago? And, will many engineering graduates in 2020 be
> proficient in FORTRAN?

How many do you need?

Helge Avlesen

2004-05-12, 9:08 pm

Curious <Curious@person.net> writes:

| This is a serious question. Is FORTRAN a dying language?

no, but it has not seen the explosive growth of other 'pop'
languages. the main advantage of fortran as I see it is that it
attracts people that are seriously interested in what they do, look
e.g. at the signal to noise ratio in this news group. the number of
commercial compilers available (see e.g.
http://www.fortran.com/fortran/metcalf.htm)
I think is a very good indicator on how alive fortran is.

as a saturday morning excercise I used google to approximate the
number of comp.lang.fortran postings per year, and got

1992 3840
1993 5330
1994 7080
1995 10500
1996 9510
1997 12930
1998 11670
1999 12940
2000 12840
2001 13410
2002 13580
2003 15710
2004 18800 (?. this is what google reports so far this year)

so 'fortran is dying' is not the first conclusion I would make from
these numbers. newsgroups has got a lot of competition from all kinds
of online discussion fora.

Another advantage of Fortran is that it is easy to learn; the 'Hello
world' excercise is e.g. a two line program

print *,'Hello world'
end

more advanced features and 'safe practices' can be taught step by step
from there. this is far more ugly and confusing for a non programmer
in the C family of languages. I would also not worry about sparsity of
fortran programmers for maintaining future software - since it is easy
to learn, any decent programmer can pick up fortran and be productive
in a few days. picking an easy to use language also opens up for
training non programmers (scientists) and let them contribute
directly.

--
Helge

Hendrik van Hees

2004-05-12, 9:09 pm

Curious wrote:

> This is a serious question. Is FORTRAN a dying language?

I'm a physicist, working in theoretical heavy ion physics, to be precise
in quantum field theory at finite temperature and do many numerical
calculations, all in FORTRAN.

The main reason is that my thesis advisor some years ago, suggested to
use FORTRAN, because he uses it and if there are problems with
programming he could better help me. So I came to FORTRAN, although at
this time, when had freshly heard about modern computer languages
(Darmstadt in Germany has a good IT faculty). There all were telling us
that a programming language should be object oriented etc. etc.

Before I made my decision whether to use FORTRAN or not, I told with
some people around the lab, where I did my diploma and PhD thesis (GSI
in Darmstadt, the heavy ion facility in Germany) and there the most
people also used FORTRAN. A colleague who is really very good in
computing used a mixed code in C (for I/O) and FORTRAN (for the
numerics). Then he told me, recently he has ported everything to C++,
because now the C++ compilers are as good in producing good performing
numerics code as FORTRAN.

I use FORTRAN now, because I am used to it, I can use some routines, I
wrote before in new programs (also it would not be any problem to write
new code in C and link older FORTRAN code to it). Another reason is
that there are many numerical routines around which are written in
FORTRAN and can be used for my own work. For instance, at the moment, I
am calculating some integrals in quantum field theory, which are quite
difficult from the viewpoint of numerics, because they have some sharp
structures in the integrand, of which I do not know the precise
position. Until yesterday I used a own little adaptive routine, which
did a rather good job with nice results. But then it came to a problem
where I had to calculate not only 1-dimensional or 2-dimensional
integrals but 3-dimensional, and my very simple program became too
slow. It took not more than 10 minutes to find a very effective, freely
available adaptive integrator for exactly the task I had to solve
(dcuhre by Genz et al, if somebody knows something better, I'd
appreciate to hear about it :-)). It took only very little effort to
use this routine within my own code. So I think FORTRAN is not dying,
but it's used pretty much in our field of computing.

Another proof for this statement: In the mean time I also was a postdoc
in Bielefeld, where one of the leading experts in lattice gauge
theories are working. That's a highly challenging field for
computational physics, needing big high-performance computer clusters
and parallization, to solve Quantum Chromo Dynamics, the underlying
theory which explains what the atomic nuclei holds together. They also
use FORTRAN, but specialized to parallelizing code, running on machines
which itself are specialized to do these lattice calculations. So,
there is even some development of FORTRAN, although in this case for a
very specialized task.

I am not an IT expert, but I'd say the decision, you have to make, is
indeed more a question of usability, as you already mentioned. So most
important is not the technical question, which is the better language,
because I guess the performance of the binary code, coming from a
modern FORTRAN compiler is not better than one coming from a modern C
compiler anymore (this was the case some years ago, at least under the
GNU compiler family under Linux, concerning performance in "number
crunching").

The right question to ask is, who will use the code. Will you have the
source code available? Are you intending to use it in own software
development? What language are your engineers most familiar with
(although I think it is not a big problem to learn a new programming
language, because the really challenging subject is more to invent
efficient algorithms than to implement them in the one or the other
programming language, but it costs time to become familiar with a new
language, and I guess time is money)?

--
Hendrik van Hees Cyclotron Institute
Phone: +1 979/845-1411 Texas A&M University
Fax: +1 979/845-1899 Cyclotron Institute, MS-3366
http://theory.gsi.de/~vanhees/ College Station, TX 77843-3366

Curious

2004-05-12, 9:09 pm

helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to
reply) wrote in news:c7i67g$2gp$3@online.de:

> Let me ask the following question: If you are talking about running
> the code for decades, how certain are you that C will be around that
> far in the future?

It's true the computer industry is always changing, but the simplist
indicator to me of a future language's supportability is how many young
people are building their skills in that language. Even if "wonder
language" comes out next year and becomes the dominant language, today
there are hordes of 20 year olds proficient in C, so that forty years from
now, odds are we could find quite a few engineers that could dust off the
code and make use of it.

> Apparently, the port has already been done. I think the argument
> "port to language B since language A is dying" is bogus: if language A
> really does die, you can port later, with the same (or less) effort.

Not in this case. We're engineers (government, actually), not
programmers. We're going to adopt a particular software product (along
with the contractors we work with), and then write additional code in that
language that models the behavior of hardware that could need to be
supported FIFTY years from now. So, it's key for us to have engineers
that understand both the computer language AND the hardware the code was
used to model. We can't just grab programmers off the street and say
"port this".

At a company I used to work at in the same industry, we had ONE 65 year old
engineer that knew both the (obsolete) modeling software and understood the
hardware that he modeled using the software (something of an art). When
he retired, all knowledge of modeling that hardware was lost.

The scenario I see coming is some time in the future, we hire a young
engineer out of college and ask him to update a model -- I think it's
probable that he'll not know FORTRAN.

>
> First, COBOL is not necessarily a bad language. Second, it is true
> that not only are COBOL programs still running the financial world,
> but NEW CODE is being written in COBOL as well.

Out of curiosity, what compilers are they using?

See, in our case, we're engineers who are highly specialized in the
technology we're developing, and programming skills are secondary.

So, this is what I think my boss is missing... FORTRAN may be alive and
well TODAY, but if it becomes the COBOL of tomorrow, that's a lethal
combination for our industry.

>
> False dichotomy. It can be extraordinarily stable as well.

Maybe I'm thinking too much in terms of hardware, or mainstream software,
where compatibility issues make it impossible to continue using out of
favor technology. I was kind of spooked that Microsoft dropped their
FORTRAN compiler. But I guess this isn't the same as us deciding to store
our data on 5-1/2" disks.

Ken Plotkin

2004-05-12, 9:09 pm

On Sat, 08 May 2004 05:12:54 GMT, Curious <Curious@person.net> wrote:

>This is a serious question. Is FORTRAN a dying language?

Yes. We all die. Everything eventually dies.

But Fortran is not dying any faster than other languages. Probably
slower. A lot of languages have gone through their complete life
cycles in Fortran's lifetime.

>I ask, because today at work (I'm an engineer) we were briefly debating
>the merits of two software packages for systems engineering, in
>preparation for adopting one for our work. The older package was
>written in FORTRAN, while the newer package was written in C. They are
>both equivalent in features -- in fact, the newer, C-based code was
>pretty much a direct copy of the elder FORTRAN code, and had some of the
>original FORTRAN developers behind it.

Why was it rewritten in C?

>My boss (who is an engineer in his 60's) was in favor of the older
>FORTRAN based program, because it's the incumbent, basically. I
>favored the newer code, arguing that since "all else is equal, why
>should we pick a code written in a dying language? We're going to be
>writing our own code to work with it, that will need to be used for
>DECADES."

It depends on who will be maintaining it. If it'll be engineers,
stick to Fortran. If it'll be programmers, go for C. But expect the
programmers to want to rewrite it again, into C++.

>Personally, I think my boss hasn't been on a college campus in decades,

You say that like it's a bad thing.

[snip]
>people running OS/2 doesn't mean it's not dying. So, the question to
>me is: are there more people programming in FORTRAN today than there
>were five years ago? And, will many engineering graduates in 2020 be
>proficient in FORTRAN?

Never mind that. Will they be proficient in engineering? :-)

But if you want to focus this on what engineering students are really
learning and using today, convert the package to Matlab.

Ken Plotkin

beliavsky@aol.com

2004-05-12, 9:09 pm

Curious <Curious@person.net> wrote in message news:<Xns94E2E1FC7371Default664@199.45.49.11>...
> This is a serious question. Is FORTRAN a dying language?

Since the Fortran 90 standard it is spelled "Fortran", not "FORTRAN".

A dying language would not be able to support as many compiler vendors
as are listed at http://www.dmoz.org/Computers/Progr...tran/Compilers/
.. In addition, the language continues to evolve -- Fortran 2003
compilers are currently under development. OTOH, I have read that
fewer people are volunteering to serve on Fortran standards committees
now than for the Fortran 90 standard, delaying progress and partly
explaining why Fortran 2000 became 2003. Read the posts of Steve
Lionel of Intel Fortran to get the views of a leading compiler vendor.

The Advanced Placement Computer Science Exam (taken by U.S. high
school students) has just switched from C++ to Java, because that is
what college computer science departments want. In the future, you may
not be able to count on college graduates being proficient in C++. If
they are proficient in Matlab, switching to Fortran 95 may be easier
than to C++.

Richard Maine

2004-05-12, 9:09 pm

beliavsky@aol.com writes:

> Curious <Curious@person.net> wrote in message news:<Xns94E2E1FC7371Default664@199.45.49.11>...
>
> Since the Fortran 90 standard it is spelled "Fortran", not "FORTRAN".

Indeed. Which suggests that perhaps the reason that the OP thinks it
is dying is because he thinks that the Fortran of today is the same
as the FORTRAN of 25 years ago. It isn't.

Btw, as expected, wg5 yesterday voted to submit the current draft
as a DIS (draft international standard), which means it next has
a 2-month country vote on whether to make it a standard (just yes/no
votes at this stage - no changes allowed).

Yes FORTRAN (as in f77 and earlier) is dying, although it has quite a
long ways to go yet in terms of existing code. Fortran (as in f90
and later) is growing. Not at the pace of the volatile fads of the
day, but steadily.

--
Richard Maine
email: my last name at domain
domain: sumertriangle dot net

beliavsky@aol.com

2004-05-12, 9:09 pm

Curious <Curious@person.net> wrote:

>Maybe I'm thinking too much in terms of hardware, or mainstream software,

>where compatibility issues make it impossible to continue using out of
>favor technology.

The Fortran 2003 standard mandates that Fortran be interoperable with C.

>I was kind of spooked that Microsoft dropped their
>FORTRAN compiler. But I guess this isn't the same as us deciding to store

>our data on 5-1/2" disks.

Microsoft decided, probably correctly, that another company (Digital) could
do a better job with Fortran. I hope that Intel's entry into the Fortran
compiler market has unspooked you. Intel Fortran descends from Digital.

(Lahey is not so well known as Microsoft or Intel outside the Fortran community,
but it is arguably as good as Intel Fortran, depending on your needs. Bigger
companies do not always make better products, especially when
you get beyond the flagship products.)

Madhusudan Singh

2004-05-12, 9:09 pm

On Saturday 08 May 2004 01:12, Curious (Curious@person.net) held forth in
comp.lang.fortran (<Xns94E2E1FC7371Default664@199.45.49.11> ):

> This is a serious question. Is FORTRAN a dying language?
>

First of all, get the case right. It is called Fortran these days.

> I ask, because today at work (I'm an engineer) we were briefly debating
> the merits of two software packages for systems engineering, in
> preparation for adopting one for our work. The older package was
> written in FORTRAN, while the newer package was written in C. They are
> both equivalent in features -- in fact, the newer, C-based code was
> pretty much a direct copy of the elder FORTRAN code, and had some of the
> original FORTRAN developers behind it.
>
> My boss (who is an engineer in his 60's) was in favor of the older
> FORTRAN based program, because it's the incumbent, basically. I
> favored the newer code, arguing that since "all else is equal, why
> should we pick a code written in a dying language? We're going to be
> writing our own code to work with it, that will need to be used for
> DECADES."

From the sound of it, you seem to be talking about FORTRAN 66 and 77. Yes,
those languages are dying, and rightly so. They are 25-40 years old and do
not support modern Fortran constructs (barring vendor specific extensions
in some cases) like pointers, some OOP, operator overloading, etc. The same
way, older archaic versions of C are dying in favor of C++, etc.

However, in each case (Fortran / FORTRAN and old C / c89), the old code is
largely interoperable with the new one.

>
> My boss immediately attacked me, saying that FORTRAN is NOT a dying
> language, that is alive and well, and that it will be viable in 2030,
> like it was in 1970. "You ever hear of COBAL? It's the worst
> language ever invented, and your banks STILL run software written in it
> -- COBAL will never die."
>
> Personally, I think my boss hasn't been on a college campus in decades,
> and has no idea of the extent to which FORTRAN has been on the decline.
> The industry we work in is very specialized and there aren't a lot of
> young engineers in it, so we aren't exposed to the changes going on in
> the computer science field. And we don't write or update much code...
> MOST of the codes we use were written before I was born!!
>

Which must a testament to how well written that code must have been.
Further, the dichotomy between computer science and web development people
(who go for languages like C++, Eiffel, Smalltalk, Java, etc.) and
engineers and scientists (who go for languages like FORTRAN, Fortran,
MATLAB, Mathematica, some C, etc.) has existed for decades, and has
naturally widened. The thrust of each field is different, so it is hardly
surprising that they would use different ways to get there.

Just because computer scientists bring out a new

toy does not mean that
engineers and scientists have to use it ASAP. There is a natural cycle of
adoption in which some of those concepts are gradually included if a set of
applications need it and others discarded.

The transformation of FORTRAN into Fortran is a very instructive story of
how this evolution has taken place. What I am trying to say is that just
because OOP (which is a part of the F2003 standard if you ask more
knowledgable people than me, around here) is available, does not mean you
should adopt it indiscriminately. For engineers and scientists, the need to
be clear, error free, and efficient outweighs the computer scientists' need
to be "smart" (from a data structures and OS perspective). Actually, doing
OOP can add overheads to your code (if the statement of the problem does
not need it) in many cases.

I did a minor in Computer Science in my undergrad, so I have some idea of
what I am trying to say here. Just to piss off my data structures
instructor, I actually did many assignments in FORTRAN (yes, the capital
case !) in addition to C++ :) Doing binary trees, etc. without recursion or
pointers was some fun.

> I'm not here to attack FORTRAN. I'm just trying to make a good
> business decision, because it will impact our industry for several
> decades at least. To me, it's a very simple equation: in computers,

You cannot realistically go for a business decision that will be sound for
"decades". What will you do if your code in future requires some features
(like vector operations, etc.) that Fortran provides natively ? Port it all
back to Fortran from whichever language you went to ?

From what I have seen, people in industry these days, write interfaces,
rarely much new code. So, better keep your code base in something that has
been tested and tried and add whatever interface the fickle customers are
demanding at the moment. For instance, OpenGL is one library - but it has
many interfaces (C, Fortran, Python, etc.).

The cost of developing a new interface is surely much less than porting and
reporting the entire code (even if done error free - in which there is no
substitute for the value of time over which testing has been done) to
latest the language of the day. An interface might be a 1000-4000 lines of
code, while your original code might be hundreds of thousands of lines of
code.

> technology is either growing, or it's DYING. Just because there are
> people running OS/2 doesn't mean it's not dying. So, the question to
> me is: are there more people programming in FORTRAN today than there
> were five years ago? And, will many engineering graduates in 2020 be
> proficient in FORTRAN?

To answer your question :

1. In absolute terms, yes there are probably more people programming in
Fortran (not FORTRAN) today than were 5 years ago.

2. In relative terms, probably not.

However, if we restrict ourselves to science and engineering fields (and
leave out those millions of new web developers, who are heavily into PHP,
DHTML, CSS, templates, etc.), the answer is not very clear either way.

And there is one scientific field in which, if I am not very mistaken,
almost the entire development is in C/C++/Java - genetics.

Dan Tex1

2004-05-12, 9:09 pm

From: Curious Curious@person.net

>My boss immediately attacked me, saying that FORTRAN is NOT a dying

Well. That depends on your definition of dying. :-)
Percentage-wise, Fortran appears to have a smaller market share than it used
to. However, it also appears that the total amount of Fortran usage has risen
considerably. This would tend to suggest that Fortran may still be growing,
though maybe not as fast as some other languages out there.

>Personally, I think my boss hasn't been on a college campus in decades,
>and has no idea of the extent to which FORTRAN has been on the decline.

Well, you may find that many college campus's and the "apparent" knowledge
that goes with them is not always as "up-to-date" and correct as we would like.
When it comes to computers, the "word" on what is in and what isn't is often
passed down from the Computer Science gurus. However, most of those guys
aren't immensely involved in the needs of engineers and scientists and others
doing intense numerical work. However, they often DO influence other peoples
thoughts on what languages are here to stay and which aren't. Keep in mind
also that most of these guys have never written a line of Fortran code in their
lives. Most have also never written even a "simple" finite element analysis
program ( though, my use of the word simple is probably inappropriate there ).

>The industry we work in is very specialized and there aren't a lot of
>young engineers in it, so we aren't exposed to the changes going on in
>the computer science field. And we don't write or update much code...
>MOST of the codes we use were written before I was born!!

The fact that you don't write or update that much code or too often is IMHO a
very large reason to go with a language which is as easy to learn and
comprehend as possible. Thus... one question to ask is "what language will a
future engineer pick up the easiest?"

>I'm not here to attack FORTRAN. I'm just trying to make a good
>business decision, because it will impact our industry for several
>decades at least. To me, it's a very simple equation: in computers,
>technology is either growing, or it's DYING. Just because there are
>people running OS/2 doesn't mean it's not dying. So, the question to
>me is: are there more people programming in FORTRAN today than there
>were five years ago? And, will many engineering graduates in 2020 be
>proficient in FORTRAN?

I don't think the answer to this last question is very helpful. IMHO, in
2020, most engineering students probably won't be proficient in ANY language.
I do know that today, the OVERWHELMING MAJORITY of engineering graduates are
not proficient in ANY language. You do get a lot of engineers who think they
are simply because they had an intro programming course in school. However, I
find that in reality, most of them are awful at programming. Only a very,
very, very small percentage of those graduating engineers will ever become
proficient at programming. Of course, that's not so hard to believe. If they
are going to write engineering programs, first and foremost, they have to
understand their engineering inside and out. If they don't... it won't matter
what language they use. Their finished product will be undependable.

IMHO, this is where Fortan comes in as a viable language. Relatively
speaking, I find it to be a very straight forward and easy to read and write
language. Thus, I have time to get my engineering right and then do the
programming to go with it. Other more difficult to understand languages would
force me to spend more time on the language and less on the engineering.
Couple the ease of Fortran with it's general speed of execution ( even when
programmed by a relative novice ), and I think you have a winning combination.

Real Life Example:
Where I work... a team of several engineers have just completed ( or nearly so
) a large code. It took them 6 years to write working full time. They are all
engineers and they chose C++, largely because they all seem to believe that
the future is there. It has a finite element analysis engine at it's core.
They didn't write that part. They got that from a college professor down the
road a ways. Well, I was recently beta testing their code. All I can say is
that their code has more bugs in it than my back yard does.

I've written similar code myself that does the same work as theirs. I wrote
mine all by myself and in my spare time at home ( not 8 hours a day as they
did ). All of my code was written sporadically over about a 3 year period. I
did this while still having a life with my wife and 2 very young, demanding
children. To date, many people have used my code. I'm the only one who has
ever found any bugs in it and those were incredibly minor and only showed up
when I really put some awful input-data into the program. They were also very
easy to find and fix.

What's more, my coworkers code runs at least 20 times slower than mine.
And... that's on small problems. The mulitplier goes up as the problem becomes
larger.

So... what is the relevance of this to your situation? If you are going to
have code that is going to be maintained and updated by future engineers, you
really ought to pick a language that is going to be as simple as possible to
read, by engineers who probably aren't ace programmers or even anything
remotely close. And, your future engineering graduates aren't likely to be any
better at programming than the engineers of today are. IMHO, fortran will
still be around in 20 years, at least as long as the "truly" technical people
who need it have a say in things ( that's certainly not a given ). Thus... I
agree with your boss that Fortran may indeed be a good choice for your company.

Dan :-)

James Giles

2004-05-12, 9:09 pm

Curious wrote:
> [...] Even if "wonder
> language" comes out next year and becomes the dominant language, today
> there are hordes of 20 year olds proficient in C,

Proficiency requires a long and relatively broad base
of experience. That's inconsistent both with youth and with
knowledge of only one language. Yes, a lot of 20-year-olds
*think* themselves proficient (I did). Most aren't.

> [...] so that forty years
> from now, odds are we could find quite a few engineers that could dust
> off the code and make use of it.

Then C is a particularly bad choice. It has the reputation
of a "write only language". People have trouble reading
their *own* code if it has been a year or so since they
looked at it last. It's often said that if you have to make
a large revision of a C code, you're probably better off
just rewriting it from scratch. That will take less time and
be less aggravating than trying to read and understand the
old code.

In addition, the very existence of large numbers of C-derived
languages will be detrimental to your choice. Your people
40 years from now will vaguely remember C itself, but will
probably really confuse it with the myriad of C-like languages
(that they used more recently) that had different semantics. The
result with be that they *think* they understand what the old
code does, but they won't.

--
J. Giles

Stewart C. Russell

2004-05-12, 9:09 pm

Madhusudan Singh wrote:
>
> And there is one scientific field in which, if I am not very mistaken,
> almost the entire development is in C/C++/Java - genetics.

Perl is very big with bioinformatics types. I think it's the
delightfully mutant syntax that attracts them.

Stewart

--
$,="\n";foreach(split('',"\3\3\3c>\0>c\177cc\0~c~``\0cc\177cc"))
& #123;$a++;$_=unpack('B8',$_);tr,01,\40#,
;$b[$a%6].=$_};print @b,"\n"

Stewart C. Russell

2004-05-12, 9:09 pm

beliavsky@aol.com wrote:
>
> A dying language would not be able to support as many compiler vendors
> as are listed at http://www.dmoz.org/Computers/Progr...tran/Compilers/

So many vendors, and all with remarkably high entry prices. I want to
develop cross-platform GUI scientific applications in Fortran. It looks
like I'll have to plunk down about US$1500 to get a compiler and
toolkit. Anyone wishing to build my code would need to spend a similar
amount. When reasonable development environments for C, Java and Perl
can be had for free, that's a big disincentive to take up Fortran.

And where's the community? c.l.f is okay as far as it goes, but it ain't
no Perl Monks <http://www.perlmonks.org/>

Stewart

Peter C. Chapin

2004-05-12, 9:09 pm

Curious <Curious@person.net> wrote in news:Xns94E35A4B0B061Default664@
199.45.49.11:

> It's true the computer industry is always changing, but the simplist
> indicator to me of a future language's supportability is how many young
> people are building their skills in that language.

I think most professional programmers know many programming languages and
can learn new languages relatively easily. Since developing skills in a
new programming language is usually not that big a deal, it probably
doesn't make sense to predict the future of a language based on how many
people are learning it in college. No matter what language people learn in
college, they will probably be using something different in 20 years.

By the way, be aware that there is a large difference between FORTRAN 77
and Fortran 90/95. FORTRAN 77 is indeed a fairly old language. But Fortran
90/95 is quite modern and supports constructs that are in keeping with
current ideas about how programming languages should be designed. I don't
know where you are coming from exactly, but I do think that many people
who talking about Fortran being a dying language are thinking of FORTRAN
77 (or maybe something even older).

Peter

Hendrik van Hees

2004-05-12, 9:09 pm

Stewart C. Russell wrote:

> So many vendors, and all with remarkably high entry prices. I want to
> develop cross-platform GUI scientific applications in Fortran. It
> looks like I'll have to plunk down about US$1500 to get a compiler and
> toolkit. Anyone wishing to build my code would need to spend a similar
> amount. When reasonable development environments for C, Java and Perl
> can be had for free, that's a big disincentive to take up Fortran.

A stupid question: What's wrong for you with the free gnu compilers? We
use them under Linux in theoretical physics. They are not bad for our
purposes (number crunching in many body quantum field theory, i.e.,
most of the time integrals with sharp structures in them). I must
admit, I have personally no commercial compilers I could compare with.

I know also a colleague who has also a commercial Fortran compiler (I
think it was an Intel compiler, although I'm not sure) to compare with,
and the GNU compiler gave the same or even better performance (he is
using it for molecular dynamics in nuclear physics, i.e., solving huge
systems of differential equations).

--
Hendrik van Hees Cyclotron Institute
Phone: +1 979/845-1411 Texas A&M University
Fax: +1 979/845-1899 Cyclotron Institute, MS-3366
http://theory.gsi.de/~vanhees/ College Station, TX 77843-3366

Gerry Thomas

2004-05-12, 9:09 pm

Tim Prince

2004-05-12, 9:09 pm

"Stewart C. Russell" <scruss@sympatico.ca> wrote in message
news:OBfnc.105854$ZJ5.2432029@news20.bellglobal.com...
> beliavsky@aol.com wrote:
http://www.dmoz.org/Computers/Progr...tran/Compilers/[color=darkred]
>
> So many vendors, and all with remarkably high entry prices. I want to
> develop cross-platform GUI scientific applications in Fortran. It looks
> like I'll have to plunk down about US$1500 to get a compiler and
> toolkit. Anyone wishing to build my code would need to spend a similar
> amount. When reasonable development environments for C, Java and Perl
> can be had for free, that's a big disincentive to take up Fortran.
If your cross-platform C/Java/Perl environment consists of cygwin and linux,
for example, I don't see how you could spend that much to add commercial
Fortran on both sides. I'm somewhat old fashioned; even when using Intel
Fortran with Microsoft SDK, I rarely use Visual Studio, and I would never
buy the full-priced version, unless I had a requirement for their variety of
C/C++.
I doubt you could find a "reasonable" free environment to cover all Intel
32- and 64- bit architectures for Windows C, while you get all of them in
Intel Fortran, and you have better performance than with free compilers.
I'm not trying to discourage anyone from developing a "64-bit" cygwin of
either variety; I'm all for it, but it won't happen by magic.

Gerry Thomas

2004-05-12, 9:09 pm

"Hendrik van Hees" <hees@comp.tamu.edu> wrote in message
news:2g5itkF4b0t2U1@uni-berlin.de...
> Stewart C. Russell wrote:
>
>
>
> A stupid question: What's wrong for you with the free gnu compilers? We
> use them under Linux in theoretical physics. They are not bad for our
> purposes (number crunching in many body quantum field theory, i.e.,
> most of the time integrals with sharp structures in them). I must
> admit, I have personally no commercial compilers I could compare with.
>
> I know also a colleague who has also a commercial Fortran compiler (I
> think it was an Intel compiler, although I'm not sure) to compare with,
> and the GNU compiler gave the same or even better performance (he is
> using it for molecular dynamics in nuclear physics, i.e., solving huge
> systems of differential equations).
>

There's no GNU F95 compiler, yet. Commercial Fortran compilers are F95+.
Isn't IFC free for pool hall physics?

--
E&OE

Ciao,
Gerry T.
______
"I believe that in all its branches, physics is still an experimental
science." -- Philip Anderson.

Madhusudan Singh

2004-05-12, 9:09 pm

On Saturday 08 May 2004 22:58, Gerry Thomas (gfthomas@sympatico.ca) held
forth in comp.lang.fortran
(<%8hnc.55852$3Q4.1478127@news20.bellglobal.com> ):

>
> "Hendrik van Hees" <hees@comp.tamu.edu> wrote in message
> news:2g5itkF4b0t2U1@uni-berlin.de...
>
> There's no GNU F95 compiler, yet. Commercial Fortran compilers are F95+.
> Isn't IFC free for pool hall physics?
>

Not only are you incredibly arrogant, but also quite ignorant (unless
something more nefarious is at work).

Take www.g95.org for instance. I have not tried it yet myself, but if you
read the comments posted there, it seems to be compiling some pretty
complex programs, including all but one routine from Numerical Recipes,
most, if not all of Netlib, and many other large codes. So, the statement
on the webpage ("pupal state") is a little misleading.

Unless you are natively stupid, I think you are a trolling employee of one
of these commercial vendors, or worse yet, of Microsoft. Such unreasoning
disdain for people who devote their time to bring proprietary-free software
to the public can arise only one of two things - a vested interest or
incredible brainlessness.

Take your pick.

While I will not call gnuplotfortran or fortranposix as being very large
pieces of code, many people have found them to be useful. I also do my
share by helping out with some questions that some people pose on c.l.f.
Yet you keep trying to insult me by calling me an "obdurate freeloader". Do
you even know some of the reasons why the Usenet was created ?

What is your ruddy problem ??

These are indeed uncharacteristically harsh words on my part and I apologize
to others on c.l.f who would rather not see these kinds of issues brought
up, but some people just force your hand.

I have now updated my kill file.

Gerry Thomas

2004-05-12, 9:09 pm

"Madhusudan Singh" <spammers-go-here@yahoo.com> wrote in message
news:2g5oo6F4qol2U1@uni-berlin.de...

[...]

> What is your ruddy problem ??

Lazy freeloaders and their ilk and, as in your case, the pretentious. If
possible, find someone to explain to you why GNU F77+ is not in the same
league as commercial F95+.

> I have now updated my kill file.

Testimony that you're a dolt to boot.

--
E&OE

Ciao,
Gerry T.
______
"God is not willing to do everything and thereby take away our free will
and that share of glory that rightfully belongs to us." -- Machiavelli.

Hrundi V. Bakshi

2004-05-12, 9:09 pm

"Madhusudan Singh" <spammers-go-here@yahoo.com> wrote in message
news:2g5oo6F4qol2U1@uni-berlin.de...

F95+.[color=darkred]
>
> Not only are you incredibly arrogant, but also quite ignorant (unless
> something more nefarious is at work).

It is my duty as wonderful friend of Sri Gerry T. to disclaim all his
rights to nefarious behavior. It is my thinking that you are paranoid a bit
maybe because he raised your BP to the sky, This is not good,

down,
take a walk, or as IBM likes to say, THINK.

>
> Take www.g95.org for instance. I have not tried it yet myself, but if you
> read the comments posted there, it seems to be compiling some pretty
> complex programs, including all but one routine from Numerical Recipes,
> most, if not all of Netlib, and many other large codes. So, the statement
> on the webpage ("pupal state") is a little misleading.

NR is a big joke, but you have not heard. Here is another joke: Is NR C++
C++? I know this will confuse you but that is the fun, duh! Netlib is 99%
FORTRAN, retrovariant Fortran, so no conclusion that in-progress g95 can
handle it is rational, but that seems to comes naturally to you.

>
> Unless you are natively stupid, I think you are a trolling employee of
one
> of these commercial vendors, or worse yet, of Microsoft. Such unreasoning
> disdain for people who devote their time to bring proprietary-free
software
> to the public can arise only one of two things - a vested interest or
> incredible brainlessness.
>
> Take your pick.

What is 'unreasoning distain'?
Believe me, Sri Gerry T. would not pick from such a constipated menu. You
are not too bright, are you? Sri Gerry T. is a cracker jack in these
matters.

>
> While I will not call gnuplotfortran or fortranposix as being very large
> pieces of code, many people have found them to be useful.

> I also do my
> share by helping out with some questions that some people pose on c.l.f.

Respectfully, there is no evidence of this, yet. Cultivate humility,
relinquish your propriety claim on stupidity, but best of all, THINK as Mr.
IBM would say.

> Yet you keep trying to insult me by calling me an "obdurate freeloader".

But it is true that you are an "obdurate freeloader" so grow up.

>Do you even know some of the reasons why the Usenet was created ?
>
> What is your ruddy problem ??
>
> These are indeed uncharacteristically harsh words on my part and I
apologize
> to others on c.l.f who would rather not see these kinds of issues brought
> up, but some people just force your hand.
>
> I have now updated my kill file.

I do not believe that you know how to this! Your loss.

Salaam and humbly,
Hrundi V. Bakshi, :-)

Danguard

2004-05-12, 9:09 pm

In article <2g5itkF4b0t2U1@uni-berlin.de>, hees@comp.tamu.edu says...

> A stupid question: What's wrong for you with the free gnu compilers? We
> use them under Linux in theoretical physics.

GNU free compilers = F77 and G95, right?

Dan

beliavsky@aol.com

2004-05-12, 9:09 pm

Hendrik van Hees <hees@comp.tamu.edu> wrote in message news:<2g5itkF4b0t2U1@uni-berlin.de>...

> A stupid question: What's wrong for you with the free gnu compilers? We
> use them under Linux in theoretical physics. They are not bad for our
> purposes (number crunching in many body quantum field theory, i.e.,
> most of the time integrals with sharp structures in them). I must
> admit, I have personally no commercial compilers I could compare with.
>
> I know also a colleague who has also a commercial Fortran compiler (I
> think it was an Intel compiler, although I'm not sure) to compare with,
> and the GNU compiler gave the same or even better performance (he is
> using it for molecular dynamics in nuclear physics, i.e., solving huge
> systems of differential equations).

The g77 compiler does not support Fortran 95, which has many useful
features. It also runs Fortran 77 codes more than 50% slower than
Intel Fortran on the benchmarks at
http://www.polyhedron.com/compare/l...77bench_p4.html .

Your colleague had a different experience. Maybe he could send his
code to the Intel Fortran team, so they can investigate.

Free Fortran 95 compilers are under development -- see
http://www.g95.org and
http://gcc.gnu.org/fortran/ . They are not yet replacements for
commercial Fortran 95 compilers.

Toon Moene

2004-05-12, 9:09 pm

Curious wrote:

> It's true the computer industry is always changing, but the simplist
> indicator to me of a future language's supportability is how many young
> people are building their skills in that language.

I entered University in 1975 as a first year physics student. First
thing we got to know in 2nd year was "programming". Of course, this
being the Vrije Universiteit, Amsterdan, the Netherlands, which happened
to get Andrew Tanenbaum as a tenured professor in something that didn't
have a name yet (Computer Science didn't exist in the mid 70's), we were
using an interpreted Pascal-like language on a Unix system.

Never mind that the "REAL WORK" for us physics students involved FORTRAN
(66). We weren't supposed to "learn" this language - you just took the
last years' students' code and modified it. In case of problems, there
was a thumbed three-ring manual available - and you could always ask the
proto-PhD's, who had hang out there for more years.

The idea that "learning Fortran" has anything to do with its popularity
is a completely foreign idea to me.

--
Toon Moene - mailto:toon@moene.indiv.nluug.nl - phoneto: +31 346 214290
Saturnushof 14, 3738 XG Maartensdijk, The Netherlands
Maintainer, GNU Fortran 77: http://gcc.gnu.org/onlinedocs/g77_news.html
GNU Fortran 95: http://gcc.gnu.org/fortran/ (under construction)

Rich Townsend

2004-05-12, 9:09 pm

Hrundi V. Bakshi wrote:
> "Madhusudan Singh" <spammers-go-here@yahoo.com> wrote in message
> news:2g5oo6F4qol2U1@uni-berlin.de...
>
>
>
> F95+.
>
>
>
> It is my duty as wonderful friend of Sri Gerry T. to disclaim all his
> rights to nefarious behavior. It is my thinking that you are paranoid a bit
> maybe because he raised your BP to the sky, This is not good,

down,
> take a walk, or as IBM likes to say, THINK.

Gerry, c.l.f is not the place for your (IMHO midly-racist) parody. Take
your meds or troll elsewhere; your continuing campaign of invective
against Madhusudan is making an absolute arse of you.

Rich

Jeff Ryman

2004-05-12, 9:09 pm

On Sun, 09 May 2004 14:32:08 +0200, Toon Moene
<toon@moene.indiv.nluug.nl> wrote:
>
>I entered University in 1975 as a first year physics student. First
>thing we got to know in 2nd year was "programming". Of course, this
>being the Vrije Universiteit, Amsterdan, the Netherlands, which happened
>to get Andrew Tanenbaum as a tenured professor in something that didn't
>have a name yet (Computer Science didn't exist in the mid 70's), we were
>using an interpreted Pascal-like language on a Unix system.
>
>Never mind that the "REAL WORK" for us physics students involved FORTRAN
>(66). We weren't supposed to "learn" this language - you just took the
>last years' students' code and modified it. In case of problems, there
>was a thumbed three-ring manual available - and you could always ask the
>proto-PhD's, who had hang out there for more years.
>
>The idea that "learning Fortran" has anything to do with its popularity
>is a completely foreign idea to me.
You experience is not uncommon. In my 2nd year of college (1966), I
took a 2-credit hour programming class using an IBM 1620 that covered
machine language, then assembler, then FORTRAN II. However, the 2
credit hours did not count towards my B.S. because programming was
something any competent engineer was supposed to pick up on his own.
Our Nuclear Engineering Department covered FORTRAN in about a 4-w

(12 lecture) period during an in-department math class for NEs, and
this was considered more than sufficient.
Jeff Ryman
email: rymanjc_at_
excite_dot_com

Stewart C. Russell

2004-05-12, 9:09 pm

Hendrik van Hees wrote:
>
> A stupid question: What's wrong for you with the free gnu compilers?

No GUI toolkit, no IDE, patchy F90/95 coverage. All of these are
show-stoppers for me.

Stewart

--
all the above should be prefaced with "that I know of" ...

Madhusudan Singh

2004-05-12, 9:09 pm

On Sunday 09 May 2004 23:16, Stewart C. Russell (scruss@sympatico.ca) held
forth in comp.lang.fortran (<StCnc.3471$dr1.135826@news20.bellglobal.com> ):

> Hendrik van Hees wrote:
>
> No GUI toolkit, no IDE, patchy F90/95 coverage. All of these are
> show-stoppers for me.
>
> Stewart
>

When you have emacs, you do not need any IDE !

As to f90/95 coverage, if you look at www.g95.org, it seems that it does
compile a large number of f90 codes (just read the feedback). Yes, it is
not complete yet, but I have been monitoring its progress for the past 1
year or so. The amount of work done so far is amazing. I won't be surprised
if they released a beta version sometime soon.

bendel boy

2004-05-12, 9:09 pm

In the 1980s the universities were teaching Pascal as the new wonder
language that would 'replace' Pascal. Had you had this problem 10-20
years ago you would be considering dropping Fortran for Pascal - and
now, 10-20 years on, would be wondering why Pascal appears to have
even less support than Fortran. Making a decision based on what is
being used as a teaching language is difficult - in my old university
department they have dropped Fortran, replacing it with Excel and
Excel macros. But I wouldn't treat that as a sign of the 'engineering
computing environment' for the future.

What languages are the people who will do your coding proficient in?
You are likley to do your own additions using that language. I assume
that you have the souce code avaliable for both the Fortan and C
packages - otherwise why should it matter? So look at your own
resouces to help you decide.

Now, you talk of your work being needed decades hence. Lets assume 50
years. That far ahead I would suggest that of greater value to you
would be setting coding standards now - no vendor extentsions (so
whether Microsoft or Sun provide your compiler becomes irelevant),
write your code as explicitly as possible - cuties such as a[i] =
b[i++] will haunt you. Work on the asumption that both Fortran and C
will have been replaced by a language where the constructs of
Fortran/C do not have a simple translation into the new language.

Curious <Curious@person.net> wrote in message news:<Xns94E35A4B0B061Default664@199.45.49.11>...
> helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to
> reply) wrote in news:c7i67g$2gp$3@online.de:
>
>
> It's true the computer industry is always changing, but the simplist
> indicator to me of a future language's supportability is how many young
> people are building their skills in that language. Even if "wonder
> language" comes out next year and becomes the dominant language, today
> there are hordes of 20 year olds proficient in C, so that forty years from
> now, odds are we could find quite a few engineers that could dust off the
> code and make use of it.
>
>
> Not in this case. We're engineers (government, actually), not
> programmers. We're going to adopt a particular software product (along
> with the contractors we work with), and then write additional code in that
> language that models the behavior of hardware that could need to be
> supported FIFTY years from now. So, it's key for us to have engineers
> that understand both the computer language AND the hardware the code was
> used to model. We can't just grab programmers off the street and say
> "port this".
>
> At a company I used to work at in the same industry, we had ONE 65 year old
> engineer that knew both the (obsolete) modeling software and understood the
> hardware that he modeled using the software (something of an art). When
> he retired, all knowledge of modeling that hardware was lost.
>
> The scenario I see coming is some time in the future, we hire a young
> engineer out of college and ask him to update a model -- I think it's
> probable that he'll not know FORTRAN.
>
>
> Out of curiosity, what compilers are they using?
>
> See, in our case, we're engineers who are highly specialized in the
> technology we're developing, and programming skills are secondary.
>
> So, this is what I think my boss is missing... FORTRAN may be alive and
> well TODAY, but if it becomes the COBOL of tomorrow, that's a lethal
> combination for our industry.
>
>
> Maybe I'm thinking too much in terms of hardware, or mainstream software,
> where compatibility issues make it impossible to continue using out of
> favor technology. I was kind of spooked that Microsoft dropped their
> FORTRAN compiler. But I guess this isn't the same as us deciding to store
> our data on 5-1/2" disks.

Jan Vorbrüggen

2004-05-12, 9:09 pm

> It's true the computer industry is always changing, but the simplist
> indicator to me of a future language's supportability is how many young
> people are building their skills in that language.

It is a peculiarity of computer "science" that there is only a loose -
nay, naybe even a negative?! - correlation between supportability and
popularity.

> Even if "wonder language" comes out next year and becomes the dominant
> language, today there are hordes of 20 year olds proficient in C, so
> that forty years from now, odds are we could find quite a few engineers
> that could dust off the code and make use of it.

As noted elsewhere, there are no 20 year old proficient programmers, and
particularly not in C and its derivates. You stand a good chance of not
finding _anybody_ "proficient" in C - have a read over at comp.lang.c and
see for yourself. And dusting off old code and making - sensible - use of
it is difficult in many languages (Fortran not excluded), but almost
impossible in C.

The problem here is that the languages semantics are very convoluted, on
many important issues the language standard punts and say "undefined" or
"implementation-defined" - both of which mean "all bets are off". And while
you'd think things are working more or less well and consistently today,
these cracks in the armor _will_ catch up with you over decades.

> Not in this case. We're engineers (government, actually), not
> programmers. We're going to adopt a particular software product (along
> with the contractors we work with), and then write additional code in that
> language that models the behavior of hardware that could need to be
> supported FIFTY years from now. So, it's key for us to have engineers
> that understand both the computer language AND the hardware the code was
> used to model. We can't just grab programmers off the street and say
> "port this".

See above - one corollary is that understanding what a program really means
is much easier in Fortran than in C, _and_ you have a higher likelihood that
the compiler's understanding is similar.

> The scenario I see coming is some time in the future, we hire a young
> engineer out of college and ask him to update a model -- I think it's
> probable that he'll not know FORTRAN.

But he should be able to learn it quickly - and if he can't do that, he's
not worth his salt anyway.

> See, in our case, we're engineers who are highly specialized in the
> technology we're developing, and programming skills are secondary.

The more important it is to choose a "simple" language - see above.

Jan

Catherine Rees Lay

2004-05-12, 9:09 pm

In article <2g5itkF4b0t2U1@uni-berlin.de>, Hendrik van Hees
<hees@comp.tamu.edu> writes
>Stewart C. Russell wrote:
>
>
>
>A stupid question: What's wrong for you with the free gnu compilers? We
>use them under Linux in theoretical physics. They are not bad for our
>purposes (number crunching in many body quantum field theory, i.e.,
>most of the time integrals with sharp structures in them). I must
>admit, I have personally no commercial compilers I could compare with.
>
>I know also a colleague who has also a commercial Fortran compiler (I
>think it was an Intel compiler, although I'm not sure) to compare with,
>and the GNU compiler gave the same or even better performance (he is
>using it for molecular dynamics in nuclear physics, i.e., solving huge
>systems of differential equations).
>
I think the critical word there was "GUI". Much as I respect all the
work that's gone into the free Fortran compilers, their built in GUI
facilities aren't up to what's available either as part of the
commercial ones or with 3rd party libraries. For some this is
irrelevant, for others it's a showstopper. You should also consider that
there's not (yet) a gnu F90 compiler, you are restricted to F77 with
extensions.

But if this is OK for you, you can always go the mixed language route,
use a free Fortran compiler for the computational stuff and a free
development environment based on another language for the GUI.

There's a table of compiler benchmark comparisons at www.polyhedron.com
which you might find interesting - not least because it shows just how
strongly "fastest" depends on the precise problem! (I work for
Polyhedron as a programmer).

Catherine.
--
Catherine Rees Lay
To email me, use my first name in front of the "at".

Catherine Rees Lay

2004-05-12, 9:09 pm

In article <2g8ebaF5fu6fU1@uni-berlin.de>, Madhusudan Singh
<spammers-go-here@yahoo.com> writes
>On Sunday 09 May 2004 23:16, Stewart C. Russell (scruss@sympatico.ca) held
>forth in comp.lang.fortran (<StCnc.3471$dr1.135826@news20.bellglobal.com> ):
>
>
>When you have emacs, you do not need any IDE !
>
Hey, there's this machine code stuff! Why do you need a language at all?

Not a swipe at emacs per se, but I've yet to see the emacs
implementation which allows me to visually design dialogs and menus. I
believe in using the right tool for the job, and in many cases an IDE
provides the right tool.

>As to f90/95 coverage, if you look at www.g95.org, it seems that it does
>compile a large number of f90 codes (just read the feedback). Yes, it is
>not complete yet, but I have been monitoring its progress for the past 1
>year or so. The amount of work done so far is amazing. I won't be surprised
>if they released a beta version sometime soon.

If an incomplete compiler which can cope with "a large number" of codes
is suitable for you, then great. But it's not finished yet, and waiting
for it to be finished is not an option for many people who are (quite
understandably) worried about investing a lot of time in it only to
discover that something they need isn't supported yet. Even 99%
completeness isn't much good if you need something from the other 1%.
And to be honest my customers would think I was joking if I said
"there's this new compiler I recommend we use, it's not complete yet but
they'll be releasing a beta version sometime soon".

Conversely if money was a big issue and I wanted a compiler with F95
features, I would certainly go to g95 first to see if it was complete
enough for me. I guess you are in this category, but I'm not, and
neither from the sounds of it is Stewart. It doesn't make any of us
wrong. These days there's a sufficiently wide variety of application
types written using Fortran that "the right tool" no longer exists.

Catherine (I work for Polyhedron as a programmer)
--
Catherine Rees Lay
To email me, use my first name in front of the "at".

Hendrik van Hees

2004-05-12, 9:09 pm

Madhusudan Singh wrote:

> When you have emacs, you do not need any IDE !

Right. Emacs is the best tool for me. I'm writing all my Fortran code
and all texts (LaTeX) with it. I do not need GUIs. I use Fortran only
as a tool to do some "number crunching", writing the output to ASCII
files which I can feed to other programs like gnuplot or xmgrace to get
my plots out. For this tasks, g77 is fine for me. When there is the
Fortran 90/95 compiler available, I'll have a look at it.

Another stupid question: What's the main reason to switch from Fortran
77 with extensions (do ... end do instead of the old-fashioned
construction etc.)?
>
> As to f90/95 coverage, if you look at www.g95.org, it seems that it
> does compile a large number of f90 codes (just read the feedback).
> Yes, it is not complete yet, but I have been monitoring its progress
> for the past 1 year or so. The amount of work done so far is amazing.
> I won't be surprised if they released a beta version sometime soon.

--
Hendrik van Hees Cyclotron Institute
Phone: +1 979/845-1411 Texas A&M University
Fax: +1 979/845-1899 Cyclotron Institute, MS-3366
http://theory.gsi.de/~vanhees/ College Station, TX 77843-3366

Jan Vorbrüggen

2004-05-12, 9:09 pm

> Another stupid question: What's the main reason to switch from Fortran
> 77 with extensions (do ... end do instead of the old-fashioned
> construction etc.)?

In rough order of priority:

- MODULEs
- array language
- KINDs
- free-form source, long names et al.
- INCLUDEs
- lotsa more interesting intrinsics, incl. INQUIRE

I probably forgot one or the other important point. No matter: I wouldn't
ever restrict myself to F77 or even to VAX/VMS Fortran again.

Jan

Richard Maine

2004-05-12, 9:09 pm

Jan Vorbrüggen <jvorbrueggen-not@mediasec.de> writes:

>
> In rough order of priority:
>
> - MODULEs
> - array language
> - KINDs
> - free-form source, long names et al.
> - INCLUDEs
> - lotsa more interesting intrinsics, incl. INQUIRE
>
> I probably forgot one or the other important point. No matter: I wouldn't
> ever restrict myself to F77 or even to VAX/VMS Fortran again.

I'd say that the most important two you forgot are structures (derived
types) and dynamic allocation. The lack of those two things in f77 was
what drove me to go looking for alternatives in the late 80's. I had
already been a Fortran programer for about 2 decades then, but I just
couldn't see doing a new project that I was starting on then without
those two features. (And the various nonportable and vendor-dependent
hacks for them in some vendor's f77s were not acceptable).

Once I discovered f90 (which didn't have any compilers yet), I found
a lot of other things to like about it (and a few warts, as with
anything), but it was structures and dynamic allocation that were
going to drive me out of f77.

--
Richard Maine | Good judgment comes from experience;
email: my first.last at org.domain | experience comes from bad judgment.
org: nasa, domain: gov | -- Mark Twain

Madhusudan Singh

2004-05-12, 9:09 pm

On Monday 10 May 2004 10:33, Hendrik van Hees (hees@comp.tamu.edu) held
forth in comp.lang.fortran (<2g9i4dF71h6U1@uni-berlin.de> ):

> Madhusudan Singh wrote:
>
>
> Right. Emacs is the best tool for me. I'm writing all my Fortran code
> and all texts (LaTeX) with it. I do not need GUIs. I use Fortran only
> as a tool to do some "number crunching", writing the output to ASCII
> files which I can feed to other programs like gnuplot or xmgrace to get
> my plots out. For this tasks, g77 is fine for me. When there is the
> Fortran 90/95 compiler available, I'll have a look at it.
>

Same here. I am waiting for them to release their first complete version
(which might be pretty close, considering the rate at which submitted bugs
seem to be fixed).

OTOH, I sometimes think that maybe I should give it a spin on my Monte Carlo
code. At worst, it could help sort out some more kinks in the final
version.

> Another stupid question: What's the main reason to switch from Fortran
> 77 with extensions (do ... end do instead of the old-fashioned
> construction etc.)?

f95 provides a more intuitive way of programming than FORTRAN 77 does (this
is not a knock on the latter, I used it for quite a few years). Modules,
pointers, recursion (some problems are inherently recursive), subscripted
array addressing (MATLAB style), machine portability of code (KIND),
superior file I/O methods, operating overloading, free form source (no
small matter there), etc. Now whenever I look at my old F77 code, I wonder
how I put up with all that.

Jan Vorbrüggen

2004-05-12, 9:09 pm

>>In rough order of priority:
>
> I'd say that the most important two you forgot are structures (derived
> types) and dynamic allocation.

Ugh - yes, thanks for the addition. My only excuse can be that you just
had your first coffee for the day, while I've just had my last 8-)...

In fact, VMS Fortran had structures, and also dynamic allocation but not
in a well-integrated way. And, of course, we had ZEBRA et al. for these
and similar things...nah, no need to eulogize the old days.

Jan

Dr Chaos

2004-05-12, 9:09 pm

On Sat, 08 May 2004 05:12:54 GMT, Curious <Curious@person.net> wrote:
> This is a serious question. Is FORTRAN a dying language?
>
> I ask, because today at work (I'm an engineer) we were briefly debating
> the merits of two software packages for systems engineering, in
> preparation for adopting one for our work. The older package was
> written in FORTRAN, while the newer package was written in C. They are
> both equivalent in features -- in fact, the newer, C-based code was
> pretty much a direct copy of the elder FORTRAN code, and had some of the
> original FORTRAN developers behind it.
>
> My boss (who is an engineer in his 60's) was in favor of the older
> FORTRAN based program, because it's the incumbent, basically. I
> favored the newer code, arguing that since "all else is equal, why
> should we pick a code written in a dying language? We're going to be
> writing our own code to work with it, that will need to be used for
> DECADES."
>
> My boss immediately attacked me, saying that FORTRAN is NOT a dying
> language, that is alive and well, and that it will be viable in 2030,
> like it was in 1970. "You ever hear of COBAL? It's the worst
> language ever invented, and your banks STILL run software written in it
> -- COBAL will never die."
>
> Personally, I think my boss hasn't been on a college campus in decades,
> and has no idea of the extent to which FORTRAN has been on the decline.
> The industry we work in is very specialized and there aren't a lot of
> young engineers in it, so we aren't exposed to the changes going on in
> the computer science field. And we don't write or update much code...
> MOST of the codes we use were written before I was born!!
>
> I'm not here to attack FORTRAN. I'm just trying to make a good
> business decision, because it will impact our industry for several
> decades at least. To me, it's a very simple equation: in computers,
> technology is either growing, or it's DYING. Just because there are
> people running OS/2 doesn't mean it's not dying. So, the question to
> me is: are there more people programming in FORTRAN today than there
> were five years ago? And, will many engineering graduates in 2020 be
> proficient in FORTRAN?

C will be dying as a good engineering-oriented language before
Fortran 2003.

There is a better upgrade path from old fortran into a safer
and good language than from C.

The best thing to do is to adopt the Fortran 77 (presumably) package
and slowly update it to use the features and safety of modern Fortran.

Dr Chaos

2004-05-12, 9:09 pm

On Sat, 08 May 2004 15:52:31 GMT, Curious <Curious@person.net> wrote:
> helbig@astro.multiCLOTHESvax.de (Phillip Helbig---remove CLOTHES to
> reply) wrote in news:c7i67g$2gp$3@online.de:
>
>
> It's true the computer industry is always changing, but the simplist
> indicator to me of a future language's supportability is how many young
> people are building their skills in that language. Even if "wonder
> language" comes out next year and becomes the dominant language, today
> there are hordes of 20 year olds proficient in C, so that forty years from
> now, odds are we could find quite a few engineers that could dust off the
> code and make use of it.

The real question is whether when people modify the code in 20 years,
unexpected and difficult bugs are likely to arise.

This is more likely to happen with C-based codes than with Fortran
based codes, simply because Fortran the language and in common
implementation has provisions to allow good bounds checking and other
checks. There are hacks to do so for C, but they aren't certain.

> The scenario I see coming is some time in the future, we hire a young
> engineer out of college and ask him to update a model -- I think it's
> probable that he'll not know FORTRAN.

But the engineer will probably know MATLAB, which can go to
Fortran 95 reasonably easily, except for pointers.

The issue in future hires will be little about the specific
programming language, as opposed to good physical reasoning, curiosity
and fundamental mathematical principles.

> See, in our case, we're engineers who are highly specialized in the
> technology we're developing, and programming skills are secondary.
>
> So, this is what I think my boss is missing... FORTRAN may be alive and
> well TODAY, but if it becomes the COBOL of tomorrow, that's a lethal
> combination for our industry.

Why?

What's the big problem with COBOL? It is completely inappropriate for
scientific computation of course, but I haven't heard of big disasters
from companies who wrote COBOL applications and still rely on them.

The fact that they are still there and being used seems to indicate
that the choice wasn't so bad after all.

If anything, the companies are stuck with data bases and data base
models which are obsolete. The manipulation langauge is probably
secondary or tertiary to that issue.

Note, you can pick up software from www.netlib.org which is pretty
old, and works perfectly.

Fortran is *reliable*.

> Maybe I'm thinking too much in terms of hardware, or mainstream software,
> where compatibility issues make it impossible to continue using out of
> favor technology. I was kind of spooked that Microsoft dropped their
> FORTRAN compiler.

Microsoft goes through development software like fashion. It's to
their financial advantage to make the even recently born stuff "old"
and no longer in fashion to make you get their new stuff. Look, even
now their dot-com-era J++ compilers and entire swaths of class
libraries have been declared obsolete by Redmond.

You needn't do so.

One more fact: pretty soon the GNU compiler collection
(GCC) will be adding Fortran 95 as part of the standard
core, and the F77 will be obsoleted.

More people will be using F95.

> But I guess this isn't the same as us deciding to store
> our data on 5-1/2" disks.

No.

Consider also the future of computer hardware. You are more
likely to get more parallelism, already multi-core CPUs will
be mainstream from Intel in a couple of years. Now consider
15 to 20.

Straight C-based languages which assume only a single-threaded
executable with flat 32-bit pointers, and pointers used everywhere,
are less future-proof than Fortran.

Fortran, and certainly Fortran 95 and up is better attuned and
more semantically adaptable to parallel hardware.

So I see it as

a) Fortran codes are more likely to remain reliable
b) potentially more parallel-friendly

because of specific language design of Fortran vs C.

Look, I'm not some old fogie. I learned Fortran 77
and C at the same time and used C for quite a while
because of needing dynamic memory allocation.

I now intentionally prefer Fortran 95 to C and C++ for most tasks
because of true technical advantage.

Dr Chaos

2004-05-12, 9:09 pm

On Sat, 08 May 2004 21:21:53 -0500, Hendrik van Hees <hees@comp.tamu.edu> wrote:
> Stewart C. Russell wrote:
>
>
>
> A stupid question: What's wrong for you with the free gnu compilers? We
> use them under Linux in theoretical physics. They are not bad for our
> purposes (number crunching in many body quantum field theory, i.e.,
> most of the time integrals with sharp structures in them). I must
> admit, I have personally no commercial compilers I could compare with.
>
> I know also a colleague who has also a commercial Fortran compiler (I
> think it was an Intel compiler, although I'm not sure) to compare with,
> and the GNU compiler gave the same or even better performance (he is
> using it for molecular dynamics in nuclear physics, i.e., solving huge
> systems of differential equations).

That's unusual.

We've found even the NAG compiler to perform better than G77, and
Intel Fortran usually dusts them both.

Dr Chaos

2004-05-12, 9:09 pm

oMadhusudan Singh <spammers-go-here@yahoo.com> wrote:
> On Saturday 08 May 2004 22:58, Gerry Thomas (gfthomas@sympatico.ca) held
> forth in comp.lang.fortran
> (<%8hnc.55852$3Q4.1478127@news20.bellglobal.com> ):
>
> Not only are you incredibly arrogant, but also quite ignorant (unless
> something more nefarious is at work).
>
> Take www.g95.org for instance. I have not tried it yet myself, but if you
> read the comments posted there, it seems to be compiling some pretty
> complex programs, including all but one routine from Numerical Recipes,
> most, if not all of Netlib, and many other large codes. So, the statement
> on the webpage ("pupal state") is a little misleading.

No optimization is on, and it won't be even started until the
GCC folks mainline the new internal representation.

Hence it is a factor of 3 or 4 (at a minimum) slower than optimized
Fortran executables using other compilers.

And yes, it's buggier than commercial compilers which have been out
for years and have years of actual people's bug fixes in them.

> Unless you are natively stupid, I think you are a trolling employee of one
> of these commercial vendors, or worse yet, of Microsoft. Such unreasoning
> disdain for people who devote their time to bring proprietary-free software
> to the public can arise only one of two things - a vested interest or
> incredible brainlessness.
>
> Take your pick.

Oh come on; stop with the free software Talibanism.

GNU fortran 95 at some point will be pretty nice and significant competition
for commercial compilers. That time is not now.

Dr Chaos

2004-05-12, 9:09 pm

>
> In rough order of priority:

And what about

- ALLOCATE()

??

Seems enormously important to me.

Kevin G. Rhoads

2004-05-12, 9:09 pm

Fortran was designed for numeric programming.

C began life as a (semi-portable PDP-11 assember minded) system programming language.

People have tried to design do-all languages (PL/I, Ada), which have had many interesting
and nice features -- where are they today?

If the thing you want to do is mostly numerics, Fortran is "better" than C.
If the thing you want to do is mostly system programming, C is "better" than Fortran (on most hardware).

You wouldn't use a nitro-burning "funny" car to go shopping for groceries, would you?
Or a dump truck for drag racing? Or a station wagon or minivan to haul 9 yards of loam?

Stop perseverating on the language and look at the problem requirements, THEN choose a
language that was designed for that kind of problem.

HTH
Kevin

Paul Van Delst

2004-05-12, 9:09 pm

Dr Chaos wrote:
>
> But the engineer will probably know MATLAB, which can go to
> Fortran 95 reasonably easily, except for pointers.

You know, I've seen this assertion made before. I reckon matlab code looks like C! I use
IDL a lot (sorta like matlab) and that's more Fortran-like (used to be written in Fortran
even!)

cheers,

paulv

Paul Van Delst

2004-05-12, 9:09 pm

Kevin G. Rhoads wrote:
>
> Stop perseverating on the language and look at the problem requirements, THEN choose a
> language that was designed for that kind of problem.

Hello,

I was just going to post something to that effect, but figured I didn't know enough of
what I was talking about to really do so. Your comment above was the first thing that
occurred to me when I first started reading this thread. People want to pick the language
and *then* define the requirements rather than the other way 'round. Maybe that sounds
like a put down to the OP - which is not how it's meant since the OP didn't reveal too
much about their software management process .... which is also good. :o)

cheers,

paulv

Surendar Jeyadev

2004-05-12, 9:09 pm

In article <Xns94E35A4B0B061Default664@199.45.49.11>,
Curious <Curious@person.net> wrote:
>
>The scenario I see coming is some time in the future, we hire a young
>engineer out of college and ask him to update a model -- I think it's
>probable that he'll not know FORTRAN.

It seems that what you are really afraid of is that "in the future ....
a young engineer out of college" will be incapable of teaching him/herself
a reasonably simple programming language. (Given the declining standards of
education, I do not blithely discount this possibility.) But, should you
even think of hiring such a person?

Many of us learnt to programme in various languages by ourselves! Just
like we do not go back to college everytime the operating system changes :-)

--

Surendar Jeyadev jeyadev@wrc.xerox.bounceback.com

Remove 'bounceback' for email address

Helge Avlesen

2004-05-12, 9:09 pm

Dr Chaos <mbkennelSPAMBEGONE@NOSPAMyahoo.com> writes:

| We've found even the NAG compiler to perform better than G77, and

that is weird, considering NAG translates fortran to pure&ugly C, and
then use gcc to make the binary...

--
Helge

Steven G. Kargl

2004-05-12, 9:09 pm

In article <slrnc9vjp7.14t.mbkennelSPAMBEGONE@lyapunov.ucsd.edu>,
Dr Chaos <mbkennelSPAMBEGONE@NOSPAMyahoo.com> writes:
>
> No optimization is on, and it won't be even started until the
> GCC folks mainline the new internal representation.
>

This isn't true for gfortran, which is part of the tree-ssa branch
of GCC. While additional optimizations could be applied, any
optimizations available to gcc are already available to gfortran.

>
> Hence it is a factor of 3 or 4 (at a minimum) slower than optimized
> Fortran executables using other compilers.
>

This isn't true either. Here are the average executions times
for 5 runs of an acoustic scattering code I wrote. The first
column is in seconds and smaller is obviously better.

7.216 gfortran -x f95 -o zz -march=athlon -O0 -static shell.f
3.278 gfortran -x f95 -o zz -march=athlon -O1 -static shell.f
2.978 gfortran -x f95 -o zz -march=athlon -O2 -static shell.f
3.188 f95 -Wc,-march=athlon -o zz -O2 -dusty -Bstatic shell.f

f95 is a commercially available compiler.

PS: the results of gfortran and f95 agree. :-)

>
> GNU fortran 95 at some point will be pretty nice and significant competition
> for commercial compilers. That time is not now.
>

I definitely agree with your assertation, here. Both g95 and gfortran
have many bugs and some missing features. Fortunately, progress has
been fairly rapid on both projects.

--
Steve
http://troutmask.apl.washington.edu/~kargl/

Dr Chaos

2004-05-12, 9:09 pm

Paul Van Delst <paul.vandelst@noaa.gov> wrote:
> Dr Chaos wrote:
>
> You know, I've seen this assertion made before. I reckon matlab code looks like C!

Other than using () for array access like Fortran and unlike C, other
than having block structured control structures with "end" like
Fortran and unlike C, other than having array slice notation and
concepts like Fortran, and unlike C, unlike distinguishing pointers
from arrays, like Fortran and unlike C, and having implicit
declarations of variables like Fortran unlike C, and having array
intrinsics, like Fortran and unlike C, having no 'address of'
operator, like Fortran and unlike C....

I guess maybe.

whoops, changed my mind. :)

Richard Maine

2004-05-12, 9:09 pm

Helge Avlesen <avle@ii.uib.no> writes:

> Dr Chaos <mbkennelSPAMBEGONE@NOSPAMyahoo.com> writes:
>
> | We've found even the NAG compiler to perform better than G77, and
>
> that is weird, considering NAG translates fortran to pure&ugly C, and
> then use gcc to make the binary...

which just illustrates why it is better to actually test performance
instead of relying on broad generalizations like "translating into
C will hurt your performance." As is well known, all generalizations
are false.

Yes, translating into C *CAN* hurt your performance, but life is
seldom quite that simple. It won't hurt performance in all cases,
and there are plenty of other things that can hurt performance worse
in some cases. If it surprises you that NAG can beat g77 in some cases,
then I suggest you are making overly simplistic generalizations.

For just one trivial example - for quite a long time, NAG was the
only compiler that did run-time contiguity testing to avoid
unnecessary copying of array arguments. This can be a *HUGE*
performance issue. I've personally seen it make differences of
two to three orders of magnitude in calls to individual
procedures. Yes, I said orders of magnitude. Admitedly, by
the time this was diluted in the complete application, the effect
was down to "only" a factor of..a few (I forget exactly).
I think the other f90 compilers have mostly caught on to this
by now, but it took some of them a *LONG* time.

Oh, and on technical details, the NAG C isn't what I'd call
"pure" as it is heavily laced with calls to the support
library. And depending on the platform, it uses any of several
different C compilers; it is not specific to gcc for the
C part.

--
Richard Maine | Good judgment comes from experience;
email: my first.last at org.domain | experience comes from bad judgment.
org: nasa, domain: gov | -- Mark Twain

Dr Chaos

2004-05-12, 9:09 pm

On 10 May 2004 21:50:23 +0200, Helge Avlesen <avle@ii.uib.no> wrote:
> Dr Chaos <mbkennelSPAMBEGONE@NOSPAMyahoo.com> writes:
>
>| We've found even the NAG compiler to perform better than G77, and
>
> that is weird, considering NAG translates fortran to pure&ugly C, and
> then use gcc to make the binary...

I know, but it shows that NAG's intermediate representation and transformation
smarts isn't so bad.

beliavsky@aol.com

2004-05-12, 9:09 pm

Dr Chaos <mbkennelSPAMBEGONE@NOSPAMyahoo.com> wrote:

>Oh come on; stop with the free software Talibanism.

Nice phrase. Some open source advocates
are too critical of people who do not share their philosophy.

>
>GNU fortran 95 at some point will be pretty nice and significant competition
>for commercial compilers. That time is not now.
>

I agree that G95 is not yet a replacement for commercial compilers. But for
me it has already reached the
point where it is a useful supplement.
I have compiled hundreds of sources
with G95 and have not yet found a case where it does not compile legal code
(not to say that those cases don't exist -- just not in my code so far).
It has rejected code that I had mistakenly thought was legal -- for example

print "(i)",1

The "(i)" format is not legal, but I think "(i0)" or (for example) "(i4)"

is. LF95 does warn against "(i)" with
the -f95 (strict F95) option, but G95 does not create an executable, which
really gets my attention :).

G95, correctly, does not allow pure procedures to call the RANDOM_NUMBER
subroutine. Until recently, some commercial compilers got this wrong.

Gerry Thomas

2004-05-12, 9:09 pm

"Dr Chaos" <mbkennelSPAMBEGONE@NOSPAMyahoo.com> wrote in message
news:slrnc9vpfn.1hp.mbkennelSPAMBEGONE@lyapunov.ucsd.edu...
> Paul Van Delst <paul.vandelst@noaa.gov> wrote:
looks like C![color=darkred]
>
> Other than using () for array access like Fortran and unlike C, other
> than having block structured control structures with "end" like
> Fortran and unlike C, other than having array slice notation and
> concepts like Fortran, and unlike C, unlike distinguishing pointers
> from arrays, like Fortran and unlike C, and having implicit
> declarations of variables like Fortran unlike C, and having array
> intrinsics, like Fortran and unlike C, having no 'address of'
> operator, like Fortran and unlike C....
>
> I guess maybe.
>
> whoops, changed my mind. :)

Additionally, the MATLAB C Math Library stores its arrays in column-major
order, unlike C, which stores arrays in row-major order. Further, the
MATLAB convention for array indices is: indices begin at one rather than
zero. MATLAB traces its lineage to FORTRAN.

--
Ciao,
Gerry T.
______
"Nobody can get the truth out of me because even I don't know what it is. I
keep myself in a constant state of utter confusion." -- Col Sam Flagg,
ICORPS dropin to the 4077th M*A*S*H

Toon Moene

2004-05-12, 9:09 pm

Madhusudan Singh wrote:

> On Monday 10 May 2004 10:33, Hendrik van Hees (hees@comp.tamu.edu) held

[color=darkred]
> Same here. I am waiting for them to release their first complete version
> (which might be pretty close, considering the rate at which submitted bugs
> seem to be fixed).

Yeah, keep trying the compiler and send in those bug reports - I really,
really regret having no time to fix bugs (until after the GCC summit,
http://www.gccsummit.org) ...

--
Toon Moene - mailto:toon@moene.indiv.nluug.nl - phoneto: +31 346 214290
Saturnushof 14, 3738 XG Maartensdijk, The Netherlands
Maintainer, GNU Fortran 77: http://gcc.gnu.org/onlinedocs/g77_news.html
GNU Fortran 95: http://gcc.gnu.org/fortran/ (under construction)

Paul Van Delst

2004-05-12, 9:09 pm

Dr Chaos wrote:
> Paul Van Delst <paul.vandelst@noaa.gov> wrote:
>
>
>
> Other than using () for array access like Fortran and unlike C, other
> than having block structured control structures with "end" like
> Fortran and unlike C, other than having array slice notation and
> concepts like Fortran, and unlike C, unlike distinguishing pointers
> from arrays, like Fortran and unlike C, and having implicit
> declarations of variables like Fortran unlike C, and having array
> intrinsics, like Fortran and unlike C, having no 'address of'
> operator, like Fortran and unlike C....
>
> I guess maybe.
>
> whoops, changed my mind. :)

Allright allright... I concede! :o) But what about that darn ";" you have to stick at the
end of most lines to stop the results from being printed? Argh - drives me nuts.

When I meant it looked like C I really meant that most of the matlab code I've seen has
looked as much like a dog's dinner as most of the C code I've seen. But maybe that hasn't
anything to do with the language - I've seen plenty of horrendous Fortran code too -- some
of it, I hesitate to admit, my own a number of years after writing it. :o(

cheers,

paulv

Steven G. Kargl

2004-05-12, 9:09 pm

In article <409fed07$1_1@news.binaries.net>,
"beliavsky@aol.com" <beliavsky@127.0.0.1:7501> writes:

> It has rejected code that I had mistakenly thought was legal -- for example
>
> print "(i)",1
>
> The "(i)" format is not legal, but I think "(i0)" or (for example) "(i4)"
>
> is. LF95 does warn against "(i)" with
> the -f95 (strict F95) option, but G95 does not create an executable, which
> really gets my attention :).

I just read the section of the proposed standard that covers this.
A correct integer edit descript