Should anyone be using 'modern' Fortran any more?

[Terence]

Since the C.L.F. forum clearly demonstrates a constant series of problems of
programmers with interpreting standards, and of getting compilers to
actually run, or getting the right set of options in place, is the real
problem the un-necessarily increased complexity of 'modern' Fortran (post
F90 at least)?

Here, I am raising a serious question, not attempting to 'prod the tiger'
even as some will perceive it as such.
I have a long history (53 actual years) of seeing large Fortran programs and
of adapting several, and I've taught F77 Fortran to London University
students (and these are bright young people). And my own commercial programs
are still running and being used on many computer types and operating
systems since 1977.

I agree that one or two post-F77 features of Fortran were important and
needed.
(E.g. 'IMPLICIT NONE', the ability to perform bit-wise logic, and the
IF..THEN..ELSE. ENDIF paragraph in particular).And very important, the
ability to use unformatted streams of data ('BINARY' or 'TRANSPARENT'
attributes)

So, given these extensions, the whatever-you-want-call-it resulting version
(possibly not a standard), is what I think is easily teachable and very
useful as a general programming langauge. A good example of one I use (with
out needing all the features) is the CVF F90/95 compiler.

I think many other features available in F90 and onwards are just
'convenience' tools, and especially that anything can be written using F77
through F90 style coding.

Any perceived limitation of coding with F77 through F90-limited features,
almost certainly has a simple way around.

I infer that market forces (read developer companies) are forcing the onward
march to final extinction of Fortran, by requiring the teaching bodies and
government organisations to upgrade to the newest standard. But this impacts
on teaching and upgrading programmers by employers or the self-employed

I am proposing as a thought, without seeing how to accomplish this, is a
move in the opposite direction, to re-simplification by setting a new
simpler 'programmer's standard', with the 'new' post-F90 parts as voluntary
extensions by the compiler suppliers. I would like to see this new
'standard' as a qualification for employment.

Thoughts?

[Richard Maine]

Terence <tbwr...@bigpond.net.au> wrote:

> Since the C.L.F. forum clearly demonstrates a constant series of problems of
> programmers with interpreting standards, and of getting compilers to
> actually run, or getting the right set of options in place, is the real
> problem the un-necessarily increased complexity of 'modern' Fortran (post
> F90 at least)?

...
> Thoughts?

My thought is that you are seeing what you expect or want to see. The
reason you are seeing mostly questions about newer standards is that is
all that anyone much cares about.

As an aside, the most recent problem I responded to on this newsgroup
was actually a problem relating to a feature from those "good old days",
namely statement functions. Rather than being simple and easy to teach,
the quirks of statement functions were the source of the confusions.

I've been both programming for myself and helping others for... well not
quite as long as you have... but for about 45 years now. I recall many,
many questions from those earlier allegedly simpler days that I think
you are seeing through rose-colored glasses.

No I do not think at all that

> Any perceived limitation of coding with F77 through F90-limited features,
> almost certainly has a simple way around.

Quite the opposite, before I decided to try f90 (which was before any
f90 compilers were actually available) I was prepared to abandon the
language entirely because I saw continuing with f77 plus limitted
extensions as too painful to be acceptable. I know plenty of people who
did abandon the language for simillar reasons.

IF/THEN/ELSE/ENDIF, by the way, was added in f77.

I don't care to argue the point with you. Been there. Done that. No
constructive result ensued (except to the extent that it was probably
constructive to stop arguing).

Just registering my complete disagreement with almost everything in your
post. This is probably not much of a surprise.

--
Richard Maine
email: last name at domain . net
domain: summer-triangle

[Ian Harvey]

On 2013-05-16 10:40 AM, Terence wrote:
> Since the C.L.F. forum clearly demonstrates a constant series of problems of
> programmers with interpreting standards, and of getting compilers to
> actually run, or getting the right set of options in place, is the real
> problem the un-necessarily increased complexity of 'modern' Fortran (post
> F90 at least)?

No.

(Getting compilers to run or run with the right set of options has
nothing to do with language standard.)

> Here, I am raising a serious question, not attempting to 'prod the tiger'
> even as some will perceive it as such.
> I have a long history (53 actual years) of seeing large Fortran programs and
> of adapting several, and I've taught F77 Fortran to London University
> students (and these are bright young people). And my own commercial programs
> are still running and being used on many computer types and operating
> systems since 1977.
>
> I agree that one or two post-F77 features of Fortran were important and
> needed.
> (E.g. 'IMPLICIT NONE', the ability to perform bit-wise logic, and the
> IF..THEN..ELSE. ENDIF paragraph in particular).And very important, the
> ability to use unformatted streams of data ('BINARY' or 'TRANSPARENT'
> attributes)
>
> So, given these extensions, the whatever-you-want-call-it resulting version
> (possibly not a standard), is what I think is easily teachable and very
> useful as a general programming langauge. A good example of one I use (with
> out needing all the features) is the CVF F90/95 compiler.
>
> I think many other features available in F90 and onwards are just
> 'convenience' tools, and especially that anything can be written using F77
> through F90 style coding.

Fascinated to know how you'd implement dynamic allocation, polymorphism
or coarrays in F77.

At some point, any sort of computer language is a "convenience" - you
could always go an work at the machine instruction level!

> Any perceived limitation of coding with F77 through F90-limited features,
> almost certainly has a simple way around.
>
> I infer that market forces (read developer companies) are forcing the onward
> march to final extinction of Fortran, by requiring the teaching bodies and
> government organisations to upgrade to the newest standard. But this impacts
> on teaching and upgrading programmers by employers or the self-employed

I think you have the forces backwards. Users are agitating for change
because they want improvements in the language that allow them to
productively build upon their existing source base, compiler vendors are
resisting because developing compilers takes real effort and money/time.
I don't have a problem with that dynamic, as long as it doesn't swing
too far either way.

> I am proposing as a thought, without seeing how to accomplish this, is a
> move in the opposite direction, to re-simplification by setting a new
> simpler 'programmer's standard', with the 'new' post-F90 parts as voluntary
> extensions by the compiler suppliers. I would like to see this new
> 'standard' as a qualification for employment.

Make sure you get rid of the really complicated and confusing stuff -
implicit typing, storage association (common and equivalence), fixed
form source, implicit procedure references, non-generic intrinsics,
inconsistent statement forms and constructs, statement functions,
alternate returns...

For many of the above, I recall reading a document recently that
effectively recommended that those things be avoided. Can't remember
the details, but it had ISO 1539 or something similar in the title.

> Thoughts?

History shows an undeniable large loss in Fortran's "market share" from
say the early 1980's on. It wasn't able to compete back then. If you
left the language pretty much as it was back then, then it clearly still
wouldn't be able to compete today. I suspect that without the F90
revision, Fortran would by now be dead.

Today, the reality that the language will continue to slowly but
steadily evolve to suit the needs of its user base is a reason for the
user base to stick with the language.

[Wolfgang Kilian]

On 05/16/2013 02:40 AM, Terence wrote:
> Since the C.L.F. forum clearly demonstrates a constant series of problems of
> programmers with interpreting standards, and of getting compilers to
> actually run, or getting the right set of options in place, is the real
> problem the un-necessarily increased complexity of 'modern' Fortran (post
> F90 at least)?

No. The real problems that we (our group) face is the slow pace by
which the current Standard gets implemented in common compilers. (No
offense to the compiler writers, they are doing an excellent job with
their available resources.)

That is obviously a consequence of the small 'market share'. This, in
turn, is obviously a consequence of the bad reputation which F77 got in
the 80s and 90s.

> Here, I am raising a serious question, not attempting to 'prod the tiger'
> even as some will perceive it as such.
> I have a long history (53 actual years) of seeing large Fortran programs and
> of adapting several, and I've taught F77 Fortran to London University
> students (and these are bright young people). And my own commercial programs
> are still running and being used on many computer types and operating
> systems since 1977.

Thanks to the committee which kept the Fortran Standard backwards
compatible while improving it over decades.

> I agree that one or two post-F77 features of Fortran were important and
> needed.
> (E.g. 'IMPLICIT NONE', the ability to perform bit-wise logic, and the
> IF..THEN..ELSE. ENDIF paragraph in particular).And very important, the
> ability to use unformatted streams of data ('BINARY' or 'TRANSPARENT'
> attributes)
>
> So, given these extensions, the whatever-you-want-call-it resulting version
> (possibly not a standard), is what I think is easily teachable and very
> useful as a general programming langauge. A good example of one I use (with
> out needing all the features) is the CVF F90/95 compiler.
>
> I think many other features available in F90 and onwards are just
> 'convenience' tools, and especially that anything can be written using F77
> through F90 style coding.

No. Nowadays, everybody is used to code in C++, Java, and related
languages. Many understand functional languages (ML, Scala, etc.). You
have a hard time convincing a young programmer to use a language which
doesn't support a straightforward object-oriented approach (supported in
modern Fortran) and generic programming techniques (still missing in
Fortran).

These are not convenience features. This has become the basic way of
thinking about programs.

> Any perceived limitation of coding with F77 through F90-limited features,
> almost certainly has a simple way around.
>
> I infer that market forces (read developer companies) are forcing the onward
> march to final extinction of Fortran, by requiring the teaching bodies and
> government organisations to upgrade to the newest standard. But this impacts
> on teaching and upgrading programmers by employers or the self-employed

Since Fortran began supporting modern programming techniques, it is
slowly re-gaining popularity. The crucial point, however, will be how
to efficiently make use of parallel hardware. Introducing coarrays as
an integral part of the language was a smart move, hopefully they will
turn out really useful.

> I am proposing as a thought, without seeing how to accomplish this, is a
> move in the opposite direction, to re-simplification by setting a new
> simpler 'programmer's standard', with the 'new' post-F90 parts as voluntary
> extensions by the compiler suppliers. I would like to see this new
> 'standard' as a qualification for employment.

Go ahead. This would lead to the immediate extinction of the language.

> Thoughts?

-- Wolfgang


--
E-mail: firstnameini...@domain.de
Domain: yahoo

[Terence]

>Just registering my complete disagreement with almost everything in your
>post. This is probably not much of a surprise.

>Richard Maine

Just as you (usually) imply that I am stuck in the mud, I think you are
oppositly biased in the 'development must continue' direction (whatever this
does for the future of Fortran).

I'm rather familiar with university professors (e.g. physics, archeology,
anthopology) who defend against reported winds of changes in their
provinces, not only because their influence and book sales would drop.

Fortran must remain as an easily learned, easily taught, and easily used
programming language, if it is going to continue to be taught, learned and
used.

By the way, the statement function feature you mentioned, was as far as I
remember, a feature I and Fortran teachers I had dealings with, a feature we
suggested to students as adviasabl to not used, if a subroutine could be
written once or borrowed from other sources or linkable libraries.
Honestly, I never used such a device in all my years of programming.

I'll give you that you are correct that the IF..THEN..ELSE..ENDIF structure
was in the F77 standard (and in my faithful compiler too), but it wasn't
implemented in two others I remember using when I think of working with F77
(available on an HP minicomputer and another on a process control machine,
both supposedly F77 compilers). I was distracted as to which were early
compilers were missing this feature, it and how useful I eventually found
it in my later F77 compiler of 1985. A Burroughs BTOS Fortran compiler I
still have the documentation for, lacks this feature, but defines itself as
being an F77 compiler.

The point is teachability in a reasonablr time frame. Else extinction.

[Anton Shterenlikht]

"Terence" <tbwr...@bigpond.net.au> writes:

>The point is teachability in a reasonablr time frame. Else extinction.

The real point is that the language
must be relevant to users' needs.

