Fortran 77 Manual for beginners
in [Fortran]
|
Prev: proble in common
Next: GNU f90 read() run time error
From: Craig Powers on 7 May 2010 18:58 A Watcher wrote: > 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. The following F90 and beyond features are pretty much essential to writing easy-to-understand and easy-to-debug code: * Lower case characters * Identifiers longer than six characters * Modules for global data * IMPLICIT NONE In a larger code, the following additional features are pretty much essential to writing good code: * Allocatable variables (necessary for compile-once-run-many code) * Modules for interface checking on routines None of that is "esoteric", especially if you already have some exposure to other languages, and I've never found any of it to "obscure the language" either.
From: glen herrmannsfeldt on 7 May 2010 19:01 Richard Maine <nospam(a)see.signature> wrote: (snip, I wrote) >> 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. (snip on separate question) > 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). I even knew it was special the only time it happened to me. I forgot that the keypunch control card puts a numeric shift default on column 6. If I still remember it, 0 is shift /. > 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. And trailing blanks in a character context in free form? > 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), Yes, it is character context that I was thinking about when I said that the rules were harder to learn. Without that, I would agree that free form is easier. > 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. See and diagnose is different than learning the rules. I would especially say not to edit with a variable width font and fixed 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. An editor that makes column 73 easy to see would help a lot. I believe that there are some that color differently after 72. > 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. -- glen
From: Sjouke Burry on 7 May 2010 19:49 glen herrmannsfeldt wrote: > 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 cut > > 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 checked out notepad? check this screengrab, notepad always had a nice line/col readout at the bottom, nice for fortran. > http://home.planet.nl/~burry004/grab.jpg
From: Jim Xia on 7 May 2010 23:42 > 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 would have agreed with these opinions 15 years ago. As a physicist, all I cared were algorithms and computations expressed mathmetically. I even canceled an enrollment of a course on Scientific Computations using Fortran 90. But then after I've moved across multiple fields and different languages, I view these opinions as near-sighted and narrow minded. True, if you want to write a toy program in one afternoon, F77 can pretty much suffice what you need. But from a serious software engineering point of view, F77 or F90/95 are handicaped. Most Fortran programs I've seen are brittle and hard to modify or integrate with other components. This was partially caused by the lack of facility in these old languages. But more importantly these softwares were mostly written by scientists/engineers who normally lacked formal trainings in software engineering. As I see it, if we don't encourage newcomers to proper learn the principles in software engineers and embrace the new language features that encourge these practices, and keep teaching them how to write old F77/F90 code, I'd say we'll drive them away from Fortran in no time. I've written F77 longer than any other languages. However after real application experiences with C, C++ and Java in a number of fields, my view on Fortran changed dramatically. Coming back to Fortran 7 years ago, I picked up Fortran 2003 and never wrote a F77/F90 code again. I'm looking forward to seeing what F2008 offers me :-) Cheers, Jim
From: glen herrmannsfeldt on 8 May 2010 01:07
Jim Xia <jimxia(a)hotmail.com> 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 would have agreed with these opinions 15 years ago. As a physicist, > all I cared were algorithms and computations expressed mathmetically. > I even canceled an enrollment of a course on Scientific Computations > using Fortran 90. But then after I've moved across multiple fields > and different languages, I view these opinions as near-sighted and > narrow minded. If you have already used other languages, and are used to thinking in programming language terms, then yes. There are some features in Fortran 2003 that will take some getting used to, but not so bad. But the OP was asking about it as a beginner. Are there any beginner level Fortran 2003 books? Is there (I haven't looked) a "Fortran 2003 for Dummies" yet? > True, if you want to write a toy program in one > afternoon, F77 can pretty much suffice what you need. But from a > serious software engineering point of view, F77 or F90/95 are > handicaped. Most Fortran programs I've seen are brittle and hard to > modify or integrate with other components. This was partially caused > by the lack of facility in these old languages. But more importantly > these softwares were mostly written by scientists/engineers who > normally lacked formal trainings in software engineering. As I see > it, if we don't encourage newcomers to proper learn the principles in > software engineers and embrace the new language features that encourge > these practices, and keep teaching them how to write old F77/F90 code, > I'd say we'll drive them away from Fortran in no time. Some people only need to write small, simple programs. It is, at least, a good way to start. > I've written F77 longer than any other languages. However after real > application experiences with C, C++ and Java in a number of fields, my > view on Fortran changed dramatically. Coming back to Fortran 7 years > ago, I picked up Fortran 2003 and never wrote a F77/F90 code again. > I'm looking forward to seeing what F2008 offers me :-) I don't know how easy C89 is to learn as a first language, but it is, in most ways, a fairly simple language. A small number of different statements and intrinsic types. The Java language (separate from the standard class libraries) is also fairly small, though somewhat more complicated than C89. -- glen |