On Mar 12, 7:45 am, Jan Vorbrüggen <jvorbrueg...@not-mediasec.de>
wrote:
> > Fortran will live if and only if
>
> > (0) It supports legacy code.
>
> This is certainly an important item on the priority list, but its relative
> importance is down on what it once was. In my personal opinion, there is
> nowadays to much material in the standard, with too many interactions among
> useful new features, because of this legacy support. A not-quite-so-dogmatic F
> would be the right thing to have. Being a bit more radical, with F03 do away
> with the F77-type fixed-length strings and only use variable-length strings.
>


> > (1) It remains a small,fast language.
>
> Fast has mmore than one aspect, but fast execution is still relevant.
>
> Small is in the eye of the beholder. For all its warts, Fortran is still quite
> regular and principled, compared to, for instance, C, and small compared to,
> for instance, C++. Do away with some of the legacy support mentioned above,
> and even F03 can still be considered to be small.
>
> > (2) The language allows for relatively simple compilers to be written.
>
> Entirely irrelevant. Most of the code is in the optimization part anyway,and
> that is to a large degree indepedent of the fron-end language - except for
> such things as supporting arrays as first-calls citizens.
>
> > (3) It has to be able to do dirty things
>
> > a) either as part of the language (without violating 1 and 2 above)
>
> > b) or as extensions supported by most vendors
>
> > c) or mixed language (C primarily) programming or by calling object
> > code complied from other languages.
>
> > Dirty things would include pipes,system calls, command line arguments,
> > accessing databases, Byte stream I/O (to support newer filetypes) to
> > name a few.
>
> Always been possible, did that almost thirty years ago. Not part of the
> standardized language anyway. A far smaller fraction of this is actually
> doable in standard C than people think.
>
> > (4) This is a tough one - allow for parallel processing. It would be
> > best if opportunities for parallelization are recognized by the
> > compiler - but if explicit parallelization cannot be introduced into
> > Fortran without destroying the look and feel of the language then
> > perhaps the explicitly parallel operations should be done with C
> > routines callable from Fortran.
>
> Entirely orthogonal to the language for many approaches to parallelism.
> Data-parallel is useful in a sufficient number of cases, and sufficientlywell
> supported, that it is supposed to become part of F08.
>
> > The philosophy of the official Fortran enhancement path seems to have
> > been to add a gazillion features considered "modern" as (0) was
> > maintained - and the result is a sad failure - just about EVERY
> > "modern" feature in Fortran is a "Yes,but".
>
> > Do you have pointers ? yes, but....
>
> With the but saying "...but this time we got it correct (compared to C)."
>
> > Do you have OOP ? yes, but ....
>
> With the but saying "but this time we got a more useful and much safer version
> than C++."
>
> > Do you have dynamic memory ? yes, but...
>
> With the but saying "but this time we got it correct compared to both C and C++."
>
> > The elementary C notion of variable length string seems to give
> > Fortran a stroke.
>
> C does not have variable lengths strings. C has an abomination instead that
> should be banned from being used due to its warts and proneness to serious
> errors. And the support routines are even worse.
>
> Jan

http://www.adass.org/adass/proceedings/adass99/P2-38/

How many more conversions like this can Fortran survive ?

True this article explicitly says that lack of f90 compilers was one
reason for the migration - but for whatever reason, the heartland of
Fortran apps was decimated during the decade of 1980.

We may argue till we are blue in the face about the superiority of
modern fortrans, buy until we start reading stories of reverse
migrations (C,C++,Java) to fortran the picture is dismal.

start quote

2. Why Convert to C?
There were three major reasons, listed in decreasing importance.


2.1. Job Market for Graduate Students
Most entering graduate students bring in some knowledge of C or Visual
Basic. Most do not end up on a track leading to a tenured position at
a research university, and many go into computer-related fields. The
job market for C programmers is vastly richer than for Fortran
experts. This is true both at the local level here in Lexington and in
national astronomical centers. Students would be far more competitive
in the job market if they had several years of experience developing
large-scale C programs. Graduate students rely on the faculty to make
choices that are in their long-term interests. If we can get our work
done in a C environment, we owe it to our students to do so.


2.2. Open Source/GNU Friendly
Fortran 95 is a modern language. Unfortunately, the Open Source
movement does not support Fortran beyond the f2c conversion utility
and the g77 compiler. Modern compilers are commercially available but
are expensive, making modern Fortran more like IDL than a true ANSI
language. As a result, portable Fortran code cannot go much beyond
FORTRAN 77. At the same time, the C++ standard has now existed for
well over a year and the gcc compiler and its standard template
library are moving ever closer to full compliance. gcc has long been
fully compliant with 1989 ANSI C.


2.3. Leverage Other Technologies
Most system shells and higher-level languages carry intellectual
heritage from C. As universities change to better take advantage of
the web, languages like Java, XGL, and SQL will become increasingly
important. A C environment makes this both easy and natural

end quote.

I think that becoming larger or more capable or cleaner or more
regular are losing propositions for Fortran when it comes to the
fundamental question of survival.

In real life,with respect to C/C++/Java, modern fortrans are (rightly
or wrongly) considered to offer no real advantages by the overwhelming
mass of managers (especially in the private sector) who make language/
platform decisions. Add on top of it the colossal commercial success
of these languages, then "total cost of ownership" arguments ensure
that new projects in Fortran are non-starters.

After all, I would argue that as of 2007, Fortran has less than 1 pct
share of number-crunching type computing in business.

So, "back to the future" is the best chance of survival - after all
unbelievably powerful code was written with Fortran 77 (I remember a
"60 minutes" documentary about Soviet missiles, and IIRC they showed
fortran code scrolling on a CRT in the control room). Somehow fortran
was practically extinguished in the 1980s by the move to "modernity"
and that near-death experience is not reversible. Whatever the new
fortrans have to offer over and above f77 is too late.

ONLY what remains of the f77 legacy can now be saved, and that has to
be done with the "small superset" strategy.

The only future for f90 etc. is the museum.