The questions students ask me typically are:
Why bother? Can't I do this in matlab?
To which I usually reply that one should
choose the right tool for the job.

There are many ways you can teach a computer
language, from a day course, to a full year course.
Obviously you don't start from OO or coarray features
or floating point exception handling.
Indeed, I've been using fortran for a number of
years, but I don't know probably even a half
of the features the latest standard provide.
I don't see a problem with that.

Anyway, it is precisely because fortran is
evolving, that it remains an attractive language.

My interests are in HPC. Fortran remains the
dominant HPC language [1,2]. I believe coarrays
will increase the fortran user base in HPC.
Having coarrays in the standard is nothing short of a miracle!
I anticipate that apart from providing the users
with unprecedented standardised! parallel SIMD simplicity,
the coarrays will improve the competition
between compiler providers/vendors, because
there is a lot of scope for optimising the performance
of coarray operations.

Anton

[1] www.prace-project.eu/IMG/pdf/D7-4-1_1ip.pdf
[2] http://sc12.supercomputing.org/schedule/event_detail.php?evid=tut141

[Gib Bogle]

On 16/05/2013 12:40 p.m., Terence wrote:
> Since the C.L.F. forum clearly demonstrates a constant series of problems of
> programmers with interpreting standards, and of getting compilers to
> actually run, or getting the right set of options in place, is the real
> problem the un-necessarily increased complexity of 'modern' Fortran (post
> F90 at least)?

There are many features in the most recent Fortran that I do not know
about and will never use. That doesn't affect me. I do find extremely
useful many of the features in F95 that were not in F77. I can't
imagine going back to F77.

[James Van Buskirk]

"Terence" <tbwr...@bigpond.net.au> wrote in message
news:kn1o4r$9nq$1...@dont-email.me...

> I agree that one or two post-F77 features of Fortran were important and
> needed.
> (E.g. 'IMPLICIT NONE', the ability to perform bit-wise logic, and the
> IF..THEN..ELSE. ENDIF paragraph in particular).And very important, the
> ability to use unformatted streams of data ('BINARY' or 'TRANSPARENT'
> attributes)

How about dynamic memory? F77 programs had to have a big
incomprehensible chunk reserved for doing that the F77 way. C
interoperability is a big deal in my view because it lets the
Fortran programmer attempt to access APIs available on a given
OS. Of course when OS writers found out that Fortran could
interoperate with C, they switched to other languages, such
as C++ and Objective C to further confound the issue. Have
you tried to interoperate with Objective C without
!DEC$ ATTRIBUTES VARYING? No fun, especially given that there
is a way to read Fortran standards that says that you can't
have different interface bodies with the same binding name.

--
write(*,*) transfer((/17.392111325966148d0,6.5794487871554595D-85, &
6.0134700243160014d-154/),(/'x'/)); end

[e p chandler]

Terence wrote:

> Fortran must remain as an easily learned, easily taught, and easily used
> programming language, if it is going to continue to be taught, learned and
> used.

The simplest answer, IMO, is to teach and use those features that you like. I started modern Fortran with G77 and went from there.

I think it is important to get students away from using F66 or F77. I recently posted a modern Fortran version of an old program that dealt with the nuclear physics of stars. Both versions compile and produce output. IMO, my version makes it much easier to talk about what the program is actually doing.

--- e

[baf]

On 5/16/2013 12:35 AM, Terence wrote:
>> Just registering my complete disagreement with almost everything in your
>> post. This is probably not much of a surprise.
>> Richard Maine
>
> Just as you (usually) imply that I am stuck in the mud, I think you are
> oppositly biased in the 'development must continue' direction (whatever this
> does for the future of Fortran).
>
> I'm rather familiar with university professors (e.g. physics, archeology,
> anthopology) who defend against reported winds of changes in their
> provinces, not only because their influence and book sales would drop.
>
> Fortran must remain as an easily learned, easily taught, and easily used
> programming language, if it is going to continue to be taught, learned and
> used.

I got a chuckle out of that statement. Two very popular languages today
are c++ and java, neither of which are easily learned, easily taught, or
easily used if you want to incorporate all of the language features.

Using the basic features of "modern" Fortran are easier to learn and use
than it was with F77. Use whatever features you enjoy Terence and be
thankful that your old code will still compile with a "modern" Fortran
compiler.

[glen herrmannsfeldt]

baf <b...@nowhere.com> wrote:
> On 5/16/2013 12:35 AM, Terence wrote:
>>> Just registering my complete disagreement with almost everything in your
>>> post. This is probably not much of a surprise.
>>> Richard Maine

I think I see, at least a little bit, what Terence means.

In the months that they had to define the PL/I language, now just
about 50 years ago, they decided that they couldn't do it as an
extension of Fortran. Many PL/I features made it into Fortran 2003,
so I might say that it took 40 years to do it.

>> Just as you (usually) imply that I am stuck in the mud, I think you are
>> oppositly biased in the 'development must continue' direction (whatever
>> this does for the future of Fortran).

PL/I is a pretty complicated languages (especially for 1963) but
it isn't so hard to find an easily learned (and taught) subset.

Seems to me that Terence is noting that it isn't quite as easy
to teach a subset of Fortran. Complications have a way of sneaking
into simpler subsets.

>> I'm rather familiar with university professors (e.g. physics, archeology,
>> anthopology) who defend against reported winds of changes in their
>> provinces, not only because their influence and book sales would drop.

>> Fortran must remain as an easily learned, easily taught, and easily used
>> programming language, if it is going to continue to be taught, learned and
>> used.

> I got a chuckle out of that statement. Two very popular languages today
> are c++ and java, neither of which are easily learned, easily taught, or
> easily used if you want to incorporate all of the language features.

Well, C++ and Java are, if you don't count the complications in
the class libraries, fairly simple languages. With an appropriate
subset of class libraries, and delaying the teaching of objects
and instance methods, it isn't hard to teach Java to beginners.

> Using the basic features of "modern" Fortran are easier to learn and use
> than it was with F77. Use whatever features you enjoy Terence and be
> thankful that your old code will still compile with a "modern" Fortran
> compiler.

Yes, but it isn't quite as easy to do as for some other languages.
Partly it is from the complications of staying compatible with the
older versions of the standard.

As an example, PL/I only passes arrays by descriptor, somewhat like
Fortran assumed shape. (Unlike Fortran, the upper and lower bound
are passed.) That presumably complicated porting of routines using
all the fun tricks one can do with assumed size arrays.

But PL/I was also much better than Fortran at orthogonality.
If something worked one way in one place, it should work in a
similar way in other places. Fortran has been very slow at
following that idea.

-- glen

[Richard Maine]

glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:

> Seems to me that Terence is noting that it isn't quite as easy
> to teach a subset of Fortran. Complications have a way of sneaking
> into simpler subsets.

There are people who seem to do a fine job of teaching subsets of
Fortran. Ask Walt, for one.

And, of course, Terence actually *IS* proposing teaching a subset -
quite explicitly so. Seems to me that was his entire point: to define a
subset language. His subset just happens to be completely different from
one I'd choose.

[John Harper]

glen herrmannsfeldt wrote:

> In the months that they had to define the PL/I language, now just
> about 50 years ago, they decided that they couldn't do it as an
> extension of Fortran. Many PL/I features made it into Fortran 2003,
> so I might say that it took 40 years to do it.

Algol 68 had a feature that f2008 hasn't, 40 years later: allowing the user
to specify the precedence of a defined operator. I know this can be misused
but so can a box of matches.

--
John Harper

[Robin Vowels]

On May 17, 3:40 am, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
> baf <b...@nowhere.com> wrote:
> > On 5/16/2013 12:35 AM, Terence wrote:
> >>> Just registering my complete disagreement with almost everything in your
> >>> post. This is probably not much of a surprise.
> >>> Richard Maine
>
> I think I see, at least a little bit, what Terence means.
>
> In the months that they had to define the PL/I language,

It took 3 years to define PL/I, from 1963.

> now just
> about 50 years ago, they decided that they couldn't do it as an
> extension of Fortran. Many PL/I features made it into Fortran 2003,
> so I might say that it took 40 years to do it.

Nowhere near there yet.
Error handling, just to mention one major feature.

[Robin Vowels]

On May 16, 3:22 pm, nos...@see.signature (Richard Maine) wrote:

> As an aside, the most recent problem I responded to on this newsgroup
> was actually a problem relating to a feature from those "good old days",
> namely statement functions. Rather than being simple and easy to teach,
> the quirks of statement functions were the source of the confusions.

Statement functions were provided so that a mathematical formula
could be expressed in an almost identical form in Fortran,

e.g., f(x) = a*x**2 + b*x + c

and were simple to use.

[Robin Vowels]

On May 16, 5:03 pm, Wolfgang Kilian <kil...@invalid.com> wrote:
> On 05/16/2013 02:40 AM, Terence wrote:

> > Here, I am raising a serious question, not attempting to 'prod the tiger'
> > even as some will perceive it as such.
> > I have a long history (53 actual years) of seeing large Fortran programs and
> > of adapting several, and I've taught F77 Fortran to London University
> > students (and these are bright young people). And my own commercial programs
> > are still running and being used on many computer types and operating
> > systems since 1977.
>
> Thanks to the committee which kept the Fortran Standard backwards
> compatible while improving it over decades.

Well, Fortran is actually not backwards compatible.
Think of one-trip DO, Hollerith constants, etc.

[Gordon Sande]

One-trip DO was a programming mistake that was rarely diagnosed.

Extended range DO went away

[glen herrmannsfeldt]

Robin Vowels <robin....@gmail.com> wrote:

(snip, I wrote)

>> In the months that they had to define the PL/I language,

> It took 3 years to define PL/I, from 1963.

It is not so easy to define the time.

In Feb. 1963, there was discussion about Fortran V or to go
directly to Fortran VI. They were working on the new language
in October 1963, with a December 1963 deadline. The deadline
was then extended to January, and later February. The first
document was released to SHARE in March 1964. A more detailed
document was ready in November, and officially released as the
"NPL Technical Report" in December 1964.

"The period between April and November 1964 was marked by
a staggering amount of language definition, debate,
presentation and early compiler implementation.
It is impossible in this short paper to describe this
activity properly."

-- glen

[Robin Vowels]

On May 17, 11:18 am, glen herrmannsfeldt <g...@ugcs.caltech.edu>
wrote:

The design of PL/I was not actually completed until 1967.

[William Clodius]

I disagree strongly. People didn't leave F77 because the problems with
F77 were easy to code around, they left because what they wanted to do
they couldn't do in anything similar to F77. IF..THEN..ELSE. ENDIF was
in F77, and the rest you suggest was sufficient was in MIL-STD 1753,
which was promulgated before F77 was officialy published, and supported
in the US by every significant compiler vendor by 1985. Allocatables,
derived types, explicit interfaces DO .. END DO (your past examples
attempting to show the contrary I consider terrible at implying intent
and difficult to maintain), SELECT CASE, free form, etc. are all useful
and your repeated failure to recognize that suggests far more about your
own limitations than about problems with F90+.

[JB]

My initial thought is a more or less complete disagreement with
everything you say. A few (related?) points:

I don't think that Fortran, per se, is dying. I'd guess it's share of
the total programming pie is getting smaller, but just because Fortran
may not be the #1 choice for making dynamic web sites doesn't mean
that it's suddenly a bad choice for, say, numerical programming tasks.

In particular, I disagree with the notion that the supposed demise of
Fortran is due to the added complexity since F77. On the contrary, I
suspect one big reason why the systems programming community abandoned
Fortran was that the lack of things like dynamical memory management,
record types, pointers, explicit interfaces etc. made things too
painful for what they were interested in doing. And thus mostly only
the scientific/numerical community remained in Fortran-land, and
everybody else moved on.

