From: m_b_metcalf on
On May 7, 12:29 am, Allamarein <matteo.diplom...(a)gmail.com> wrote:

>Where can I download relative documentation?

A place to start is http://en.wikipedia.org/wiki/Fortran_language_features
but you'll need more later.

Regards,

Mike Metcalf


From: A Watcher on
jfh wrote:
> On May 7, 8:46 am, Allamarein <matteo.diplom...(a)gmail.com> wrote:
>> I'm a newbie in Fortran 77. It's possible to find a manual with built-
>> in statements and that show this language, without digressing too
>> much?
>
> The best book I know on that is "Effective Fortran 77" by Michael
> Metcalf, Oxford 1990, but it has long been out of print because that
> Fortran dialect has been out of date for 20 years, so you may well
> find it only in libraries and on the shelves of oldies. But why is a
> newbie doing f77 anyway instead of f95 or f2003?
>
> -- John Harper

F77 is pretty easy to understand and learn if you have any kind of math
aptitude. The advanced features and syntax of f90 and up obscure the
language, in my opinion. I think it would be wise to learn the basics
before going on to the esoteric stuff, especially if you don't already
know some other programming languages.

I've been writing fortran code since 1968.
From: Richard Maine on
A Watcher <stocksami(a)earthlink.net> wrote:

> F77 is pretty easy to understand and learn if you have any kind of math
> aptitude. The advanced features and syntax of f90 and up obscure the
> language, in my opinion. I think it would be wise to learn the basics
> before going on to the esoteric stuff, especially if you don't already
> know some other programming languages.

I have the opposite opinion. F90 need not be esoteric. Several of its
features make life a lot simpler. Start with things such as not having
to worry about counting columns; I don't know how many people have been
confused and asked here about problems relating to fixed source form,
but it is a lot. If you are already an f77 programmer, there is
*NOTHING* that you absolutely have to learn new in order to use f90. You
are also already an f90 programmer.

You can learn new features as they become useful to you. Some of them
become useful pretty much right away. Others you might never have to
learn. Conversely, some f77 features you never have to learn. COMMON is
actually quite messy if you really learn all the details of it (not to
speak of being very error prone). I'd recommend that new users not
bother with even learning COMMON until they have to deal with legacy
programs that use it. If you think COMMON is simple (as I see many
people claim), that's almost certainly because you are talking about
only the particular way you use it instead of about the actual rules
(and the odd behavior you get from trivial typos - putting a comma in
column 73 is one of my "favorites" in terms of making a mess of COMMON).

If you handicap yourself by sticking to f77, then it is all but
guaranteed that you will soon be back asking about how to do something
that turns out to be one of the new features of f90. It happens quite
regularly. Someone insists that f77 does everything they need. Then the
next week they are asking how one does, for example, dynamic allocation,
or any of a host of other things.

> I've been writing fortran code since 1968.

Same here; exactly the same year.

--
Richard Maine | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle | -- Mark Twain
From: glen herrmannsfeldt on
Richard Maine <nospam(a)see.signature> wrote:
> A Watcher <stocksami(a)earthlink.net> wrote:

>> F77 is pretty easy to understand and learn if you have any kind of math
>> aptitude. The advanced features and syntax of f90 and up obscure the
>> language, in my opinion. I think it would be wise to learn the basics
>> before going on to the esoteric stuff, especially if you don't already
>> know some other programming languages.

> I have the opposite opinion. F90 need not be esoteric. Several of its
> features make life a lot simpler. Start with things such as not having
> to worry about counting columns; I don't know how many people have been
> confused and asked here about problems relating to fixed source form,
> but it is a lot. If you are already an f77 programmer, there is
> *NOTHING* that you absolutely have to learn new in order to use f90. You
> are also already an f90 programmer.

But the rules aren't that hard to learn. I do agree that it was
much easier getting things into 72 columns on punched cards than
it is on a screen, though. By the time you get all the rules for
free form continuation down, though, I think it is harder to learn
than the rules for fixed form. Actually following the rules is a
separate question.

Well, first you need to learn an editor to get programs into your
computer. If that is WORD or NOTEPAD, then it is likely especially
hard to get the columns right. Current vim gives you the row and
column at the bottom of the screen.

