Home > Archive > Fortran > August 2005 > Fortran 77 vs Fortran 90/95
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Fortran 77 vs Fortran 90/95
|
|
| crash_zero 2005-08-06, 9:02 am |
| Hi,
I'm a Fortran 77 programmer. I haven't switched over to Fortran 90/95.
I would like to hear the views of those who switched over to Fortran
90/95.
- How different is it from Fortran 77?
- What are the advantages of it over Fortran 77?
- How stable is Fortran 90/95 compared to Fortran 77?
Thanks
| |
| Duane Bozarth 2005-08-06, 5:01 pm |
| crash_zero wrote:
>
> Hi,
>
> I'm a Fortran 77 programmer. I haven't switched over to Fortran 90/95.
> I would like to hear the views of those who switched over to Fortran
> 90/95.
>
> - How different is it from Fortran 77?
Since it is a superset of F77 for all practical purposes, you can treat
it exactly like your previous F77 so there isn't any reason to fear its
being "different"
> - What are the advantages of it over Fortran 77?
Many...which are most significant depends on the specific individual.
Just a few of the highlights include (but are not limited to :) )-
free-form source files
modules
array operation syntax
generic user-defined procedures
pointers
....
> - How stable is Fortran 90/95 compared to Fortran 77?
That's a compiler-dependent question. Generically, I'd say there are no
major issues w/ commercially available compilers. I understand (and
someone will be sure to correct me) that the open-source compilers are
still in progress.
>
> Thanks
| |
| crash_zero 2005-08-06, 5:01 pm |
| Hi Duane,
Would that mean that Fortran 90/95 has a more C/C++ like structure?
i.e. I'm assuming that my modules, you would mean something like
objects.
Hmmm... pointers, that would be nice to implement data structures and
algorithms in.
Anyway, a little more about myself. My name's Adrian and I'm 23 this
September. Kinda funny but yeah, I program in Fortran and a few other
languages.
Pleased to meet you Duane.
| |
| e p chandler 2005-08-06, 5:01 pm |
| crash_zero wrote:
> Would that mean that Fortran 90/95 has a more C/C++ like structure?
> i.e. I'm assuming that my modules, you would mean something like
> objects.
In the sense that you have data hiding and user defined types, yes. F9x
may resemble C/C++ more but F9x is *not* C/C++.
> Hmmm... pointers, that would be nice to implement data structures and
> algorithms in.
It is amazing what you can do in modern Fortran. In addition, pointers
and some of the other new features are somewhat less dangerous than
they are in C/C++.
> Anyway, a little more about myself. My name's Adrian and I'm 23 this
> September.
Nice to see the youngsters still program in Fortran. :-).
| |
| Richard Maine 2005-08-06, 5:01 pm |
| In article <42F4C970.286863F0@swko.dot.net>,
Duane Bozarth <dpbozarth@swko.dot.net> wrote:
> crash_zero wrote:
>
> That's a compiler-dependent question. Generically, I'd say there are no
> major issues w/ commercially available compilers.
Since the question is "compared to Fortran 77" and the context is today,
I think it is worth noting that commercial compilers that are f77-only
pretty much don't exist today. There are probably one or two hiding
around somewhere, but it is largely a nonexistent breed, particularly if
you want something that is actually has active current support. Most f77
compilers today are also f90 compilers (and all f90 compilers are also
f77 compilers, f77 being a subset of f90), so there is no distinction.
There can well be stability distinctions in terms of what features of
the compiler you use, but that's a different question. Even there, f90
being 15 years old now, that's awfully old in dog^h^h^hcomputer years.
There are some newish features that have more questionable stability
than the old features, but for the most part that is features a lot more
recent than f90. Allocatable components are an oft-noted example, but
those are even post-f95.
I'll mostly leave to others the question of what is different in f90. As
has been said - a lot, but f77 is a subset, so you can learn new f90
features a bit at a time. That bit is important. You don't have to make
an all-or-nothing decision. You can start by using small features that
you find help you.
For that matter, odds are strong that you are already using quite a few
f90 features. *VERY* few people actually stick strictly to the f77
standard, even among people that claim to disdain f90. F90 includes a
lot of the extensions to f77 that were such widely adopted extensions to
f77 that many people think of them as f77. Some of these are so trivial
that many people probably don't even think of them as features or be
conscious of using them. Examples include the use of lower case and
variable names longer than 6 characters.
| |
| Richard Maine 2005-08-06, 5:01 pm |
| In article <1123342693.392493.307130@g47g2000cwa.googlegroups.com>,
"e p chandler" <epc8@juno.com> wrote:
> crash_zero wrote:
>
>
> In the sense that you have data hiding and user defined types, yes. F9x
> may resemble C/C++ more but F9x is *not* C/C++.
It is common for people to make that comparison, but I'd say it is
mostly among people whose exposure to different programming languages is
relatively limited - notably those who have seen little other than
Fortran 77 and C-like languages. It is certainly true that Fortran 90
adds many features that have analogues in C, but often those features
also have analogues in most modern languages. If C and C++ are the only
other modern languages someone knows, then F90 probably looks a lot like
them. But I'd say that is just because of features it shares with many
languages and that the F90 version of the features isn't particularly
C-like.
When I try to make such a language analogy for f90, I generally say that
it somewhat like a cross between Fortran 77 and Ada. I see more of Ada
than C in f90. All such analogies are flawed, but I personally feel that
is at least closer than the F90=F77+C one.
One specific point I'll make because it is one that leads many people
astray. You are far from the first to try to think of modules as like
C++ objects or classes. That is not a "good" analogy. It will lead you
*FAR* astray; it has done so for other people. If you try to think of
modules as being like C objects, then you will perpetually have trouble
understanding modules; that particular analogy is broken badly enough to
make it harder rather than easier to understand modules.
The closest f90 analogy to a C++ class is the Fortran derived type. It
isn't the same thing, but at least it is in the right general
"direction". Indeed, when classes were added to Fortran (as they were in
f2003, which you can't get compilers for yet), the F90 classes are
basically extensions of the concept of derived types - not extensions of
the concept of modules.
I'd say a Fortran module is closer to an Ada package. Not identical, but
at least it shares some heritage.
| |
| Steven G. Kargl 2005-08-06, 5:01 pm |
| In article <42F4C970.286863F0@swko.dot.net>,
Duane Bozarth <dpbozarth@swko.dot.net> writes:
> crash_zero wrote:
>
>
> Many...which are most significant depends on the specific individual.
> Just a few of the highlights include (but are not limited to :) )-
>
> free-form source files
> modules
> array operation syntax
> generic user-defined procedures
> pointers
dynamic memory allocation
derived data types
>
> That's a compiler-dependent question. Generically, I'd say there are no
> major issues w/ commercially available compilers. I understand (and
> someone will be sure to correct me) that the open-source compilers are
> still in progress.
Yes, g95 and gfortran are progressing rapidly. If you don't
want to hassle with too many bugs, then g95 is probably your
cup of tea. If you have odd hardware or an OS not supported
by a commercial compiler or g95, then gfortran is probably the
only game in town.
If you keep to a F77 and only a few F90/95 features, then either
g95 or gfortran should work.
--
Steve
http://troutmask.apl.washington.edu/~kargl/
| |
| Walter Spector 2005-08-06, 5:01 pm |
| Richard Maine wrote:
> ...
> One specific point I'll make because it is one that leads many people
> astray. You are far from the first to try to think of modules as like
> C++ objects or classes. That is not a "good" analogy. It will lead you
> *FAR* astray; it has done so for other people. If you try to think of
> modules as being like C objects, then you will perpetually have trouble
> understanding modules; that particular analogy is broken badly enough to
> make it harder rather than easier to understand modules.
This is certainly true. But to be sorta fair to those who want to think
of a module as a class, it should be noted that some "authorities" actually
encourage this line of thinking. (Notably the Symanski papers on OOP
Programming in Fortran-90, and Akins book on "Object Oriented Programming
in Fortran 90/95".)
Since a class is bascically a derived type, with a bunch of associated
methods, it can be a useful way to organize a module to follow this.
F2003 type-bound procedures and the like will, of course, make methods
somewhat simpler to use. But I suspect the "one class per module" technique
may still represent a nice way to structure ones code.
To the original poster:
Learn F95. While F77 is a subset of F95, it is not a 'good' subset.
If I were to throw things out of F95, and did not have to worry about
legacy applications, much of what I would throw out would be certain
F77 anachronisms. ("Default data typing", and COMMON blocks, being at
the top of the list.)
Some good things about F95:
Besides things like 31-character variable names (...), modules are
a huge win, dynamic memory allocation (e.g., ALLOCATABLE arrays) is a
huge win, derived types - when intelligently used - can be a huge win.
The F90 procedure calling sequence is a huge win (in most cases.)
As Richard notes, by now most commercial compilers have had a decade or more
of 'hardening' and are quite stable. The freebee g95 and gfortran less so,
but are apparently getting pretty good now too. And even in the latter
case, a relatively inexperienced programmer probably will not be probing the
really esoteric issues - where dragons lie - anytime soon.
Walt
(w6ws att earthlinkk dott nett)
| |
| Peter Browry 2005-08-06, 5:01 pm |
|
> Since the question is "compared to Fortran 77" and the context is today,
> I think it is worth noting that commercial compilers that are f77-only
> pretty much don't exist today. There are probably one or two hiding
> around somewhere, but it is largely a nonexistent breed, particularly if
> you want something that is actually has active current support. Most f77
> compilers today are also f90 compilers (and all f90 compilers are also
> f77 compilers, f77 being a subset of f90), so there is no distinction.
True but this fact causes the question below.
> For that matter, odds are strong that you are already using quite a few
> f90 features. *VERY* few people actually stick strictly to the f77
> standard, even among people that claim to disdain f90. F90 includes a
> lot of the extensions to f77 that were such widely adopted extensions to
> f77 that many people think of them as f77. Some of these are so trivial
> that many people probably don't even think of them as features or be
> conscious of using them. Examples include the use of lower case and
> variable names longer than 6 characters.
I am one of these people who believe that "f77 + the (OLD) common extensions"
(such as longer variable names, "call system", etc) is sufficient for my
job which requires a fast real*8 calculations and I do not care about
allocation of memory or pointers. Also for me debugging a f77 code is much
easier than the modular f90/95 code (probably because I know very well only
the f77). So, currently I still use "f77 + the (OLD) common extensions/CE" as a
subset of my newest 90/95/96/97/97.1 etc compilers - sorry I lost the counting :-))
The question now:
In the past, code written in f90 was regarded to be slower then the same code
written in f77+CE (or at least this is what I think it was).
Is it still true?
If not anymore, does this have to do with the fact that (pure) f77+CE compilers do not
exist anymore? so f90 compilers may support both codes but they are optimized
for f90 codes?
Thanks!
/Peter
| |
| Duane Bozarth 2005-08-06, 5:01 pm |
| Peter Browry wrote:
....
> In the past, code written in f90 was regarded to be slower then the same code
> written in f77+CE (or at least this is what I think it was).
>
> Is it still true?
I don't accept it ever was true as a general precept. There are some
specific features of F90/95 that may cause some performance problems,
but that has to do w/ those features, not the broad generality.
> If not anymore, does this have to do with the fact that (pure) f77+CE compilers do not
> exist anymore? so f90 compilers may support both codes but they are optimized
> for f90 codes?
>
> Thanks!
>
> /Peter
| |
| David Flower 2005-08-06, 5:01 pm |
|
crash_zero wrote:
> Hi,
>
> I'm a Fortran 77 programmer. I haven't switched over to Fortran 90/95.
> I would like to hear the views of those who switched over to Fortran
> 90/95.
>
> - How different is it from Fortran 77?
> - What are the advantages of it over Fortran 77?
> - How stable is Fortran 90/95 compared to Fortran 77?
>
> Thanks
There is no doubt that F90 includes some goodies that are of immense
value. However, this is at a cost, as F90 compilers are not as bug free
as F77 ones, and given the size of the language, may never be.
Personallyly, I avoid extensions unless I really need them. What I have
used are:
- Various intrinsics
- INTERFACE
I would avoid free-format code like the plague.
| |
| Richard Maine 2005-08-06, 5:01 pm |
| In article <dd2ute$1bh$1@grapevine.wam.umd.edu>,
Peter Browry <pbrowry@yahoo.com> wrote:
> In the past, code written in f90 was regarded to be slower then the same code
> written in f77+CE (or at least this is what I think it was).
>
> Is it still true?
This has pretty much never been true. It has been stated several times,
but that doesn't actually make it true. This is one of those cases where
it turns out that you have to find out exactly what people mean by the
words they are using. Different people mean different things when they
make statements like this.
One of the more common misleading meanings of statements like this
involves the definition of what it means to "write code in f90". The
definition of that is neither obvious nor universal.
What you will sometimes see is that some people are hung up with
labeling DO loops as an f77 feature. Thus sometimes when someone says
"writing code in f90", they really mean writing code that uses whole
array expressions instead of DO loops. Yes, there are some cases where
whole loop expressions are slower than DO loops. The specifics have
changed over time and vary from one compiler to another, but their
certainly exist cases.
However, many if us (me, for example) entirely reject the identification
of "writing code in f90" as meaning to avoid DO loops. DO loops are
perfectly fine f90, and not just because f77 is included in f90; they
are perfectly fine modern f90 and the best approach to some things.
In my personal opinion, whole array expressions aren't even among the
most interesting features that were new to f90. They are occasionally
convenient, but when I list the things that drove me to move to f90,
array expressions doesn't even make the list. So I pretty strongly
disagree with the characterization that writing code in f90 means using
array expressions.
My list probably has derived types and dynamic allocation at the top. In
the late '80s I had decided that, as comfortable as I had been in
Fortran for nearly 2 decades then, I needed a language with those 2
features for a new application I was starting. It was going to be just
too painful to fake them in f77. (People do at least the dynamic
allocation part, but it is just too painful). I looked at non-Fortran
choices (notably C and Ada) and was not happy with them. When I found
out about f90, I decided that it had what I needed in a way that I could
understand and use. That was before the first f90 compilers were
available, but I decided that it was worth the risk to write to the
future compilers, because my alternatives (including f77+extensions)
were so bad.
I've since come to be quite find of other f90 features, but it was
derived types (structures) and dynamic allocation that drove me to the
language in the first place.
| |
| Thomas Koenig 2005-08-06, 5:01 pm |
| David Flower <DavJFlower@AOL.COM> wrote:
>I would avoid free-format code like the plague.
Why?
| |
| robert.corbett@sun.com 2005-08-07, 4:01 am |
| > How different is it from Fortran 77?
Fortran 95 is quite different from FORTRAN 77.
Almost all of standard-conforming FORTRAN 77
is there, but finding it among the crowd can be
challenging. Fortran 95 is much more complex than
FORTRAN 77. Fortran 2003 is much more complex
than Fortran 95. I have seen the proposals for
extensions in the next Fortran standard, and if even
a quarter of those proposals are approved, the next
standard will be much more complex than Fortran 2003.
> What are the advantages of it over Fortran 77?
There are lots of advantages. In my opinion, the most
important is dynamic storage allocation.
> How stable is Fortran 90/95 compared to Fortran 77?
The FORTRAN 77 subset of Fortran 95 tends to be
fairly stable. All the vendors have good test suites
for FORTRAN 77.
OTHO, Fortran 95 compilers are, as a rule, much bigger
and much slower than FORTRAN 77 compilers.
Optimizing array expressions in particular is a bottomless
sink for code space and compilation time.
Bob Corbett
| |
| David Flower 2005-08-07, 9:01 am |
| a) It is gratuitously incompatible with f77
b) I use a PC, and most editors, browsers etc. are based on an
80-character line. This is also true of other systems. I agree that the
punched card is obsolete, but the 80-character line is not, and to
deviate from it is wilful stupidity.
| |
| Gordon Sande 2005-08-07, 9:01 am |
|
David Flower wrote:
> a) It is gratuitously incompatible with f77
>
> b) I use a PC, and most editors, browsers etc. are based on an
> 80-character line. This is also true of other systems. I agree that the
> punched card is obsolete, but the 80-character line is not, and to
> deviate from it is wilful stupidity.
>
I don't recall seeing an 80 column editor for a PC since CRTs stopped
being glass teletypes of 80 x 25 characters and started to be bit mapped
screens. I have an editor which has an option to put a gray background
behind the first 80 columns. If they were concerned about Fortran it
would be at 72. The feature is so important that I have not looked to
see if the 80 is hardwired or adjustable.
I have not been into EDT emulators so perhaps my experience is a
bit limited with the legacy editors. I thought that my preference
for monospaced fonts in text editors marked me as a candidate member
of the old foggy crowd.
| |
| Rich Townsend 2005-08-07, 5:02 pm |
| David Flower wrote:
> a) It is gratuitously incompatible with f77
Of course it is. An alternative syntax format must, tautologically, be
incompatible with f77. How else could it be done?
>
> b) I use a PC, and most editors, browsers etc. are based on an
> 80-character line. This is also true of other systems. I agree that the
> punched card is obsolete, but the 80-character line is not, and to
> deviate from it is wilful stupidity.
>
If you upgraded your PC from MS-DOS to one of the new-fangled (Windows
95 and upward) operating systems that supported scalable fonts, you
could fit far more than 80 characters on a line.
How many, of course, would depend on your display resolution. That's
something that's also changed since MS-DOS; no longer are we restricted
to EGA and CGA. From my experience, a standard display size is 1024x768
(XGA); assuming 8 pixels width are required for each glyph, you can see
that one can fit far more than 80 characters on each line.
cheers,
Rich
| |
| Charles Russell 2005-08-07, 5:02 pm |
| In-Reply-To: <dd555m$jjo$1@scrotar.nss.udel.edu>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Lines: 15
Message-ID: <yBpJe.2878$lK2.877@trndny01>
Date: Sun, 07 Aug 2005 15:16:46 GMT
NNTP-Posting-Host: 64.222.214.51
X-Complaints-To: abuse@verizon.net
X-Trace: trndny01 1123427806 64.222.214.51 (Sun, 07 Aug 2005 11:16:46 EDT)
NNTP-Posting-Date: Sun, 07 Aug 2005 11:16:46 EDT
Xref: number1.nntp.dca.giganews.com comp.lang.fortran:135448
Rich Townsend wrote:
> If you upgraded your PC from MS-DOS to one of the new-fangled (Windows
> 95 and upward) operating systems that supported scalable fonts, you
> could fit far more than 80 characters on a line.
>
> How many, of course, would depend on your display resolution. That's
> something that's also changed since MS-DOS;
The resolution of my eyeballs has also changed since MS-DOS, and I would
no longer want more than 80 characters on a line.
Also, the less flexibility there is in writing and formatting code, the
easier it is to read someone else's code. The style and idiom used in
f77 got pretty well honed down over the years.
| |
| Rich Townsend 2005-08-07, 5:02 pm |
| Charles Russell wrote:
> Rich Townsend wrote:
>
>
>
> The resolution of my eyeballs has also changed since MS-DOS, and I would
> no longer want more than 80 characters on a line.
>
> Also, the less flexibility there is in writing and formatting code, the
> easier it is to read someone else's code. The style and idiom used in
> f77 got pretty well honed down over the years.
But how about control structure indenting? With three nested loops, each
indented by 3 characters, you've already used up 6+3*3=15 characters of
a line before the code starts -- over 1/5 of the line length!
I find with free-form source, plus a consistent and coherent indenting
scheme, I can write very readable code. Can I offer my recently-debated
ISO_VARYING_STRING module as an example:
http://www.star.ucl.ac.uk/~rhdt/dow...ying_string.f90
cheers,
Rich
| |
| BrownSugar 2005-08-07, 5:02 pm |
| Before dream on after F2003, I dream a real F2003 compiler.
The big problem is Java, C#, VB.Net etc. progress year after year.
Also, if you speak Fortran... first comment is "old language".
<robert.corbett@sun.com> wrote in message
news:1123389611.331673.3440@g47g2000cwa.googlegroups.com...
>
> Fortran 95 is quite different from FORTRAN 77.
> Almost all of standard-conforming FORTRAN 77
> is there, but finding it among the crowd can be
> challenging. Fortran 95 is much more complex than
> FORTRAN 77. Fortran 2003 is much more complex
> than Fortran 95. I have seen the proposals for
> extensions in the next Fortran standard, and if even
> a quarter of those proposals are approved, the next
> standard will be much more complex than Fortran 2003.
>
>
> There are lots of advantages. In my opinion, the most
> important is dynamic storage allocation.
>
>
> The FORTRAN 77 subset of Fortran 95 tends to be
> fairly stable. All the vendors have good test suites
> for FORTRAN 77.
>
> OTHO, Fortran 95 compilers are, as a rule, much bigger
> and much slower than FORTRAN 77 compilers.
> Optimizing array expressions in particular is a bottomless
> sink for code space and compilation time.
>
> Bob Corbett
>
| |
| Rich Townsend 2005-08-07, 5:02 pm |
| BrownSugar wrote:
> Before dream on after F2003, I dream a real F2003 compiler.
> The big problem is Java, C#, VB.Net etc. progress year after year.
> Also, if you speak Fortran... first comment is "old language".
....and the immediate retort is 'netlib'. None of these adolescent
languages has anything close to netlib.
cheers,
Rich
| |
| crash_zero 2005-08-07, 5:02 pm |
| Well,
Fortran may be an "old language", but the fact that younger programmers
like me are still using it means that it is still alive and kicking.
*smile*
Personally, I've just taken a look at F90/95, its good but I still find
F77 more elegant and simplistic to use than F90/95. This is not to say
I'm won't be learning the language though.
Anyway, thanks for all the comments guys. They really helped me.
-Original Thread Poster-
| |
| Steven G. Kargl 2005-08-07, 5:02 pm |
| In article <1123429926.019852.302180@g49g2000cwa.googlegroups.com>,
"crash_zero" <choo.adrian@gmail.com> writes:
>
> Fortran may be an "old language", but the fact that younger programmers
> like me are still using it means that it is still alive and kicking.
> *smile*
The latest revision of Fortran was ratified as an international
standard last year. So, it is definitely alive and well.
> Personally, I've just taken a look at F90/95, its good but I still find
> F77 more elegant and simplistic to use than F90/95. This is not to say
> I'm won't be learning the language though.
As you program with a set of F77 features, you'll start
to pick up newer features because of their usefulness/power.
--
Steve
http://troutmask.apl.washington.edu/~kargl/
| |
| e p chandler 2005-08-07, 5:02 pm |
| Rich Townsend wrote:
> BrownSugar wrote:
No, the real problem is that vendors come up with incompatible
languages year after year in order to lock out their competitors. Then
they write Byzantine APIs on top of them.
One of the great advantages of Fortran is that you can continue to
compile old programs. Ask VB6 programmers how they enjoyed migrating to
VB.Net.
[color=darkred]
> ...and the immediate retort is 'netlib'. None of these adolescent
> languages has anything close to netlib.
>
> cheers,
>
> Rich
Well Perl and Python have libraries for almost anything, but why would
I want to use languages where substring notation starts at zero and
ends somehere in never-never land _between_ characters?
| |
| Brooks Moses 2005-08-07, 5:02 pm |
| David Flower wrote:
> b) I use a PC, and most editors, browsers etc. are based on an
> 80-character line. This is also true of other systems. I agree that the
> punched card is obsolete, but the 80-character line is not, and to
> deviate from it is wilful stupidity.
I don't remember any requirement that free-format code use lines longer
than 80 characters. It merely prevents one from getting errors on the
times when one uses lines (a little) longer than that.
Certainly in my own free-format code, I rarely use lines longer than 72
characters, simply for readability.
(I'll leave debating that "most" to other people, but I can't remember
having seen _any_ non-DOS editors or browsers that are based on
80-character lines, ever. And that includes the ones on my Linux box
and under Cygwin that run in text mode.)
- Brooks
--
The "bmoses-nospam" address is valid; no unmunging needed.
| |
| Brooks Moses 2005-08-07, 5:02 pm |
| BrownSugar wrote:
> Before dream on after F2003, I dream a real F2003 compiler.
> The big problem is Java, C#, VB.Net etc. progress year after year.
> Also, if you speak Fortran... first comment is "old language".
That "old language" comment is invariably from people who think that the
language is unchanged since F77, however. I don't think the language
should really be blamed for people's misperceptions.
- Brooks
--
The "bmoses-nospam" address is valid; no unmunging needed.
| |
|
| Thomas Koenig wrote:
>
>
> Why?
Code, like other printed stuff is for the human eye and until books, and
in particular computer manuals with their *fat* side margins, are fixed,
freestyle coding is, as already aptly described, willful stupidity.
| |
| Richard Maine 2005-08-07, 5:02 pm |
| In article <1123421236.316374.305450@o13g2000cwo.googlegroups.com>,
"David Flower" <DavJFlower@AOL.COM> wrote:
[about free source form]
> a) It is gratuitously incompatible with f77
It is incompatible, certainly. That's sort of the nature of new features.
Gratuitously? I might be tempted to describe the use of that term in
this context as gratuitous. :-) You think there was no reason for or
interest in this feature to motivate it? That's what "gratuitous"
would imply.
My observation is that free source form is one of the most widely
accepted and desired features in f90. I don't think I'd use up one
hand in counting the number of people that have expressed dislike
of it (and yes, that's now including you). The main complaint about
it I hear is that it was long overdue. For that matter, nonstandard
variants of free source form are high on the list of things that
people mean when they talk about f77 plus common extensions. I've
seen people say that free source form doesn't even count as "really"
being a new f90 feature because of that.
I've helped more than a handful of programmers who use f77 and
fixed source form find the switch to allow long source lines
in fixed source form as an f77 extension. Indeed, I'm not at
all sure that I haven't seen more users of fixed source form
who use long source lines as an extension than I've seem free
source form users actually write lines that long. After all,
in fixed source form, you don't get to start until column 7,
so you are actually limited to 65 characters if you stick to the
standard.
> b) I use a PC, and most editors, browsers etc. are based on an
> 80-character line. This is also true of other systems.
Could you name perhaps one such? I can't off-hand think of any. I
certainly knew of old terminals, and some newer terminal emulators that
are so based, but I can't think of any editors or browsers.
> I agree that the
> punched card is obsolete, but the 80-character line is not, and to
> deviate from it is wilful stupidity.
You seem to be hung up on free source form implying lines longer than
80 characters. It does not. It *ALLOWS* such lines. You don't
actually have to make your lines exactly 132 characters long any more
than you have to have 29 continuation lines or make all your
arrays rank 7. In my own free source form code, I almost never go
beyond column 80. Heck, I usually stay below 72 or so, not because
that was the old fixed source form limit, but because that's
about long enough for good readability and, yes, because I often
use editor windows that I keep about that size. (The editors
will perfectly well handle more, but I often keep them down to
about that).
It is my impression that most f90 coders keep most of their lines
down to about that size. Have you actually observed otherwise in
a significant sample? If so, I must wonder what kind of population
you draw your samples from. If you don't actually see much of this
(as I don't), I'd have to wonder why the vehemence over such a
matter.
| |
| Louis Krupp 2005-08-07, 10:00 pm |
| crash_zero wrote:
<snip>
> Personally, I've just taken a look at F90/95, its good but I still find
> F77 more elegant and simplistic to use than F90/95. This is not to say
> I'm won't be learning the language though.
Look up the definition of "simplistic." Are you sure that's what you
meant? Words aren't always better just because they're bigger.
I know, you probably weren't an English major, but as a FORTRAN (and
hopefully soon to be Fortran) programmer, you're held to a higher
standard than the rest of your comp sci classmates.
Louis
| |
| John Halpenny 2005-08-07, 10:00 pm |
| Richard Maine wrote:
<snip>
>
> I've since come to be quite find of other f90 features, but it was
> derived types (structures) and dynamic allocation that drove me to the
> language in the first place.
This is interesting. I've been using Watcom fortran 77- now OpenWatcom and free -
and they have dynamic allocation, structures, end do, and long, lower case
filenames. Maybe I have the benefits of fortran 90 without the hassle.
--
John Halpenny
Truth is stranger than fiction.
This is why writers and readers are more comfortable with fiction.
| |
| BrownSugar 2005-08-07, 10:00 pm |
| Yes, I am also an VB6 programmer and effectively VB.Net is a big surprise
(negative!)
I have no experience with VB.Net and DLL Fortran... but, I suppose this is
an other big surprise :-(
Effectively, Fortran compiler is anywhere, anytime full compatible with very
old programs
I love this.
"e p chandler" <epc8@juno.com> wrote in message
news:1123434031.809458.194110@g44g2000cwa.googlegroups.com...
> Rich Townsend wrote:
>
> No, the real problem is that vendors come up with incompatible
> languages year after year in order to lock out their competitors. Then
> they write Byzantine APIs on top of them.
>
> One of the great advantages of Fortran is that you can continue to
> compile old programs. Ask VB6 programmers how they enjoyed migrating to
> VB.Net.
>
>
> Well Perl and Python have libraries for almost anything, but why would
> I want to use languages where substring notation starts at zero and
> ends somehere in never-never land _between_ characters?
>
| |
| Richard Maine 2005-08-07, 10:00 pm |
| In article <42F69DC7.8A215647@Rogers.com>,
John Halpenny <j.halpenny@Rogers.com> wrote:
> Richard Maine wrote:
>
>
> This is interesting. I've been using Watcom fortran 77- now OpenWatcom and
> free -
> and they have dynamic allocation, structures, end do, and long, lower case
> filenames. Maybe I have the benefits of fortran 90 without the hassle.
If a single-vendor proprietary solution suits your needs, then I'm happy
for you. I don't have the benefit of such a luxury.
My applications get used by people on lots of different platforms. The
people wouldn't even bother to give me strange looks if I told them that
they had to go with a particular vendor in order to use the
applications; they would just assume that I had a rather odd sense of
humor. And then they would find someone who could actually write
applications that met their needs instead of playing practical jokes on
them. :-(
I've nothing against Watcom. Fine f77 compiler as far as I know. I think
I even used it some a long time ago. I've used so many Fortran compilers
that the details blur together, but I think Watcom was once one of them.
But if it was, I'm sure I stuck to standard, portable Fortran code when
using it, because that's required for what I do. I'm sure that my f77
code would have run fine on Watcom.... as it would on most any f77
compiler.
| |
| Richard Maine 2005-08-07, 10:00 pm |
| In article <11fd6rpt2f3ilef@corp.supernews.com>,
Louis Krupp <lkrupp@pssw.nospam.com.invalid> wrote:
> crash_zero wrote:
> <snip>
>
> Look up the definition of "simplistic."
:-)
But even with "simple", have you ever tried to explain the actual
working of, say, common blocks or array argument passing to someone who
didn't already know it? For that matter, do you know all the quirks of
them? I mean the full gore of what the standard does and doesn't allow -
not the simple cases. Can you list all the differences between blank and
named common without looking them up? Do you know what is and is not
allowed as an actual argument corresponding to an array dummy?
I've observed that many people who think that f77 is simple don't
actually know about its complications. :-( Yes,one can stick to a
simple subset of f77, just as one can stick to a simple subset of f90,
but I hesitate to describe the whole of f77 as simple and elegant. It
has too many arbitrary restrictions for me to label it as elegant. Some
of those restrictions are pretty much impossible for a user to
understand unless he/she thinks about compiler implementations and
realizes that temporary dynamic storage might be involved. There just
isn't any other way to explain why, for suitable declaration of dummy,
string = dummy // 'a'
is valid, but
call sub(dummy // 'a')
is not. And if you read the bit of the standard that explains this,
you'll have to go very slowly because it involves at least a triple
negative, if not quadruple. I don't have it in front of me, but I recall
with horror trying to make sense of the exception to the exception, or
some such thing. That's not my idea of elegant. :-(
| |
| Rich Townsend 2005-08-08, 4:01 am |
| Richard Maine wrote:
> In article <11fd6rpt2f3ilef@corp.supernews.com>,
> Louis Krupp <lkrupp@pssw.nospam.com.invalid> wrote:
>
>
>
>
> :-)
>
> But even with "simple", have you ever tried to explain the actual
> working of, say, common blocks or array argument passing to someone who
> didn't already know it? For that matter, do you know all the quirks of
> them? I mean the full gore of what the standard does and doesn't allow -
> not the simple cases. Can you list all the differences between blank and
> named common without looking them up? Do you know what is and is not
> allowed as an actual argument corresponding to an array dummy?
>
> I've observed that many people who think that f77 is simple don't
> actually know about its complications. :-( Yes,one can stick to a
> simple subset of f77, just as one can stick to a simple subset of f90,
> but I hesitate to describe the whole of f77 as simple and elegant. It
> has too many arbitrary restrictions for me to label it as elegant. Some
> of those restrictions are pretty much impossible for a user to
> understand unless he/she thinks about compiler implementations and
> realizes that temporary dynamic storage might be involved. There just
> isn't any other way to explain why, for suitable declaration of dummy,
>
> string = dummy // 'a'
>
> is valid, but
>
> call sub(dummy // 'a')
>
> is not. And if you read the bit of the standard that explains this,
> you'll have to go very slowly because it involves at least a triple
> negative, if not quadruple. I don't have it in front of me, but I recall
> with horror trying to make sense of the exception to the exception, or
> some such thing. That's not my idea of elegant. :-(
Yes, but nothing comes quite close to the sheer horror that is TKR
matching in F9X. I couldn't think straight for days; luckily, I've
forgotten it all now...
:)
cheers,
Rich
| |
|
|
| Charles Russell 2005-08-08, 5:03 pm |
| Rich Townsend wrote:
> But how about control structure indenting? With three nested loops, each
> indented by 3 characters, you've already used up 6+3*3=15 characters of
> a line before the code starts -- over 1/5 of the line length!
True. It would be nice to use all 80 characters at least, but I have
never checked to see which of my old utilities that might mess up. I
routinely indent by two characters, and when that is not enough, I mark
matching pairs of control structures with something like ###### or
******, or put a big block in an include file with an informative name.
The latter methods work across page breaks, where indenting is not very
helpful.
| |
| sali0090@tc.umn.edu 2005-08-08, 5:03 pm |
| Most undergrad engineering schools teach Fortran to the freshman. For
scientific / engineering classes, they typically use either Fortran or
Matlab.
It's much easier to teach vs. C/C++, but you still get all of the speed
benefits of C.
The only obstacle is getting over the names. Learning something called
Fortran77 (or even 90) feels a bit antiquated, especially if you were
born in the 80s. ;) It must be our hyper craving for new technological
solutions. (I did say 'feel' and not 'is'!)
| |
| Gordon Sande 2005-08-08, 5:03 pm |
|
Peter Browry wrote:
>
>
>
> True but this fact causes the question below.
>
>
>
> I am one of these people who believe that "f77 + the (OLD) common
> extensions"
> (such as longer variable names, "call system", etc) is sufficient for my
> job which requires a fast real*8 calculations and I do not care about
> allocation of memory or pointers. Also for me debugging a f77 code is much
> easier than the modular f90/95 code (probably because I know very well only
> the f77). So, currently I still use "f77 + the (OLD) common
> extensions/CE" as a
> subset of my newest 90/95/96/97/97.1 etc compilers - sorry I lost the
> counting :-))
If you want good debugging then you should run, that is run and not
walk, to use the F77 subset combined with the use of module procedures
with their good checking. And assumed shape, the ":" stuff, makes for
better subscript checking. F90 is a much safer language than F77.
If you are not using the error prone construct of passed procedures
then you can convert a collection of F77 code into call checked
F90 by adding about 5 lines of new fangled stuff like contains.
And if your code is tame then a global change on some arguments
will pick up the assumed shape stuff.
Unfortunately you are doing a superb imitation of someone who has
assumed a self defeating Luddite position. It may well be a sensible
response to some ill informed local provocation but it still remains
contrary to your stated objectives. Or maybe it is just flame bait and
I have been had.
> The question now:
>
> In the past, code written in f90 was regarded to be slower then the same
> code
> written in f77+CE (or at least this is what I think it was).
>
> Is it still true?
>
> If not anymore, does this have to do with the fact that (pure) f77+CE
> compilers do not
> exist anymore? so f90 compilers may support both codes but they are
> optimized
> for f90 codes?
>
> Thanks!
>
> /Peter
| |
|
| Having programmed using F77, then F90, then C++, then C# I am impressed at
how similar F90 is to C# not to C++.
"crash_zero" <choo.adrian@gmail.com> wrote in message
news:1123341344.533195.183160@g43g2000cwa.googlegroups.com...
> Hi Duane,
>
> Would that mean that Fortran 90/95 has a more C/C++ like structure?
> i.e. I'm assuming that my modules, you would mean something like
> objects.
>
> Hmmm... pointers, that would be nice to implement data structures and
> algorithms in.
>
> Anyway, a little more about myself. My name's Adrian and I'm 23 this
> September. Kinda funny but yeah, I program in Fortran and a few other
> languages.
>
> Pleased to meet you Duane.
>
| |
| Dr Ivan D. Reid 2005-08-10, 9:04 am |
| On Mon, 08 Aug 2005 16:18:07 GMT,
Charles Russell <STOPworSPAMwor@bellsouth.net>
wrote in <3BLJe.6474$eR.3321@trndny04>:
> True. It would be nice to use all 80 characters at least, but I have
> never checked to see which of my old utilities that might mess up. I
> routinely indent by two characters, and when that is not enough, I mark
> matching pairs of control structures with something like ###### or
> ******, or put a big block in an include file with an informative name.
> The latter methods work across page breaks, where indenting is not very
> helpful.
You might like to try a folding editor[1] for the latter, such as the
Zeus editor that was recently announced in this group. I fiddled briefly
with one back in my Atari/golem days but never took it up enthusiastically.
I can see where it could be a help, though.
[1] In case you are unfamiliar with the term, the editor can "fold" the
code around program structures, e.g. a long do-loop becomes a one-line
placeholder, so that the enclosing code is more readily followed. This
can be done to several levels of folding, of course, and the folded code
revealed again at a keystroke.
--
Ivan Reid, Electronic & Computer Engineering, ___ CMS Collaboration,
Brunel University. Ivan.Reid@[brunel.ac.uk|cern.ch] Room 40-1-B12, CERN
KotPT -- "for stupidity above and beyond the call of duty".
| |
| David Flower 2005-08-10, 5:06 pm |
|
Brooks Moses wrote:
> David Flower wrote:
>
> I don't remember any requirement that free-format code use lines longer
> than 80 characters. It merely prevents one from getting errors on the
> times when one uses lines (a little) longer than that.
I agree that there is no such requirement; the problem is that there is
no guarantee that there is no code hiding beyond coloumn 80. This is a
potential problem for maintenance.
>
> Certainly in my own free-format code, I rarely use lines longer than 72
> characters, simply for readability.
>
> (I'll leave debating that "most" to other people, but I can't remember
> having seen _any_ non-DOS editors or browsers that are based on
> 80-character lines, ever. And that includes the ones on my Linux box
> and under Cygwin that run in text mode.)
>
> - Brooks
>
>
> --
> The "bmoses-nospam" address is valid; no unmunging needed.
| |
| Gareth Owen 2005-08-10, 5:06 pm |
| "David Flower" <DavJFlower@AOL.COM> writes:
> I agree that there is no such requirement; the problem is that there is
> no guarantee that there is no code hiding beyond coloumn 80. This is a
> potential problem for maintenance.
While some editors are 80 column (e.g. the emacs in which I'm typing
this) I've never seen one that wouldn't word-wrap if you asked it to.
| |
| Gordon Sande 2005-08-10, 5:06 pm |
|
David Flower wrote:
> Brooks Moses wrote:
>
>
>
> I agree that there is no such requirement; the problem is that there is
> no guarantee that there is no code hiding beyond coloumn 80. This is a
> potential problem for maintenance.
>
Surely the problem is beyond 72 and not beyond 80. The classic examples
involve a continuation not picking up column 73 and changing the actual
program into something other than what was intended or appears unless
you notice the details of where the code is on the lines.
F90 has the capabilities to make that sort of thing impossible. BUT you
have to use them.
Lately there have been a goodly number of irritating ads for a golfing
magazine which includes the observation that you will never find out
about all their good advice UNLESS YOU READ IT as it is not good enough
to just buy the magazine. Maybe too many folks were using it to clean
their shoes and line their bird cages. It might be one of those free
give aways for all I have retained of the ads. But anyway the message is
the same that if you chose to avoid the enhancement then you will never
get the benefits.
>
>
>
| |
| Ron Shepard 2005-08-11, 9:03 am |
| In article <r5ivf2dhhlu.fsf@gill.maths.keele.ac.uk>,
Gareth Owen <usenet@gwowen.freeserve.co.uk> wrote:
> While some editors are 80 column (e.g. the emacs in which I'm typing
> this) I've never seen one that wouldn't word-wrap if you asked it to.
I have used emacs for almost 30 years now (originally it was written
in TECO macros), and as far as I remember, you could always set the
number of columns. Here is part of my .emacs file for the gnu
version of emacs for f77 code:
(setq fortran-mode-hook
'(lambda () (set-screen-width 73) ;;to flag long line
(auto-fill-mode 0) ;;turn off auto-fill
mode.
(set-fill-column 67))) ;;for filling comments
Now, for f90 code, emacs seems to pretty much do the right thing for
132-column windows without any customization.
I'm trying to remember a text editor that I've used that really was
limited to 80-column records. I can't think of one. EDT, vi,
emacs, vim, I think even wylbur on IBM machines would edit longer
lines.
$.02 -Ron Shepard
| |
| Scott Moore 2005-08-11, 10:01 pm |
| e p chandler wrote:
> crash_zero wrote:
>
>
>
>
> In the sense that you have data hiding and user defined types, yes. F9x
> may resemble C/C++ more but F9x is *not* C/C++.
>
>
>
>
> It is amazing what you can do in modern Fortran. In addition, pointers
> and some of the other new features are somewhat less dangerous than
> they are in C/C++.
But still dangerous. It was irresponsible to introduce them into Fortran.
Being reference secure was one of Fortran's major advantages, which is
now being destroyed.
| |
| Jan Vorbrüggen 2005-08-12, 4:02 am |
| Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: individual.net 8GgQLbjp1lDqdBesjgqqEQOovN/OXFM3iaJxKpofYo/mWCPSCI
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: de-DE, de, en-us, en
In-Reply-To: <ddgmbb$k85$1@news1nwk.SFbay.Sun.COM>
Xref: number1.nntp.dca.giganews.com comp.lang.fortran:135715
> But still dangerous. It was irresponsible to introduce them into Fortran.
> Being reference secure was one of Fortran's major advantages, which is
> now being destroyed.
'scuse me? So all those program crashes and, worse, silent data corruptions
caused by using illegal array indices into arrays in common as a substitute
to pointers in the programs written in F77 and previous are figments of my
imagination?
If the blade guard makes it impossible to execute a required part of the
work, users will remove it, no matter how good the designers intentions were.
Better to provide a method to get it out of the way just for those few jobs
where this is an absolute requirement, and keep it in place otherwise. The
ALLOCATABLE TR was a big step in this direction, but there remain cases
where one does actually need to use pointers, and Fortran pointers are still
less dangerous than C pointers.
Jan
| |
| Bart Vandewoestyne 2005-08-12, 5:03 pm |
| On 2005-08-07, crash_zero <choo.adrian@gmail.com> wrote:
> Well,
>
> Fortran may be an "old language", but the fact that younger programmers
> like me are still using it means that it is still alive and kicking.
> *smile*
I totally agree! I am 27 years old myself, and I `took the risk' of
starting to dig into Fortran for the code I'm developing for my PhD.
Being used to all the Java stuff they taught me as the university, the
switch to Fortran was quite big and took some time to get used to, but
after about 1.5 years I feel very comfortable with fortran for my
numerics.
The big misunderstanding of other (and often young) programmers (including
collegues of mine) is that when you speak of 'Fortran' they immediately
associate that word with old FORTRAN77 code. I think it is up to `the
more informed Fortran users' ;-) to let those people know that Fortran
indeed has evolved.
I have already been thinking about giving a seminar here at our
department, just to inform people about the current f90/95 standard and
about the new features that can be expected when a fully F2003 compliant
Fortran compiler starts to exist. I am quite sure that -even here at our
*computer science* department- a large part my collegues doens't know
there is something like a difference in Fortran standards, and does not
know about the features they can use in Fortran 90/95 or can expect in
the upcoming F2003 compilers...
Now that I think of it... yes... it really might be a good idea to give
that seminar :-)
Regards,
Bart
--
"Share what you know. Learn what you don't."
| |
| Dr Ivan D. Reid 2005-08-13, 5:01 pm |
| On Fri, 12 Aug 2005 16:09:04 +0000 (UTC),
Bart Vandewoestyne <MyFirstName.MyLastName@telenet.be>
wrote in <1123859344.166288@seven.kulnet.kuleuven.ac.be>:
> The big misunderstanding of other (and often young) programmers (including
> collegues of mine) is that when you speak of 'Fortran' they immediately
> associate that word with old FORTRAN77 code. I think it is up to `the
> more informed Fortran users' ;-) to let those people know that Fortran
> indeed has evolved.
> Now that I think of it... yes... it really might be a good idea to give
> that seminar :-)
Just Do It! You overestimate your target audience. They don't
associate 'Fortran' with F77 -- they associate it with FORTRAN66 and
FORTRAN-IV!
--
Ivan Reid, Electronic & Computer Engineering, ___ CMS Collaboration,
Brunel University. Ivan.Reid@[brunel.ac.uk|cern.ch] Room 40-1-B12, CERN
KotPT -- "for stupidity above and beyond the call of duty".
| |
| Kevin G. Rhoads 2005-08-16, 5:06 pm |
| >I'm trying to remember a text editor that I've used that really was
>limited to 80-column records.
026
029
(rarely) 129
;-)
| |
| Kevin G. Rhoads 2005-08-16, 5:06 pm |
| >You overestimate your target audience. They don't
>associate 'Fortran' with F77 -- they associate it with FORTRAN66 and
>FORTRAN-IV!
That's because none of them remember FORTRAN-II
| |
| blmblm@myrealbox.com 2005-08-19, 4:18 pm |
| In article <430240E0.547CB541@alum.mit.edu>,
Kevin G. Rhoads <kgrhoads@alum.mit.edu> wrote:
>
>026
>029
>(rarely) 129
>;-)
";-)" indeed. What I wonder is how many people are thinking "026!
those were [not] the days!" versus those who are thinking "say WHAT?!"
(I'm in the former group, though I admit I don't quite remember
the differences among 026, 029, and 129, except that the 129 was
in some way "more programmable" -- though exactly what that means I
don't remember.)
--
| B. L. Massingill
| ObDisclaimer: I don't speak for my employers; they return the favor.
| |
|
|
David Flower wrote in message
<1123355350.528582.288900@f14g2000cwb.googlegroups.com>...
>There is no doubt that F90 includes some goodies that are of immense
>value. However, this is at a cost, as F90 compilers are not as bug free
>as F77 ones, and given the size of the language, may never be.
>
>Personallyly, I avoid extensions unless I really need them. What I have
>used are:
>
>- Various intrinsics
>- INTERFACE
>
>I would avoid free-format code like the plague.
That is a foolish recommendation, as the use of
free format source catches errors that slip though
in FORTRAN 77.
That - along with IMPLICIT NONE - help considerably
in picking up typos.
| |
|
|
crash_zero wrote in message
<1123321532.925931.120340@g44g2000cwa.googlegroups.com>...
>Hi,
>
>I'm a Fortran 77 programmer. I haven't switched over to Fortran 90/95.
>I would like to hear the views of those who switched over to Fortran
>90/95.
>
>- How different is it from Fortran 77?
A lot and a little.
If you restrict yourself to the same constructs as you use
in FORTRAN 77, advantages exist at the coding level -
* free source form (that is, blanks are significant). This helps
helps to avoid typing errors.
* use IMPLICIT NONE catches simple errors including
misspelled names, inadvertent use of 0 for O and vice versa., etc
If you use the new constructs of Fortran 95, you will have
* dynamic arrays (better than adjustable dimensions)
* better and more portable specifications of kinds (precisions)
* modules
* generic procedures
* and much more
* and you can avoid some ot the obsolescent F77 constructs
You can use as few or as many of the new F95 features that
you feel comfortable with, because F95 is almost a superset of F77.
>- What are the advantages of it over Fortran 77?
>- How stable is Fortran 90/95 compared to Fortran 77?
>
>Thanks
| |
| jussij@zeusedit.com 2005-08-21, 6:57 pm |
| > You might like to try a folding editor[1] for the latter,
> such as the Zeus editor that was recently announced in this
> group.
Just to add to Ivan posting, Zeus can indeed fold Fortran ".for"
files. The fold points are provided for these keywords:
do
else
elsewhere
function
if
interface
module
procedure
program
select
subroutine
type
where
and their matching "end" keyword.
If anyone finds a problems with the current folding implementation,
a bug report can be posted to this link:
http://www.zeusedit.com/forum/viewforum.php?f=8
and all effort will be made the problem.
Note: Zeus is shareware (45 free trial).
Jussi Jumppanen
Author: Zeus for Windows
|
|
|
|
|