I also don't think a restricted F77-like subset would attract any
attention in an educational setting. As a tool for learning
numerical/statistical computing Fortran died a long time ago, not
because F90+ was too complicated, but due to the advent of high-level
interactive environments with large bodies of included libraries and
visualization functionality. Such as:

- R
- MATLAB
- The scientific python stack
(numpy/scipy/matplotlib/pandas/scikit-*/etc.)

Of course, many of the libraries forming the basis of the
above-mentioned environments are still implemented in Fortran. These
(interpreted) environments do suffer from the fact that unless one
manages to implement whatever one is doing in terms of array
expressions, performance is much lower than a compiled language such
as Fortran. But, with the speed of modern computers and the typically
small data sets used in education, it's not an issue in
practice. Furthermore, in case it is an issue, all of these
environments have facilities for implementing functionality in lower
level languages for performance reasons as well.

So that leaves Fortran entrenched in a niche as a language for doing
non-trivial (mostly numerical) applications. And for large-scale
programming, lack of F90+ features such as dynamical memory
allocation, pointers, derived types, and explicit interfaces would be
enough to instantly disqualify the language, IMHO.

--
JB

[michael...@compuserve.com]

On Monday, May 20, 2013 9:43:29 AM UTC+2, JB wrote:
>
>
>
> I also don't think a restricted F77-like subset would attract any
>
> attention in an educational setting.

Or any subset. The F77 subset language was never really used, and the F Programming language, sadly, failed to take off :-(.

Regards,

Mike Metcalf

[gmail-unlp]

On May 19, 12:34 am, wclod...@earthlink.net (William Clodius) wrote:

Which reminds me of
http://en.wiktionary.org/wiki/if_all_you_have_is_a_hammer,_everything_looks_like_a_nail

Fernando.

[Walt Brainerd]

I, too, am a little sad that F did not "take off", but
certainly not surprised (and therefore, not too disappointed).

I thought there were two reasons for F: one, as an educational
tool, so one could learn the "new" stuff without being distracted
by the old; two, and probably the only reason it was used some,
is that it was the only free implementation that included the
features of Fortran 90--when g95 and gfortran came along, this
reason disappeared.

[fj]

I tried to use F many years ago, but I decided to give up because F was unable to manage the F77 style.

For an entirely new code, F could be an acceptable choice, but in practice, one rarely starts from scratch !

[Phillip Helbig---undress to reply]

In article <_uOdnf0iGffMyQfM...@swcp.com>, Walt Brainerd

<wa...@swcp.com> writes:

> I, too, am a little sad that F did not "take off", but
> certainly not surprised (and therefore, not too disappointed).

I thought it was a good idea. However, around the same time there was
elf, also a subset, but a different one.

[anal...@hotmail.com]

This used to be my leitmotif in this ng. years ago for which I got
thoroughly beaten up.

Anybody who lives in the real world would realize that there is
gentlemen's coding and coding by drudges who face project managers,
production support, time charges, code reviews etc.

Rightly or wrongly, history has passed Fortran by as a language
suitable for the latter type of coding - and therefore the only
competition is with "gentelemen's" languages such as R,Matlab etc.

If this is agreed to - then there is an upper bound to how "big"
Fortran should get. C,C++,Java are different in kind from fortran and
any mating (such as interoperability) would only result in sterile
offspring.

Fortran is fairly close to pseudo-code for any number of tasks, and is
also fairly fast - which are the necessary and sufficient reasons for
it to continue to exist.

The notion that grown-up features such as Modules and Interfaces would
allow for large production fortran programs written by teams to exist
and be maintained has been proven by reality to be false.

Once it is agreed that its potential continued existence would only be
justified by proof-of-concept type code written by a single programmer
- it would become crystal clear how it ought to evolve.

[Walt Brainerd]

Of course, it was never meant to "take over" in a production environment
because, as you say, it would compile no existing
programs (of the time).

[Walt Brainerd]

Yeah, we had similar ideas at almost exactly the same time.
We tried to get Lahey to agree to a common subset, but he
refused to talk with us--said he had his own subset and
didn't need ours (F).

Loren Meissner wrote a book in which all the programs
ran on both subsets. The only real conflict was that Lahey
required IMPLICIT NONE and F didn't allow it (everything
had to be declared anyway), so we agreed to allow it to
avoid that problem.

[Richard Maine]

anal...@hotmail.com <anal...@hotmail.com> wrote:

[things that I and, I'm sure many others here, don't agree with]

> If this is agreed to...
> Once it is agreed...

And if pigs had wings, many things could be concluded.

But since pigs don't have wings, that's moot.

[Nasser M. Abbasi]

On 5/20/2013 2:43 AM, JB wrote:

> These
> (interpreted) environments do suffer from the fact that unless one
> manages to implement whatever one is doing in terms of array
> expressions, performance is much lower than a compiled language such

> as Fortran. ...
>...

> So that leaves Fortran entrenched in a niche as a language for doing
> non-trivial (mostly numerical) applications. And for large-scale
> programming, lack of F90+ features such as dynamical memory
> allocation, pointers, derived types, and explicit interfaces would be
> enough to instantly disqualify the language, IMHO.
>

FYI, You might like to look at Julia, a new "dynamic" language aimed
for scientific applications.

http://julialang.org/

"Julia�s LLVM-based just-in-time (JIT) compiler combined with
the language�s design allow it to approach and often match
the performance of C. "

See figure above for comparing performance with other languages.

Ofocurse, it remains to be seen if Julia will make it. It is only 1 year old,
It seems interesting though.

--Nasser

[Brian Salter-Duke]

I have been hesitating about joining in here as I am stuck for several
reasons in a f77/f90 time warp. The Fortran code I see is entirely in
the quantum chemistry field where large programs have developed over
many years by many people. What surprises me after keeping up with this
group for quite a long while is how few of the F90+ features have
actually been taken up in these Fortran programs. One of the most
popular is Gaussian, which goes back to the early 1970s when it was free
and is now sold by Gaussian Inc with few users ever seeing the actual
code. I have only seen bits of the code recently but it still seems to
be largely f77. I am an author of a valence bond code which interfaces
to the popular GAMESS(US) program. Until recently that was strictly f77
or at least on what ftnchek accepted as f77 as it relied heavily on
ftnchek. Very recently it has moved to use more f90 features. A modern
ftnchek is in progress (or out?). We have therefore kept our valence
bond code to be f77, although all new routines I write now use IMPLICIT
NONE and the other f90 features the OP mentioned. Several other quantum
chemistry programs also still use f77, although some use C++ rather than
Fortran and some use more modern Fortrans.

If you work on a very large f77 program it seems difficult to move to
modern Fortran and I suspect that this is the case in fields other than
quantum chemistry. I would welcome Ron Shepard's views as he is in this
field and he has moved on to modern Fortran. His insights on why so few
of us have done so may be interesting.

Brian.

--
Brian Salter-Duke (Brian Duke), Melbourne, Australia
My real address is b_duke(AT)bigpond(DOT)net(DOT)au
Use this for reply or followup
"A good programmer can write Fortran in any language"

[Terence]

Glen wrote:
PL/I is a pretty complicated languages (especially for 1963) but
it isn't so hard to find an easily learned (and taught) subset.

Seems to me that Terence is noting that it isn't quite as easy
to teach a subset of Fortran. Complications have a way of sneaking
into simpler subsets.

Actually Glen, the Fortran I taught was then the latest, known in IBM as '
Fortran 4/1/61' and not a subset. That was the version used to design the
electricity pylons you still see around any country.

I suppose the version was intended to be Fortran III, but not released as
such, and the next version I found myself using was Fortran IV on mainframes
and the /360 and later /370 series.

As for Pl/1 I found it very easy to learn. (I think it was written in UK
IBM's Winchester labs by a huge team of new programmers). As an example of
its flexibility, I wrote my first language parsers in that code (actually
for a program suite to allow Dutch, English or Spanish speaking managers and
auditors to go though Shell's books in a batch mode and all without
specifying which language you were using to defien and speify the needed
reports. I know it was still running some 15 years after I left that area).

[\"Vladimír Fuka <"name.surnameat]

> FYI, You might like to look at Julia, a new "dynamic" language aimed
> for scientific applications.
>
> http://julialang.org/
>

> "Julia’s LLVM-based just-in-time (JIT) compiler combined with
> the language’s design allow it to approach and often match

> the performance of C. "
>
> See figure above for comparing performance with other languages.
>
> Ofocurse, it remains to be seen if Julia will make it. It is only 1 year
> old,
> It seems interesting though.

Seems nice, but not much targeted on parallelism. In this regard I like
Chapel more (chapel.cray.com)

Vladimir

[Thomas Jahns]

On 05/20/2013 08:41 PM, anal...@hotmail.com wrote:
> The notion that grown-up features such as Modules and Interfaces would
> allow for large production fortran programs written by teams to exist
> and be maintained has been proven by reality to be false.

In fact the model implementations from the climate community I happen to work on

- are very large production programs, that
- indeed use modules to encapsulate complexity and
- are developed by teams of several people.

Regards, Thomas

[anal...@hotmail.com]

On May 21, 4:51 am, Thomas Jahns <ja...@idontlikespam.dkrz.de> wrote:

Niche.

Readers' Digest is still around - but does that mean it has a future?

I don't give a damn anymore which way official fortran goes - the open
source free language R has become enormously powerful (not that it
doesn't have its own slash qz's to master) and if there is any
language Fortrn needs interoperability woth it is R. Then all
problems are solved - underneath R is probably C/C++ type code that
can do dirty things like database access /unbelievably sophisticated
graphics etc. that are alien to fortran to this day. I know, I know
these are not native parts of most languages but callable libraries -
but somehow they become elusive when you start looking for preferably
free ones that would work with Fortran.

I'll have that done for me - (if it doesn't exist already) and with
Fortran (even 77 would do at a pinch although free form source etc.
are nice) and R you would have a universal toolset.

Imagine a csv data set sitting out there (coudl even be on the web)
with the names of the columns in the first row - R can bring it in
into an object called a dataframe with one line of code. If you want
a list of unique values of a column , you say vector =
levels(as.factor(dataframe$column)) - and voila you have the unique
values in vector. Can you imagine how much must happen with Fortran
(or for that matter in C/C++/Java) to achieve what these two lines
can?

But R is slow and I have discoved that by combining R and Fortran I
can get a lot of gentleman's code accomplished.

[glen herrmannsfeldt]

anal...@hotmail.com <anal...@hotmail.com> wrote:
> On May 21, 4:51 am, Thomas Jahns <ja...@idontlikespam.dkrz.de> wrote:

(snip)

>> In fact the model implementations from the climate community
>> I happen to work on

>> - are very large production programs, that
>> - indeed use modules to encapsulate complexity and
>> - are developed by teams of several people.

(snip)

> I don't give a damn anymore which way official fortran goes - the open
> source free language R has become enormously powerful (not that it
> doesn't have its own slash qz's to master) and if there is any
> language Fortrn needs interoperability woth it is R.

As well as I know it, historically much of R, especially the add-in
package code, was Fortran. It might be that enough more has now been
done in C that Fortran isn't the majority, but I expect that there
is still a lot of Fortran there.

-- glen

[Ron Shepard]

In article <519adcbe$0$32114$1472...@news.sunsite.dk>,

Brian Salter-Duke <brian.ja...@gmail.com> wrote:

> If you work on a very large f77 program it seems difficult to move to
> modern Fortran and I suspect that this is the case in fields other than
> quantum chemistry. I would welcome Ron Shepard's views as he is in this
> field and he has moved on to modern Fortran. His insights on why so few
> of us have done so may be interesting.