> You can learn new features as they become useful to you. Some of them
> become useful pretty much right away. Others you might never have to
> learn. Conversely, some f77 features you never have to learn. COMMON is
> actually quite messy if you really learn all the details of it (not to
> speak of being very error prone). I'd recommend that new users not
> bother with even learning COMMON until they have to deal with legacy
> programs that use it. If you think COMMON is simple (as I see many
> people claim), that's almost certainly because you are talking about
> only the particular way you use it instead of about the actual rules
> (and the odd behavior you get from trivial typos - putting a comma in
> column 73 is one of my "favorites" in terms of making a mess of COMMON).

I probably agree with this. But I believe in terms of the previous
post, for simple problems often you don't need much of the added
complication of F90 and later. I believe the suggestion was for
one learning as a first programming language. How do you know
which features to learn first and which later?

Now, if you have a class that goes through features in an
appropriate order, such that you learn the easier to use ones
first, then maybe it isn't a problem. But if you pick up a
Fortran 2003 reference manual and start reading, you will get
confused faster than from a Fortran 77 reference manual.

> If you handicap yourself by sticking to f77, then it is all but
> guaranteed that you will soon be back asking about how to do something
> that turns out to be one of the new features of f90. It happens quite
> regularly. Someone insists that f77 does everything they need. Then the
> next week they are asking how one does, for example, dynamic allocation,
> or any of a host of other things.

If one is just starting, usually with smaller programs, there are
many things to learn before you get to many of those features.
But yes there are some things missing in F77 that are not easy
to get around, as you say dynamic allocation likely one of them.

>> I've been writing fortran code since 1968.

> Same here; exactly the same year.

May or June 1972 for me. The IBM S/360 Fortran Reference manual
was my 8th grade graduation present, just before going on a month
long vacation by car. I did read some of it along the way, but
not as much as I had thought I would. It was the rest of the
summer when I could actually try running programs and see
the results.

-- glen

From: Richard Maine on
glen herrmannsfeldt <gah(a)ugcs.caltech.edu> wrote:

> Richard Maine <nospam(a)see.signature> wrote:

> > F90 need not be esoteric. Several of its
> > features make life a lot simpler. Start with things such as not having
> > to worry about counting columns; I don't know how many people have been
> > confused and asked here about problems relating to fixed source form,
> > but it is a lot.
>
> But the rules aren't that hard to learn.
> much easier getting things into 72 columns on punched cards than
> it is on a screen, though. By the time you get all the rules for
> free form continuation down, though, I think it is harder to learn
> than the rules for fixed form. Actually following the rules is a
> separate question.

I disagree that it is a separate question. When introducing a new
programmer to the language, if he gets it wrong, then he gets it wrong
and it really doesn't matter whether he didn't know the rules or
accidentally failed to follow them. I'm an engineer. Part of that is
caring about getting the results right instead of about being able to
say that there was some excuse for why they were wrong.

I also disagree that the rules for fixed source form are simpler. Don't
forget that blank insignificance comes with fixed source form, for one.
And as far as continuation rules, even experts here regularly quote the
fixed source ones incorrectly (it is quite common for people to forget
that 0 is a special character). When there are trailing blanks on a
continued line, you won't even find the experts (or compilers) always
agreeing on the exact interpretation. It gets off into subtle points
relating to the representation of source code.

But continuation rules in free source form are in the category of things
you don't need to learn at first. Don't worry about them until you need
them. And even once you need them, just learn the simple case
(non-character context), as that is all you will likely need for a
*LONG* time. With free source form, you can just start writing your
first codes without even paying attention to source form questions other
than the question about how to tell the compiler you are using free
source form.

WIth fixed source form, you can't do that. You *HAVE* to learn at least
a few of the rules about getting things in the right columns. You can't
write even the most trivial of programs without tripping over that...
and trip over it is what an awful lot of people do.

Furthermore, fixed source form makes for bugs that are very hard to see
and diagnose. Reference my prior comment about having a comma in column
73. Add in the blank insignificance that comes with fixed source form.
Also add in the implicit typing that you are stuck with in f77 (recall
that the question was about sticking with f77; you can half fake
implicit none in f77, but you can't do it right). This makes for bugs
that often are quite hard to find.

I predict mention of various tools (such as the old-style reference
maps) that could in theory help find such bugs. But I'll dismiss that
along with the mention of how much easier fixed source form was on
punched cards. I'm much more interested in what actually happens to
people today. One of the things that actually happens with fair
regularity is that people using fixed source form get bitten by such
things. I know this because they regularly post the questions here.

--
Richard Maine | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle | -- Mark Twain
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5 6 7 8 9 10
Prev: proble in common
Next: GNU f90 read() run time error