
Opinion HN: Fortran 90 (F90) doesn't look terrible - monopolemagnet
http://www.cesm.ucar.edu/models/cesm1.2/clm/models/glc/cism/source_glimmer-cism/glint_main.F90
======
monopolemagnet
As opposed to this F66 example:

[http://www.fortran.bcs.org/2005/fortran/img10.html](http://www.fortran.bcs.org/2005/fortran/img10.html)

~~~
GFK_of_xmaspast
I'm not totally sure it's fair to bring up a version of a language that is
twenty four years earlier than the one under discussion. (and for a thought to
make some people feel old, 1966 is closer to 1990 than 1990 is to today).

~~~
monopolemagnet
I am. The point is to show Fortran 90 evolved a lot, which is indeed, a good
thing. Remember, F66 was influenced by Speedcoding which was, in turn,
influenced by assembly, because practical, high-level languages were still in
the learning phase. In other words, early Fortran (e.g., FORTRAN for the IBM
704 on punchcards, which my mom coded in at NUQ) was just barely higher level
than assembly, but later versions improved to gain additional features which
made coding in it less onerous and more productive.

Age is an irrelevant, consumerism fallacy; the _contextual history_ including
the players involved, machines available, problems to solve and lessons
learned, is far more important.

More (salient links from various sources):

Generally

\-
[https://gcc.gnu.org/wiki/GFortranStandards](https://gcc.gnu.org/wiki/GFortranStandards)

F60

\-
[https://www.fortran.com/FortranForTheIBM704.pdf](https://www.fortran.com/FortranForTheIBM704.pdf)

F66

\- ftp://ftp.nag.co.uk/sc22wg5/ARCHIVE/Fortran66.pdf

F77

\-
[http://web.stanford.edu/class/me200c/tutorial_77/](http://web.stanford.edu/class/me200c/tutorial_77/)

\-
[http://www.fortran.com/fortran/F77_std/rjcnf.html](http://www.fortran.com/fortran/F77_std/rjcnf.html)

F90

\-
[http://www.nccs.nasa.gov/tutorials/f90studentnotes.pdf](http://www.nccs.nasa.gov/tutorials/f90studentnotes.pdf)

\- ftp://ftp.nag.co.uk/sc22wg5/N1801-N1850/N1830.pdf

\-
[http://www.j3-fortran.org/doc/year/10/10-007.pdf](http://www.j3-fortran.org/doc/year/10/10-007.pdf)

\- [http://www.fortran90.org/](http://www.fortran90.org/)

F95

\-
[http://www.j3-fortran.org/doc/year/04/04-007.pdf](http://www.j3-fortran.org/doc/year/04/04-007.pdf)

F2003

\-
[http://www.j3-fortran.org/doc/year/04/04-007.pdf](http://www.j3-fortran.org/doc/year/04/04-007.pdf)

F2008

\-
[http://fortranwiki.org/fortran/show/Fortran+2008](http://fortranwiki.org/fortran/show/Fortran+2008)

------
spapin
One problem I find in fortran is that subroutines quickly have a lot of
arguments. In this example, glint have 30ish. I have seen fortran subroutines
in the aerospace industry with more than 100 arguments.

~~~
monopolemagnet
Oh god. Reminds me of simulated processor pipeline stages (VHDL, etc.), which
tend of have a huge amount of state.

I'm no Fortran expert. Were there no composite types (i.e., structures or
tuples) at the time or other reasons to do that (i.e., code testing tools)?

Edit: Last q: Yes, as a vendor extension

[https://gcc.gnu.org/onlinedocs/gfortran/STRUCTURE-and-
RECORD...](https://gcc.gnu.org/onlinedocs/gfortran/STRUCTURE-and-RECORD.html)