Of course I can't speak for all quantum chemists, but maybe I can
say a few things about problems with conversions from f77 to modern
fortran.

One of the main ones has always been memory management. A lot of
quantum chemistry codes in the past 20 years run on parallel
computers, including linux clusters and Cray and IBM supercomputers.
These are typically "small memory" machines (where "small" of course
has changed over time) and they use distributed memory programming
models (or some kind of mixed shared and distributed memory
programming model). For this kind of environment, you need to
monitor how memory is used, and sometime change algorithms or
blocking parameters at runtime in order to keep things running
efficiently (or to run at all).

With f77, this was typically done by declaring some big static block
of memory and then aliasing sections of this memory through
subroutine argument lists. This makes for tedious programming and
debugging. It also requires aliasing various integer, real, double
precision, and logical arrays, which practically speaking works, but
it is outside of what the standard guarantees. And of course, it
makes any type checking done by the compiler useless in writing and
debugging code.

Allocatable and automatic arrays and the associated functionality
makes all this much easier in modern fortran. Of course, the
important part of this functionality was not really standardized
until f2003, and many of us thought this was so important that it
should have been included earlier, but that is different matter.
So now, debugging is much easier, and much of the work can be done
at compile time rather than at runtime with TKR checking, and so on.
The importance of this cannot be overstated. This ability in modern
fortran can reduce programming+debugging time by a factor of 10
compared to the old f77 approach.

However, a practical problem with the fortran implementation is that
it does not allow the programmer to query the system to see how much
memory has been used or how much is available. These kinds of
things were relatively straightforward with the old style f77
approach, and they are basically impossible with modern fortran. So
if you can't monitor and control memory usage, or adjust your
algorithm according to memory usage, it is going to be limited in
its applicability on modern supercomptuers, and that is the
environment where fortran has (or would have, if the functionality
existed) the biggest advantage over other languages.

$.02 -Ron Shepard

[e p chandler]

On Tuesday, May 21, 2013 11:52:53 AM UTC-4, Ron Shepard wrote:
> Of course I can't speak for all quantum chemists, but maybe I can
> say a few things about problems with conversions from f77 to modern
> fortran.

> One of the main ones has always been memory management. A lot of
> quantum chemistry codes in the past 20 years run on parallel
> computers, including linux clusters and Cray and IBM supercomputers.
> These are typically "small memory" machines (where "small" of course
> has changed over time) and they use distributed memory programming
> models (or some kind of mixed shared and distributed memory
> programming model). For this kind of environment, you need to
> monitor how memory is used, and sometime change algorithms or
> blocking parameters at runtime in order to keep things running
> efficiently (or to run at all).

> With f77, this was typically done by declaring some big static block
> of memory and then aliasing sections of this memory through

> However, a practical problem with the fortran implementation is that
> it does not allow the programmer to query the system to see how much
> memory has been used or how much is available. These kinds of
> things were relatively straightforward with the old style f77
> approach, and they are basically impossible with modern fortran. So
> if you can't monitor and control memory usage, or adjust your
> algorithm according to memory usage, it is going to be limited in
> its applicability on modern supercomptuers, and that is the
> environment where fortran has (or would have, if the functionality
> existed) the biggest advantage over other languages.

Is it possible to use allocate & deallocate of a scratch array as a mechanism to determine how much memory is left? Or is an allocation failure a fatal error?

---- e

[Thomas Koenig]

anal...@hotmail.com <anal...@hotmail.com> schrieb:

> I don't give a damn anymore which way official fortran goes

Excellent.

If you don't have an interest, you might also consider to stop
trolling.

[Seneika]

Em 16/05/2013 04:03, Wolfgang Kilian escreveu:
> Since Fortran began supporting modern programming techniques, it is
> slowly re-gaining popularity. The crucial point, however, will be how
> to efficiently make use of parallel hardware. Introducing coarrays as
> an integral part of the language was a smart move, hopefully they will
> turn out really useful.

Well, I'm just an apprentice in these matters but when I started
programming (just a few years back), my undergraduate advisor passed
me some source codes for me to take a look. As I was already teaching
myself C, I found all that Fortran 77 code very awkward. I ended not
using any of his codes and I wrote everything by myself using Fortran
90/95 (whose existence my advisor wasn't aware of). Later on, I thought
about translating to C everything I had done to that point but the ease
of several whole-array operations made me stick with Fortran.

Now that compilers are implementing much of F2003 and even F2008 (by
"compilers" I mean gfortran, since I can no longer use ifort) and I can
use many of those OOP-like facilities, I can say I have had a huge
increase in productivity. I suspect most of it can be done in F77 (as
the OP would say) but I have only limited understanding of programming
and computing, and all the new "fancy stuff" really helps me.

Also, with Fortran-C interoperability, I can easily* use GSL (GNU
Scientific Library) and some other C or C++ libraries.

Just mentioning this for people to know what can lead newbies to choose
Fortran nowadays.

Seneika.

*I don't know whether this is possible with older Fortran or not.

PS: my field is theoretical astrophysics (evolution of neutron stars).

[glen herrmannsfeldt]

Seneika <notsp...@today.com> wrote:

(snip)

> Also, with Fortran-C interoperability, I can easily* use GSL (GNU
> Scientific Library) and some other C or C++ libraries.

(snip)

> *I don't know whether this is possible with older Fortran or not.

It usually is, but you have to do more work.

First, you have to find the corresponding types in each.

Usually INTEGER goes to int, REAL to float, and DOUBLE
PRECISION (or non-standard REAL*8) to double.

There are extra complications for C programs that use arrays
of pointers in place of 2D arrays.

Then you have to figure out how to make the subroutine or function
call work. If is usual for Fortran to pass the address of arguments,
and so the C routine should expect a pointer to the appropriate type.
There have been Fortran systems where the called routine had to pop
the arguments off the stack. That is not usual for C, as C allows
for functions with a variable number of arguments.

If the linker is case sensitive, you have to get case right on
the C side. Fortran traditionally didn't give you a choice.
Also, sometimes (especially with unix) there are extra underline
characters on the external names that you have to match.

Fortran COMMON usually matches up with a C external structure,
but the alignment might be different.

> PS: my field is theoretical astrophysics (evolution of neutron stars).

-- glen

[Brian Salter-Duke]

Thanks, Ron, for explaining all this better than I could. I fully agree
that going this way makes debugging of future additions to the code much
easier and much faster. However, rewriting the whole code to go this way
is aften beyond the resources of the authors of some programs. The VB
code has three authors, Roy McWeeny stopped doing anything long ago. The
lead author has a job that does not include VB so he works on it in his
spare time, and I have been retired for over 10 years and do a mass of
other things. Adding new features always wins over rewriting old code.
Parts of the code go back to the late 80s. I tidy stuff up at times and
use some f90 features, but the memory stuff is all over. I just do not
have the time. I suspect that similar issues are why other QC codes are
not fully updated.

> However, a practical problem with the fortran implementation is that
> it does not allow the programmer to query the system to see how much
> memory has been used or how much is available. These kinds of
> things were relatively straightforward with the old style f77
> approach, and they are basically impossible with modern fortran. So
> if you can't monitor and control memory usage, or adjust your
> algorithm according to memory usage, it is going to be limited in
> its applicability on modern supercomptuers, and that is the
> environment where fortran has (or would have, if the functionality
> existed) the biggest advantage over other languages.

This is indeed a problem and would apply to some extent even if the
program is running on a single core.

Brian.

> $.02 -Ron Shepard


--
Brian Salter-Duke Melbourne, Australia

[Ian Harvey]

On 2013-05-22 8:32 AM, glen herrmannsfeldt wrote:
> Seneika <notsp...@today.com> wrote:
>
> (snip)
>
>> Also, with Fortran-C interoperability, I can easily* use GSL (GNU
>> Scientific Library) and some other C or C++ libraries.
>
> (snip)
>
>> *I don't know whether this is possible with older Fortran or not.
>
> It usually is, but you have to do more work.

...and you quite often have to repeat that (low level, fiddly and error
prone, in my view) work whenever you move to a different
system/platform/compiler/change in compiler version/change in compiler
options - i.e. portability, which is pretty fundamental to a language
standard, goes out the window.

...

[Richard Maine]

Ian Harvey <ian_h...@bigpond.com> wrote:

> On 2013-05-22 8:32 AM, glen herrmannsfeldt wrote:
> > Seneika <notsp...@today.com> wrote:

> >> Also, with Fortran-C interoperability, I can easily* use GSL (GNU
> >> Scientific Library) and some other C or C++ libraries.

> >> *I don't know whether this is possible with older Fortran or not.
> >
> > It usually is, but you have to do more work.
>
> ...and you quite often have to repeat that (low level, fiddly and error
> prone, in my view) work whenever you move to a different
> system/platform/compiler/change in compiler version/change in compiler
> options - i.e. portability, which is pretty fundamental to a language
> standard, goes out the window.

That portability was really the reason for adding C interop to the
standard in f2003. It wasn't so much to make it possible to do new
things as to make it possible to do things portably. I certainly did
plenty of C interop code myself prior to f2003, and I don't claim to be
at all alone in that. But I had to tweak it for different compilers.

[Tom Micevski]

anal...@hotmail.com wrote:
> and if there is any
> language Fortrn needs interoperability woth it is R.

maybe you might find this useful? http://rfortran.org/

[JB]

On 2013-05-21, Brian Salter-Duke <brian.ja...@gmail.com> wrote:
> I have been hesitating about joining in here as I am stuck for several
> reasons in a f77/f90 time warp. The Fortran code I see is entirely in
> the quantum chemistry field where large programs have developed over
> many years by many people. What surprises me after keeping up with this
> group for quite a long while is how few of the F90+ features have
> actually been taken up in these Fortran programs. One of the most
> popular is Gaussian, which goes back to the early 1970s when it was free
> and is now sold by Gaussian Inc with few users ever seeing the actual
> code. I have only seen bits of the code recently but it still seems to
> be largely f77. I am an author of a valence bond code which interfaces
> to the popular GAMESS(US) program. Until recently that was strictly f77
> or at least on what ftnchek accepted as f77 as it relied heavily on
> ftnchek. Very recently it has moved to use more f90 features. A modern
> ftnchek is in progress (or out?). We have therefore kept our valence
> bond code to be f77, although all new routines I write now use IMPLICIT
> NONE and the other f90 features the OP mentioned. Several other quantum
> chemistry programs also still use f77, although some use C++ rather than
> Fortran and some use more modern Fortrans.
>
> If you work on a very large f77 program it seems difficult to move to
> modern Fortran and I suspect that this is the case in fields other than
> quantum chemistry. I would welcome Ron Shepard's views as he is in this
> field and he has moved on to modern Fortran. His insights on why so few
> of us have done so may be interesting.

My argument was about the usefulness of Fortran for writing new code,
be it for writing major applications or for education
purposes. Whether one should use newer language features, and if so to
which extent, when adding functionality to an existing program is of
course another interesting question.

My own background is in condensed matter physics, which is
methodologically relatively closely related to quantum chemistry,
though the method of choice tends to be DFT rather than HF which the
chemists seem fond of. In my own little bubble it seems that many
(most?) of the popular applications are F90+ (e.g. vasp, abinit, cp2k,
castep, wien2k, elk, octopus), although there are some holdouts
(e.g. cpmd is F77 + cray pointers).

--
JB

[JB]

On 2013-05-21, Ron Shepard <ron-s...@NOSPAM.comcast.net> wrote:
> However, a practical problem with the fortran implementation is that
> it does not allow the programmer to query the system to see how much
> memory has been used or how much is available. These kinds of
> things were relatively straightforward with the old style f77
> approach, and they are basically impossible with modern fortran.

There are a number of things one can do here, with varying degrees of
unportableness. E.g.:

- getrusage() (POSIX, though on Linux the maxrss field is filled only
with kernel 2.6.32+)
- mallinfo() (GLIBC)

In practice it seems what is done is that the input file contains
various parameters specifying the system size, and then users do
various trial-and-error runs until "success" is achieved.


--
JB

[Lynn McGuire]

No. It is time to move to C / C++. On older F77
programs that do not use many extensions, you can
use such translation programs as FOR_C:
http://www.cobalt-blue.com/fc/fcmain.htm

Unfortunately, our software uses the old zero
initialization of all local and global variables
so moving 800K lines of F77 code to C++ has been a
real bear.

Lynn

[aerosp...@gmail.com]

On Wednesday, May 22, 2013 10:49:55 AM UTC-5, Lynn McGuire wrote:
>No. It is time to move to C / C++. On older F77 programs that do not use many >extensions, you can use such translation programs as FOR_C: http://www.cobalt->blue.com/fc/fcmain.htm Unfortunately, our software uses the old zero >initialization of all local and global variables so moving 800K lines of F77 >code to C++ has been a real bear. Lynn

And you've been doing it for at least 5 years. That would be a ton of time to teach and hone new Fortran programmer's skills Fortran is indeed coming back. It is extremely interoperable. I'm doing several large projects (>100,000 lines) that tie Fortran and C++ together...

Ed

[JB]

On 2013-05-21, Ron Shepard <ron-s...@NOSPAM.comcast.net> wrote:

> However, a practical problem with the fortran implementation is that
> it does not allow the programmer to query the system to see how much
> memory has been used or how much is available. These kinds of
> things were relatively straightforward with the old style f77
> approach, and they are basically impossible with modern fortran.

There are a number of things one can do here, with varying degrees of
unportableness. E.g.:

- getrusage() (POSIX, though on Linux the maxrss field is filled only
with kernel 2.6.32+)

- mallinfo() (GLIBC, assuming your Fortran compiler implements
(de)allocate via malloc()/free()))
- Read /proc/self/status (Linux-specific)

[Lynn McGuire]

Good for you! Just not interested here
in continuing the Fortran battles.

Lynn

[glen herrmannsfeldt]

JB <f...@bar.invalid> wrote:
> On 2013-05-21, Ron Shepard <ron-s...@NOSPAM.comcast.net> wrote:
>> However, a practical problem with the fortran implementation is that
>> it does not allow the programmer to query the system to see how much
>> memory has been used or how much is available. These kinds of
>> things were relatively straightforward with the old style f77
>> approach, and they are basically impossible with modern fortran.

In the Fortran I days, only one program ran at a time, so the
available memory was pretty well defined. That was not so far off
in the Fortran 66 days, but by Fortran 77 virtual memory multi-user
systems were common, where the available memory is much less well
defined.

Often you want to know the available real memory, to avoid page
thrashing using up all the virtual memory. Even on a single user
system (most home computers) there is still enough going on in
the background that it is hard to know how much real memory is
available.

> There are a number of things one can do here, with varying degrees of
> unportableness. E.g.:

> - getrusage() (POSIX, though on Linux the maxrss field is filled only
> with kernel 2.6.32+)
> - mallinfo() (GLIBC, assuming your Fortran compiler implements
> (de)allocate via malloc()/free()))
> - Read /proc/self/status (Linux-specific)

> In practice it seems what is done is that the input file contains
> various parameters specifying the system size, and then users do
> various trial-and-error runs until "success" is achieved.

Yes, that is probably best. The user should know the amount of
physical memory on the system, subtract what other programs might
be using, round down a little, and then allow that much.

Adjust as appropriate. It isn't hard with top or task manager to
see when a program is page thrashing.

-- glen

[dpb]

On 5/16/2013 2:35 AM, Terence wrote:
>> Just registering my complete disagreement with almost everything in your
>> post. This is probably not much of a surprise.
>> Richard Maine
>
> Just as you (usually) imply that I am stuck in the mud, I think you are
> oppositly biased in the 'development must continue' direction (whatever this
> does for the future of Fortran).
>
> I'm rather familiar with university professors (e.g. physics, archeology,
> anthopology) who defend against reported winds of changes in their
> provinces, not only because their influence and book sales would drop.
>
> Fortran must remain as an easily learned, easily taught, and easily used
> programming language, if it is going to continue to be taught, learned and
> used.
...

I've been away so just happened on the thread, but...

I think that those are absolutely the wrong measuring sticks by which
Fortran (or any programming language, for that matter) will be taught in
university. It is far more likely to be taught for pedagogical reasons
that are related to advancing concepts of data abstraction, algorithm
development or such esoterica or even simply on the basis of "popular
color of the day" than on the above.

The one system I know of that is widely used for the above reasons is as
another mentioned, Matlab, but I don't see it being taught as a
programming language per se but as a solutions system to either support
a particular course or curriculum w/ easy-to-do apps or as the way to
get the graphics or similar features builtin to the system but not
really so much as a "here's the fundamentals of programming principles
for a general programming language".

$0.02, imo, ymmv, etc., etc., etc., of course...

--

[glen herrmannsfeldt]

dpb <no...@non.net> wrote:

(snip on choice of programming language to teach)

> I think that those are absolutely the wrong measuring sticks by which
> Fortran (or any programming language, for that matter) will be taught in
> university. It is far more likely to be taught for pedagogical reasons
> that are related to advancing concepts of data abstraction, algorithm
> development or such esoterica or even simply on the basis of "popular
> color of the day" than on the above.

> The one system I know of that is widely used for the above reasons is as
> another mentioned, Matlab, but I don't see it being taught as a
> programming language per se but as a solutions system to either support
> a particular course or curriculum w/ easy-to-do apps or as the way to
> get the graphics or similar features builtin to the system but not
> really so much as a "here's the fundamentals of programming principles
> for a general programming language".

I believe that there are ones about equal in teaching the language
and the solutions/system, but I agree there shouldn't be a course that
teaches Matlab without any applications.

My son last year had the choice between a course using Matlab and
one using C. That is, the degree program required one or the other.
I believe both included some application to the solutions of some
differential equations, but the primary reason for the course was
to learn the language, in the context of the application.

There are, or course, plenty of math department courses on
differential equations and their solutions, without programming.

-- glen

[dpb]

I'm going mostly on basis of on-campus college interviewing for previous
employer I did and that is getting somewhat dated now. Where we mostly
went Matlab was used pretty heavily but mostly as outlined above--it
wasn't taught except as a means to the end--nobody was teaching much
about programming itself with it. I looked at that very hard because we
needed some for support of large codes as well as those who were adept
in solving ad hoc problems for which Matlab or such was a help.

I just did a search of my undergrad degree uni's catalog online and
found zero references to Fortran and only one to Matlab at all. There
were intro courses for C/C++/C#/Visual Basic/Java but not of the Intro
to Programming courses mentioned any specific language at all (so one
presumes they probably focus on C altho I don't know that it's just what
I'd guess). The Matlab reference was in the MATH department as having
it and Mathematica, etc., available as tools not as a course or object
of study.

Engineering syllabi in catalog were also completely mum on any
particular programming language other than a couple of courses that did
have C in the title. I saw no parallel courses that offered one or the
other choice of language for the same/similar course as your son was
offered.

I initially thought of trying to put together a "real world" intro
course that would include some Fortran/C/Matlab as a prep for the local
juco besides the Intro courses they teach but just haven't had the time
to pursue it now that I've been back on the farm and find that almost 12
years have passed and I don't have a clue as to how that could be...so,
it would be kinda' fun but it ain't agonna' happen.

--

[Gib Bogle]

I suspect most of us have been down that path. C interop was a great
addition.

[glen herrmannsfeldt]

dpb <no...@non.net> wrote:

(snip, I wrote)

>> My son last year had the choice between a course using Matlab and
>> one using C. That is, the degree program required one or the other.
>> I believe both included some application to the solutions of some
>> differential equations, but the primary reason for the course was
>> to learn the language, in the context of the application.

(snip)

See: http://www.scu.edu/engineering/cse/ugrad/bulletin.cfm

Specifically COEN44 and COEN45.

> I'm going mostly on basis of on-campus college interviewing for previous
> employer I did and that is getting somewhat dated now. Where we mostly
> went Matlab was used pretty heavily but mostly as outlined above--it
> wasn't taught except as a means to the end--nobody was teaching much
> about programming itself with it. I looked at that very hard because we
> needed some for support of large codes as well as those who were adept
> in solving ad hoc problems for which Matlab or such was a help.

For one, more schools now separate Computer Science and Computer
Engineering.

> I just did a search of my undergrad degree uni's catalog online and
> found zero references to Fortran and only one to Matlab at all. There
> were intro courses for C/C++/C#/Visual Basic/Java but not of the Intro
> to Programming courses mentioned any specific language at all (so one
> presumes they probably focus on C altho I don't know that it's just what
> I'd guess). The Matlab reference was in the MATH department as having
> it and Mathematica, etc., available as tools not as a course or object
> of study.

> Engineering syllabi in catalog were also completely mum on any
> particular programming language other than a couple of courses that did
> have C in the title. I saw no parallel courses that offered one or the
> other choice of language for the same/similar course as your son was
> offered.

Yes, they really need to be in the Engineering dept. They should
teach how to use the language on real problems, and relate to the
courses that teach those problems.

-- glen

[dpb]

On 5/22/2013 7:34 PM, glen herrmannsfeldt wrote:
> dpb<no...@non.net> wrote:
>
> (snip, I wrote)
>
>>> My son last year had the choice between a course using Matlab and
>>> one using C. That is, the degree program required one or the other.
>>> I believe both included some application to the solutions of some
>>> differential equations, but the primary reason for the course was
>>> to learn the language, in the context of the application.
>
> (snip)
>
> See: http://www.scu.edu/engineering/cse/ugrad/bulletin.cfm
>
> Specifically COEN44 and COEN45.
>
>> I'm going mostly on basis of on-campus college interviewing for previous
>> employer I did and that is getting somewhat dated now. Where we mostly
>> went Matlab was used pretty heavily but mostly as outlined above--it
>> wasn't taught except as a means to the end--nobody was teaching much
>> about programming itself with it. I looked at that very hard because we
>> needed some for support of large codes as well as those who were adept
>> in solving ad hoc problems for which Matlab or such was a help.
>
> For one, more schools now separate Computer Science and Computer
> Engineering.
>

...

We (or at least I) never interviewed either--we were strictly other
engineering degrees or physics guys w/ a practical mindset and some
applied math. These days that would probably change and they'd at least
get a look-see opportunity.

We were more concerned they understood the problems they were working on
and figured we could teach the computer sci end much easier than the
basic physics and engineering disciplines.

--

[Ron Shepard]

In article <kniun4$ej5$1...@speranza.aioe.org>,

glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:

> JB <f...@bar.invalid> wrote:
> > On 2013-05-21, Ron Shepard <ron-s...@NOSPAM.comcast.net> wrote:
> >> However, a practical problem with the fortran implementation is that
> >> it does not allow the programmer to query the system to see how much
> >> memory has been used or how much is available. These kinds of
> >> things were relatively straightforward with the old style f77
> >> approach, and they are basically impossible with modern fortran.
>
> In the Fortran I days, only one program ran at a time, so the
> available memory was pretty well defined. That was not so far off
> in the Fortran 66 days, but by Fortran 77 virtual memory multi-user
> systems were common, where the available memory is much less well
> defined.
>
> Often you want to know the available real memory, to avoid page
> thrashing using up all the virtual memory. Even on a single user
> system (most home computers) there is still enough going on in
> the background that it is hard to know how much real memory is
> available.

Modern supercomputers aren't like this at all. There is some fixed
amount of physical memory per node, typically .5GB to 2GB. Or
sometimes some small number of cores (4 to 16) share a pool of
physical memory. There is only one user process running, and there
are some limited number of threads (e.g. 2 or 4). There is no local
disk space, so there is no virtual/swapped memory.

The user is trying to run efficiently on 10^5 or 10^6 nodes. If
there is a memory allocation on any one of those nodes, then the job
will fail, so the user needs enough information to absolutely
prevent that from happening.

The trend on these computers is toward larger number of cores and
nodes and toward smaller memory per core, not larger. So this
memory issue will become even more important in the future than now.

> Yes, that is probably best. The user should know the amount of
> physical memory on the system, subtract what other programs might
> be using, round down a little, and then allow that much.
>
> Adjust as appropriate. It isn't hard with top or task manager to
> see when a program is page thrashing.

You make this sound much too random. The programmer needs to be
able to absolutely guarantee that memory will not be overallocated.
None of the "round down a little" business. It needs to be
absolutely correct.

This can be achieved with the old f77 style of memory allocation
through aliasing with the dummy argument list. It was always known
what total memory was available and what is the last array offset,
and a subtraction gives what is left at any time.

The problem is that the high level modern fortran features of
allocatable and automatic arrays prevent this information from being
available to the programmer.

Hence, many program systems have stuck with f77 style conventions
rather than making use of the modern fortran conventions, despite
their advantages in other respects.

$.02 -Ron Shepard

[glen herrmannsfeldt]

Ron Shepard <ron-s...@nospam.comcast.net> wrote:
> In article <kniun4$ej5$1...@speranza.aioe.org>,

(snip, I wrote)

>> Often you want to know the available real memory, to avoid page
>> thrashing using up all the virtual memory. Even on a single user
>> system (most home computers) there is still enough going on in
>> the background that it is hard to know how much real memory is
>> available.

> Modern supercomputers aren't like this at all. There is some fixed
> amount of physical memory per node, typically .5GB to 2GB. Or
> sometimes some small number of cores (4 to 16) share a pool of
> physical memory. There is only one user process running, and there
> are some limited number of threads (e.g. 2 or 4). There is no local
> disk space, so there is no virtual/swapped memory.

So, no Fortran related I/O, either. I/O buffers are one of the
less obvious users of memory.

The C solution is to write your own malloc(), which can keep track
of memory however you want it to. It would be tricky, but for
Fortran compilers that use the underlying C library to do allocation,
it might still work.

> The user is trying to run efficiently on 10^5 or 10^6 nodes. If
> there is a memory allocation on any one of those nodes, then the job
> will fail, so the user needs enough information to absolutely
> prevent that from happening.

Seems like you have to be careful not to do anything that will
need a temporary array. PL/I compilers I used to use gave a warning
when they used a temporary array, in case you didn't guess. That
would seem useful in Fortran compilers, too.

> The trend on these computers is toward larger number of cores and
> nodes and toward smaller memory per core, not larger. So this
> memory issue will become even more important in the future than now.

Writing your own routines to return POINTER arrays of a specified
size isn't so hard to do. Easier than the Fortran 77 day tricks.

>> Yes, that is probably best. The user should know the amount of
>> physical memory on the system, subtract what other programs might
>> be using, round down a little, and then allow that much.

>> Adjust as appropriate. It isn't hard with top or task manager to
>> see when a program is page thrashing.

> You make this sound much too random. The programmer needs to be
> able to absolutely guarantee that memory will not be overallocated.
> None of the "round down a little" business. It needs to be
> absolutely correct.

> This can be achieved with the old f77 style of memory allocation
> through aliasing with the dummy argument list. It was always known
> what total memory was available and what is the last array offset,
> and a subtraction gives what is left at any time.

Yes, but if you can do it that way, you can also write the routines
to suballocate memory and return pointers to it. You can even
rewrite the Fortran library routines that do memory allocation.
For gfortran and glibc they are all open source and available.

> The problem is that the high level modern fortran features of
> allocatable and automatic arrays prevent this information from being
> available to the programmer.

For most systems, it isn't available to give.

I have written a few times that I don't think allocate on assignment
without asking for it was a good idea. I am not at all against it in
the case where it is wanted.

> Hence, many program systems have stuck with f77 style conventions
> rather than making use of the modern fortran conventions, despite
> their advantages in other respects.

If the sizes are fixed, then static allocation is fine.

-- glen

[\"Vladimír Fuka <"name.surnameat]

Why you are going to this forum then? Just to troll?

[Beliavsky]

On Wednesday, May 22, 2013 4:49:28 PM UTC-4, dpb wrote:
> On 5/16/2013 2:35 AM, Terence wrote:
> > Fortran must remain as an easily learned, easily taught, and easily used
>
> > programming language, if it is going to continue to be taught, learned and
>
> > used.
>
> ...
>
>
>
> I've been away so just happened on the thread, but...
>
>
>
> I think that those are absolutely the wrong measuring sticks by which
>
> Fortran (or any programming language, for that matter) will be taught in
>
> university. It is far more likely to be taught for pedagogical reasons
>
> that are related to advancing concepts of data abstraction, algorithm
>
> development or such esoterica or even simply on the basis of "popular
>
> color of the day" than on the above.

"Easily learned, easily taught, and easily used" sounds like Python to me, and I think it would be a good language for an introductory programming course. A few universities use it for this, but Java and C++ are more common.

[Lynn McGuire]

On 5/23/2013 7:15 AM, \"Vladimír Fuka <\"name.surname at >> wrote:
> Why you are going to this forum then? Just to troll?

Yup. That and horsing 800K lines of F77 code
around. Wrote about 1,000 new lines of F77
code in the last couple of weeks. Will
probably write another couple thousand lines
before our next major release.

I've got an intern working on getting rid of
zero initialization out of our code. He is
just about finished, only another year or so
of bugs to fix. He has been working on this
project for two years now. Then we will
attempt to jump to C++ again.

Lynn

[JB]

On 2013-05-23, Beliavsky <beli...@aol.com> wrote:
> "Easily learned, easily taught, and easily used" sounds like Python
> to me, and I think it would be a good language for an introductory
> programming course. A few universities use it for this, but Java and
> C++ are more common.

My uni being one, FWIW. They switched from Java to Python IIRC a few
years ago. At least in our department there was much rejoicing, as
python has got somewhat big in the scientific computing community
whereas Java is nowhere to be seen.


--
JB

[Lynn McGuire]

One thing that really hurt Fortran is when Microsoft
dropped their Fortran compiler from their sales mix
of products. To me, that was the kiss of death in
the Windows market. And that has been, 15 years now?

Lynn

[Nasser M. Abbasi]

On 5/25/2013 11:41 AM, Lynn McGuire wrote:

>
> One thing that really hurt Fortran is when Microsoft
> dropped their Fortran compiler from their sales mix
> of products. To me, that was the kiss of death in
> the Windows market. And that has been, 15 years now?

Maybe. But any way, the future of software have now been
found. It is

HTML5 + CSS3+ Javascript + php + the browsers

So, it is all set. All future apps will be done using
the above wonderful technologies. Everything will run
inside the browser and the iphone, the ipad, andriod and
other such mobile devices from now on.

So forget about Fortran and all similar old fashioned compiled
languages like it. Too late to do anything. The party is
over. Nothing can be done to change the future we are
facing.

I just ordered 10 books from amazon on php, Javascript and
HTML5 and sold all my other computer programming languages
books I have since there is no use for them any more.

One nice thing about this new software technology, is that it is
all based on typeless or very weak typed languages. Which is so
cool. No more compiler errors or warnings to worry about. One just
writes code and hits the refresh button in the browser.

One does not even need a makefile to compile things!

--Nasser

[dpb]

On 5/25/2013 11:41 AM, Lynn McGuire wrote:

...

> One thing that really hurt Fortran is when Microsoft
> dropped their Fortran compiler from their sales mix
> of products. To me, that was the kiss of death in
> the Windows market. And that has been, 15 years now?

Closer to 20 but the slack was taken up by DEC w/ DVF which was much
better compiler than MS Powerstation. I know Terence will disagree but
the 16-bit MS compiler was already long in the tooth before Powerstation.

There's nothing imo that indicates Fortran will disappear any more than
there's anything that indicates it will become the next fad but it will
continue to occupy the specific application space for which it is suited
(Nasser and other youngsters who don't know what _real_
"compute-intensive" applications are notwithstanding :) ).

--

[Gary Scott]

On 5/25/2013 12:23 PM, Nasser M. Abbasi wrote:
> On 5/25/2013 11:41 AM, Lynn McGuire wrote:
>
>>
>> One thing that really hurt Fortran is when Microsoft
>> dropped their Fortran compiler from their sales mix
>> of products. To me, that was the kiss of death in
>> the Windows market. And that has been, 15 years now?
>
> Maybe. But any way, the future of software have now been
> found. It is
>
> HTML5 + CSS3+ Javascript + php + the browsers
>
> So, it is all set. All future apps will be done using
> the above wonderful technologies.

Yuk!

> --Nasser
>
>
>

[gmail-unlp]

I wonder why you "lose" your time at clf at all...

Fernando.

[anal...@hotmail.com]

On a lark, I looked up

http://cis.hfcc.edu/faq/cobol

and apparently COBOL is far more healthy than Fortran (interesting
that its high priests have been putting the same "elevator on an
outhouse" kind of enhancements into it - paralleling the excruciating
post Fortran-77 tragedy).

Actually the survivability of Fortran has many aspects to it. We can
ask questions like

(1) Can Fortran continue to exist?

Yes - individuals can write compilers/interpreters for anything
fortran-like they define as Fortran.

(2) Will there be a committee and language revisions going forward?

Eventually, No.

(3) Will it have a use-base? And just whats is the core application
area?

The notion that Fortran is either best-suited for numerical
computations or that it is its best feature is so patently false that
it is amazing how many people still repeat it.

Fortran is non-existent in commercial (it is possible that it does
exist in specialized engineering and/or non-profit sectors)
numerically intensive applications - which involve significant money-
exchange between buyer and seller anw there are contractual
obligations as to how the software is supposed to be installed and
used and there are performance expectations.

Fortran no longer belongs in the commercial world of grown-ups. There
is a massive explosion of "big data" computations (largely hype - but
hey - there is money to ne made doing it) underway and Fortran's share
of is vanishingly small, if not zero.

There is something about the look-and-feel of all-caps Fortran 77 and
the stodginess of "modern" fortrans - that belongs in the world of
business suits as much as a jar of leaches in modern medicine.

Fortran as an aficionados' hobby is perfectly rescuable and actually
EVERYTHING ought to be doable with it - with two-way hooks to/from
whatever is the rage at any given time.

And it should exist because although all procedural languages are more
or less isomorphic - fortran expresses the basic ideas of programming
with an economy and elegance that can only be equaled but not
surpassed.

[Richard Maine]

anal...@hotmail.com <anal...@hotmail.com> wrote:
[trolling that I don't feel worth responding to]

Guess it's time for me to start a new killfile. I moved to a different
machine and didn't bother to bring over the old killfile, which mostly
had entries for people that had long since gotten tired of trolling and
gone away anyway. I think there was only one stil regularly active. My
new killfile now has its first entry. Mostly that serves to help me
resist the temptation to pointless responses.

--
Richard Maine
email: last name at domain . net
domain: summer-triangle

[dpb]

On 5/25/2013 3:40 PM, anal...@hotmail.com wrote:
...

> Fortran is non-existent in commercial (it is possible that it does
> exist in specialized engineering and/or non-profit sectors)
> numerically intensive applications - which involve significant money-

...

There's no money in petroleum seismology????? I'm sure _that's_ news...

--

[Lynn McGuire]

Fortran will never disappear. Just continue to
fade slowly into the distance as newbies do not
put it into their quiver of applicable technologies
for solving problems. To be honest, I am worried
about C++ fading into the distance also but the
fact that operating systems are written in C may
keep C++ usable. However, C++ is moving from the
same terseness into verbosity that Fortran has
done also. Just 20 years behind it.

Lynn

[anal...@hotmail.com]

On May 25, 5:08 pm, dpb <n...@non.net> wrote:

What part of "Specialized engineering .... sectors" is hard to
understand?

The tetchy old ng. fogies are like "Baghdad Bob" during the war Baby
Bush unleashed on Iraq - there was only a finite time window during
the advance of the US army from the border towards Baghdad that he
could meet the press every day and claim imaginary victories.

Prime areas like data mining, financial computations, supply chain
management, Airline crew scheduling, marketing - you name it are gone
(AFAIK)- and we have absurd responses like - yeah, but we still do
seismic modeling or weather forecasting or hydrological modeling with
Fortran.

The boom is being lowered as we speak and all that the regulars can do
is to pull the sheet over their head and hope the world goes away.

[Clive Page]

On 25/05/2013 17:41, Lynn McGuire wrote:

> One thing that really hurt Fortran is when Microsoft
> dropped their Fortran compiler from their sales mix
> of products. To me, that was the kiss of death in
> the Windows market. And that has been, 15 years now?

I have to disagree with that. It was an awful product, with lots of
bugs. It could be that it hurt Fortran to have a well-known company
bringing out a compiler of such poor quality. In my opinion it was good
that they eventually decided it was too difficult to fix and simply
dropped it, so that Fortran users were forced to turn to some other
product. Almost any other choice would have provided an improvement.


--
Clive Page

[Gib Bogle]

On 26/05/2013 5:23 a.m., Nasser M. Abbasi wrote:

> Maybe. But any way, the future of software have now been
> found. It is
>
> HTML5 + CSS3+ Javascript + php + the browsers
>
> So, it is all set. All future apps will be done using
> the above wonderful technologies. Everything will run
> inside the browser and the iphone, the ipad, andriod and
> other such mobile devices from now on.
>
> So forget about Fortran and all similar old fashioned compiled
> languages like it. Too late to do anything. The party is
> over. Nothing can be done to change the future we are
> facing.
>
> I just ordered 10 books from amazon on php, Javascript and
> HTML5 and sold all my other computer programming languages
> books I have since there is no use for them any more.
>
> One nice thing about this new software technology, is that it is
> all based on typeless or very weak typed languages. Which is so
> cool. No more compiler errors or warnings to worry about. One just
> writes code and hits the refresh button in the browser.
>
> One does not even need a makefile to compile things!
>
> --Nasser

;)

[Gib Bogle]

On 26/05/2013 9:21 a.m., Lynn McGuire wrote:

>
> Fortran will never disappear. Just continue to
> fade slowly into the distance as newbies do not
> put it into their quiver of applicable technologies
> for solving problems. To be honest, I am worried
> about C++ fading into the distance also but the
> fact that operating systems are written in C may
> keep C++ usable. However, C++ is moving from the
> same terseness into verbosity that Fortran has
> done also. Just 20 years behind it.
>
> Lynn
>

C++ was always verbose, IMO.

[dpb]

On 5/25/2013 4:28 PM, anal...@hotmail.com wrote:
> On May 25, 5:08 pm, dpb<n...@non.net> wrote:
>> On 5/25/2013 3:40 PM, analys...@hotmail.com wrote:
>> ...
>>
>>> Fortran is non-existent in commercial (it is possible that it does
>>> exist in specialized engineering and/or non-profit sectors)
>>> numerically intensive applications - which involve significant money-
>>
>> ...
>>
>> There's no money in petroleum seismology????? I'm sure _that's_ news...
>>

...

> What part of "Specialized engineering .... sectors" is hard to
> understand?

...

Nothing...other than there's certainly much financial incentive in many
areas in which Fortran is used which contradicts your contention.

Meanwhile, as Richard... <plonk> seems appropriate as there seems no
value here.

--

[dpb]

On 5/25/2013 4:21 PM, Lynn McGuire wrote:
> On 5/25/2013 1:03 PM, dpb wrote:
>> On 5/25/2013 11:41 AM, Lynn McGuire wrote:
>> ...
>>

...

>> There's nothing imo that indicates Fortran will disappear any more than
>> there's anything that indicates it will become the next fad but it will
>> continue to occupy the specific application space for which it is suited
>> (Nasser and other youngsters who don't know what _real_
>> "compute-intensive" applications are notwithstanding :) ).
>>

...

> Fortran will never disappear. Just continue to
> fade slowly into the distance as newbies do not
> put it into their quiver of applicable technologies
> for solving problems. To be honest, I am worried
> about C++ fading into the distance also but the
> fact that operating systems are written in C may
> keep C++ usable. However, C++ is moving from the
> same terseness into verbosity that Fortran has
> done also. Just 20 years behind it.

I expect it to remain robust in the areas in which it already is heavily
used and folks working in those areas will learn it as they need it. I
was at a royalty owners' annual meeting just a couple of weeks ago where
one of the guest speakers was a UT-Austin prof (Applied Math and Geology
type) whose area of specialization is seismology analysis development.
Just happens this fella' grew up near here and was a HS student of the
person who is current President of the association (which is how the
invitation to him specifically came about, obviously) and I know the
former teacher well. While chatting I asked about the tools used and
while it's not exclusive, Fortran is prominent and he has both
under-grad and grad students who are from learning to expert in
proficiency altho it's not a curriculum course per se.

I know there are other areas in which it's widely used as well.
Granted, it's never going to be other than that, but does that really
matter? I don't see that it does, really.

C++ was bloat from the git-go imo...and as far as syntax
incomprehensible it seemed to me. I never gave it a chance though since
there was nothing that forced the issue couldn't see the point in
indulging in self-torture. :)

--

[Richard Maine]

I strongly agree with Clive here. I had nothing but bad experiences with
the later MS compilers. There were several alternatives avaliable, all
of which I'd say were better than MicroSoft's. I have certainly seen
worse compilers than the MS ones, but all the examples I can recall
off-hand were on other platforms.

I had multiple cases of people fighting to get codes to run correctly
(or at all) with the MS compilers where the easiest fix was to just buy
Lahey or DVF. I'm sure some of those people had wasted far more of their
(and my) time than a compiler license cost.

[Clive Page]

On 25/05/2013 18:23, Nasser M. Abbasi wrote:
> One nice thing about this new software technology, is that it is
> all based on typeless or very weak typed languages. Which is so
> cool. No more compiler errors or warnings to worry about.

I've found that too - no more error messages (even when I make mistakes).

Agile programming here I come. :-)


--
Clive Page

[anal...@hotmail.com]

On May 25, 5:28 pm, "analys...@hotmail.com" <analys...@hotmail.com>
wrote:

It is a sad coincidence that "Rocket Science" was done in fortran when
it was only used for rockets and missiles and when it proliferated
massively into the economy as a whole, it forgot to take fortran with
it.

[Wolfgang Kilian]

(Anyone observed the proliferation of Javascript add-ons that enforce
scoping rules and emulate a strong type system ...?)

If the compiler detects your mistake, it's simply not funny. And a
waste of resources anyway. Companies have learned to enjoy shipping
their product to their users before debugging. Users are much cheaper
than QA professionals -- they even pay for their experience.

-- Wolfgang

--
E-mail: firstnameini...@domain.de
Domain: yahoo

[John Harper]

Lynn McGuire wrote:

> C++ is moving from the same terseness
> into verbosity that Fortran has
> done also. Just 20 years behind it.

Eh? Modern Fortran is less verbose than f77 for various useful things. If A
and B are arrays of the same shape A = B**2 is less verbose than the
equivalent f77 DO loop(s), and REAL,PARAMETER:: PI = 3.14159265 is one line
shorter than the f77 equivalent.

--
John Harper

[Gary Scott]

lol, yes some of these comments are befuddling...

[Richard Maine]

One that I like a lot is the f90

call sub(x,y,z)

as opposed to the typical f77 equivalent something like

call sub(x,maxx,nx,mx,y,maxy,ny,my,z,maxz,nz,mz)

where x is an array with physical dimensions (maxx,something), of which
an nx by mx section is used for the current run. In the f90 version, it
will be allocated to the correct size instead of having separate
physical and used sizes; that size will be passed via assumed shape.

I find the f90 version to be not only shorter, but far more clear.
Admitedly, I do get pretty verbose on other things. For a start, I tend
to use longer variable names in my f90 code. I don't go for the
ludicrously long things you see in some C libraries where by the time
you have typed one variable name, a line is pretty full, but I do go
longer than 6 characters.

[Beliavsky]

Terence thinks that Fortran 77 meets his needs and largely sticks to it. I wonder if there is another contingent of Fortran programmers who will stop at Fortran 95 (in my case with a few extensions such as allocatable arrays as components in derived types and as procedure arguments). So far I have not felt the need to use the object-oriented features of Fortran 2003, but that might change if I studied them more.

Is the Fortran standards committee working on new standards beyond Fortran 2008?
I think a future standard should be deferred until Fortran 2008 compilers exist, ideally including a free one such as gfortran.

[Gary Scott]

dont stop until we have some "system programming" additions like a
PROPER bit/bit string data type...

[dpb]

On 5/28/2013 7:08 AM, Beliavsky wrote:

> Terence thinks that Fortran 77 meets his needs and largely sticks to
> it. I wonder if there is another contingent of Fortran programmers who
> will stop at Fortran 95 (in my case with a few extensions such as
> allocatable arrays as components in derived types and as procedure
> arguments). So far I have not felt the need to use the object-oriented
> features of Fortran 2003, but that might change if I studied them more.

...

I think it's like so many things--people tend to stick w/ what they
learned initially after some point that is generally relatively early in
working careers unless there's a very distinct incentive to not do so.

In my case, I jumped into F95 owing to the porting of a moderate-sized
code to a new system wherein the existing compiler was no longer
supported and the customer required commercial products be used so a new
compiler was imperative.

If it hadn't required the new compiler it's likely would have stayed
much like Terence altho the particular compiler used had even more
F90-like extensions implemented than his compiler of choice so wasn't
all that big of step up.

After that was done and supported for roughly 10 yr I ended up returning
to family farm and essentially retiring from much (as in any)
significant Fortran development as I transitioned from consulting to
farming to now (trying to) retirement (Category IV Exceptional Drought
for third-year running helps in that regard looking for the silver lining).

Consequently, I've pretty much stagnated at that point and what
consulting I do now is almost all of the size that Matlab is the tool I
choose first because of the integration it possesses 'out of the box'.

--

[Tobias Burnus]

My impression with newer features was often: That's nice, but I don't
need it - only to end up using it shortly later. There are many nice new
features in Fortran 2003 and 2008 which one tends to use without
realizing. For instance (F2003) strings in namelist which do not have
constant bounds, (F2008) passing internal procedures as actual argument
- or using intrinsics in initialization/constant expressions which
weren't permitted in previous versions. There are many such smaller
features - and I wouldn't be surprised if many so-called Fortran 90 or
95 programs failed to compile with -std=f95 / -stand f95 because
(accidentally) use newer features, which their compiler(s) simply accepts.

* * *

Regarding the new Fortran standard: It will contain two Technical
Specifications and otherwise:

"WG5 resolves that the next revision shall consist of a consolidation of
the agreed editorial improvements, corrigenda and the two Technical
Specifications into the main standard, plus the removal of simple
deficiencies in, and discrepancies between, existing facilities. The
intent is to resolve issues that have been created by successive
extensions to Fortran, while minimising impact on the standard document,
implementors and other users. The criterion for deciding whether a
change is simple is that it requires no more than a small amount of
editorial effort and no more than a small amount of implementation
effort. Furthermore, WG5 resolves that no new significant language
extensions, beyond those mentioned in these resolutions, will be
considered until the process described in this resolution is complete."
(N1927)

One new feature will probably be a means to influence the host
association, e.g. "IMPORT, NONE" to disable the host association; or
"IMPORT :: VAR" to only host-associated a certain variable.


The two technical specifications are:

* ISO/IEC TS 29113:2012 on Further Interoperability of Fortran with C
* And the currently being developed TS 18508 Additional Parallel
Features in Fortran, which will extend the coarray support.



The first one mainly addresses wishes from the MPI Forum (Message
Passing Interface), e.g. "TYPE(*), dimension(*) :: buffer" as equivalent
to C's "void*" or supporting Fortran-style arrays (assumed-shape,
deferred-shape, assumed-rank) from C. The latter permits passing arrays
with strides to the MPI library.


The released GCC/gfortran 4.8 already supports most of the TS29113:2012
features. And when gfortran's array descriptor is finally updated, the
new descriptor will match the one of TS29113. (The old descriptor has
several problems; e.g. in some rarely encountered case, the current
descriptor cannot represent valid Fortran 90 code.)

The TS29113 implementation was motivated in order to support the new MPI
features, which could be used with other compilers via vendor
extensions. Well, it turned out that TS29113 wasn't enough (without
using assumed-rank arrays) - hence, GCC 4.9 also add a vendor-specific
directive:
!GCC$ attributes no_arg_check :: buf
which internally uses TYPE(*) but doesn't distinguish between scalar and
dimension.

[Side remark: The next Fortran standard probably will permit to use
"type(*),dimension(*)" also with scalars - but not with other types than
type(*).]

* * *

In general, I concur that it would be useful to have a full Fortran 2008
compiler instead of having compilers which supports a lot of the new
features but not the full standard. However, I also like to be able to
use a new feature without having to wait until everything is ready and
all of a new standard is ready and enabled.

Regarding gfortran in particular: Do not forget that the development is
nearly entirely done by volunteers. Unfortunately, it seems to become
increasingly more difficult to find new contributors, while existing
contributors have increasingly less time. - Thus, if you are tempted to
contribute to the compiler or know someone who might be ...


Tobias

PS: Upcoming gfortran 4.9 features: Fortran 2003's finalization (partial
support should become available in the next weeks). The new array
descriptor might also become available in 4.9, but that's not yet
completely clear. And deferred-character length strings (as components
of derived types) could also become available, depending on the new
array descriptor. - For all those items, a lot of the work has been
done, but more is required before it can be used.
(And below the radar of release notes: Many smaller changes for newer
standards or bug fixes have and will be implemented.)

PPS: Another major GCC 4.9 feature will be the support of OpenMP 4 for
C, C++ and Fortran.

[Stansfield Temelmeir]

Don't laugh. Now Fortran is becoming more Ada-like and offering nice
combination of power and type safety. Fortran compilers are available on
every major system, Fortran can displace C for many uses. C is full of smoke
and mirrors and stumbling blocks and Fortran is quite nicer and not likely
to do what you said and not what you meant as C. I'll be quite happy to see
extensions to help to this goal such as native void pointer and something
better than vendor extension bit operations or the awful US mil standard
forced little endian bit functions (wretched on big endian platforms!)

Stan

[Richard Maine]

Stansfield Temelmeir <s...@opiker.de> wrote:

> I'll be quite happy to see
> extensions to help to this goal such as native void pointer

Fortran's type(cptr) is pretty close to a void pointer. Although its
advertised purpose, as reflected in the name, is C interop, you can use
it without really having anything to do with C. You can even use it with
types that are not interoperable. There are some restrictions, it is
true. Polymorphic variables are right out, as are some other things. But
then the things that are disallowed are mostly things where a void
pointer wouldn't plausibly work with simple implementations (namely
implementations where the void pointer has no information other than an
address). That's generally why they are disallowed.

See also unlimitted polymorphics. I've never really had a chance to use
them, so I can't offer a lot of advice on them, but they ought to cover
some of that kind of ground.

[Phillip Helbig---undress to reply]

In article <ce3358a6-4b13-4213...@googlegroups.com>,

Beliavsky <beli...@aol.com> writes:

> Terence thinks that Fortran 77 meets his needs and largely sticks to it. I
> wonder if there is another contingent of Fortran programmers who will stop
> at Fortran 95 (in my case with a few extensions such as allocatable arrays
> as components in derived types and as procedure arguments). So far I have
> not felt the need to use the object-oriented features of Fortran 2003, but
> that might change if I studied them more.

Same here. Until now, I have found one post-2003 feature which I need,
though there is a workaround in F95 (exactly the same functionality but
more lines of code). It might be that I never need more. In my case,
an issue is also the fact that, sadly (especially since VMS Fortran used
to be the gold standard), there will probably never be F2003 on VMS,
much less a later revision.

> I think a future standard should be deferred until Fortran 2008 compilers
> exist, ideally including a free one such as gfortran.

The original idea, after the long gap between 77 and 90, was to have a
major revision every 10 years and a minor one every 10 years, with a
5-year offset. This worked until Fortran95. We then had 2003 instead
of 2000, but 2008 was again 5 years later. However, times have changed.
F90 standardized many extensions; that wasn't the main thrust of 2003.
The community is smaller and probably there is less demand for new
features. Under the circumstances, working on a new version before 2008
is (widely) available does seem rather bizarre.

[Beliavsky]

On Tuesday, May 28, 2013 3:57:02 PM UTC-4, Phillip Helbig---undress to reply wrote:

> The original idea, after the long gap between 77 and 90, was to have a
>
> major revision every 10 years and a minor one every 10 years, with a
>
> 5-year offset. This worked until Fortran95. We then had 2003 instead
>
> of 2000, but 2008 was again 5 years later. However, times have changed.
>
> F90 standardized many extensions; that wasn't the main thrust of 2003.
>
> The community is smaller and probably there is less demand for new
>
> features. Under the circumstances, working on a new version before 2008
>
> is (widely) available does seem rather bizarre.

According to Tobias Burnus in an earlier message, the standards committee understands this, and the next Fortran standard is largely about corrections and clarifications of previous standards.

[Tobias Burnus]

Richard Maine wrote:
> Stansfield Temelmeir <s...@opiker.de> wrote:
>
>> I'll be quite happy to see
>> extensions to help to this goal such as native void pointer
>
> Fortran's type(cptr) is pretty close to a void pointer. Although its
> advertised purpose, as reflected in the name, is C interop, you can use
> it without really having anything to do with C. You can even use it with
> types that are not interoperable. There are some restrictions, it is
> true.

I think type(c_ptr) has two (minor) disadvantages: It requires to
explicitly convert the argument to a C pointer - i.e. one has to
explicitly call "c_loc" at some point. And the argument to C_Loc has to
have the TARGET attribute, which is not always required for "void*" usage.

As mentioned before, the Technical Specification on Further
Interoperability of Fortran with C (ISO/IEC TS 29113:2012) provides as
alternative assumed types ("type(*)"). They are only permitted as dummy
arguments, are unlimited polymorphic but do not carry type information
(contray to class(*)). Additionally, their use is rather restricted. One
permitted usage is as argument to C_LOC, which closes the circle.

The downside of TYPE(*) is that it either accepts scalars ("type(*) ::
var") or arrays (including array elements): "type(*), dimension(*)" but
not both. (That might changed in the next Fortran standard, but probably
only with bind(C).)

One way to accept both scalars and arrays is "type(*), dimension(..)",
but that uses an array descriptor and not not just an address like
"void*" would do.

For TS29113, see: ftp://ftp.nag.co.uk/sc22wg5/N1901-N1950/N1942.pdf

(By the way, both TYPE(*) and CLASS(*) are implemented in GCC 4.8 (and
4.9).)

Tobias

[Richard Maine]

Beliavsky <beli...@aol.com> wrote:

> According to Tobias Burnus in an earlier message, the standards committee
> understands this, and the next Fortran standard is largely about
> corrections and clarifications of previous standards.

We'll see. Sounds familliar. The standards committee also said that
f2008 was supposed to be a small revision. And there were multiple
people on the committee who thought it should be postponed until after
there was time for user experience with f2003. I sure know that's what I
thought, and I had correspondence with some other WG5 members (notably
some from the UK) who expressed simillar opinions.

But in my opinion, the committee had trouble with matching the detailed
plans with that broad goal. Sort of like budget plans where everyone
agrees to cut the budget, but wants to increase each individual line
item. Ended up being a pretty major revision in my estimation. It
certainly came out before many people had experience with f2003. And I
think that work on the new features ended up distracting from much
needed corrections and clarifications. Yes, I know that there are those
who disagree with my perception of this or who think it was necessary.

That's one of the reasons I left the committee. I didn't like the
direction I saw it going, and I'd have ended up just being a naysayer,
which is not a role I like. Given the "lead, follow, or get out of the
way" choice, I choose to get out of the way. I didn't see f2008 as being
something I had much interest in working on (and I didn't have enough
experience in some of the major areas to feel I could contribute much
anyway).

That wasn't the only reason I left. I was also about to retire from
NASA, who had been at least partially paying for my trips to meetings. I
suspect it was going to be getting harder to get NASA to pay for the
trips anyway, as the bean counters were becoming more insistent that
everything had to be directly supporting particular NASA projects. Plus
I had been on the committee (and dedicating quite a lot of my time) for
enough years that I was just starting to burn out. But my disapproval of
the direction of f2008 was certainly at least a factor.

[Gib Bogle]

On 29/05/2013 12:08 a.m., Beliavsky wrote:
> Terence thinks that Fortran 77 meets his needs and largely sticks to
> it. I wonder if there is another contingent of Fortran programmers
> who will stop at Fortran 95 (in my case with a few extensions such as
> allocatable arrays as components in derived types and as procedure
> arguments). So far I have not felt the need to use the
> object-oriented features of Fortran 2003, but that might change if I
> studied them more.

<snip>

I am the same.

[Terence]

Belivaski wrote (extract):

>Terence thinks that Fortran 77 meets his needs and largely sticks to it

Well, mainly yes, but I still do use the latest (last!) DVF compiler for
native Windows work (I couldn't get the Intel one to install, in spite of
much communication). And I have licences for my compilers (which cost more
that the computers, not counting the additional cost of the IDEs and
libraries).

But my point was about a definable level of Fortran, that is simple,
comprehensible, sufficiently encompassing of typical University level
mathematics, and easily teachable at such a level in a short time, so as to
be usable later in degree years, as a problem-solving tool. I don't care
about having matrix abbreviations and the like found in later standards. In
principle, a subroutine or a call to a library can take care of written
shortcuts without introducing them to the language.

Really the only problem with the F77 implementations of the eighties, was
the 64kb limitation on individual matrices (named 'common'). But there were
always disks (and evn the odd tape drive) on microcomputers. It's a long
way from starting out building computers in the fifties to be buying them
off the shelf.

Terence

[Terence]

Belivasky wrote (extract):