50 years of progress in the language


I've been converting a set of old Fortran IV (mainly) programs, to
versions "more understandable" (to me at least).

To be fair, almost every program would compile and run correctly using
an F77 compiler
but the code contained:-
Hollerith (nH-type) text strings for output and comunicating
ASSIGN label TO i structures and associated use thereof:
GO TO i,(L1,L2,L3,,)
All alphabetic text constants were equated to double precision
floats,
Smaller length (1-4) alphabetic test onstant strings were treated as
reals,
All condtional branches used three-way arithmetic IF statements,
There were no logical IF statements,
Almost every do loop shared nested labels where possible
All matrices had the index of faster sequential progress in memory
at the right and not at the left
Conversion between integer variabless and equivalent digit strings
was
done by writing a scratch tape and reading back with another
format.
Every subroutine name shared among the 56 programs had very
different
code associated with the names; some with more, some with fewer
options and error handling, even if the purpose was very similar..

I was extremely surprised at how much work appeared to be necessary to
eliminate the obsolescent code and the enormous complexities of
testing for, and manipulating
characters in any way.

Most I solved (reported) by writing a program to automate much of the
conversion:
indent nests of DO loops for readability; supply a CONTINUE ending to
DO-loops where possible; convert hollerith to apostophe-delimited
strings;
providing sequential re-labeling; note unused labels; report ASIIGN
use.

But comparing the task of programming, between 'then', and now, there
were two
additions to the language that have helped enormously
1) the internal read.
2) the character array and the character string.

The next, in my opinion, would be the IF-THEN-ELSE structrues.

After which point I haven't seen any real advantage to further bells
and whistles.
So 1956 to 1976 was a good 20 years of progress, but the next 30 have
been like new
verisions of any of the "old", first "X" software versions: noow
larger, more complicated, more expensive, larger boxes, but all to do
the same basic job.

It's just a personal refection on my last three months of work, with
the first three in this field, nearly 50 years ago
.

Relevant Pages

  • Re: Character KIND conversion?
    ... One thing I noticed is the lack of a CHARACTER kind conversion function, even though there are such functions for all other intrinsic types, including LOGICAL. ... Which, of course, is only guaranteed to work for characters in the ASCII data set. ... Interestingly, the Fortran-95 ISO-VARYING-STRING standard does define one, for converting between the varying strings and normal fortran strings; it's an overload to the CHARfunction. ...
    (comp.lang.fortran)
  • Re: Ada Interfaces and the Liskov Substitution Principle
    ... Even with strings, you might want to share the strategy for character ... And why should I bother with endianness here? ... Or I just delegate to locale and conversion library that is part of my ...
    (comp.lang.ada)
  • Re: Character KIND conversion?
    ... One thing I noticed is the lack of a CHARACTER kind conversion function, even though there are such functions for all other intrinsic types, including LOGICAL. ... Which, of course, is only guaranteed to work for characters in the ASCII data set. ... for converting between the varying strings and normal fortran strings; it's an overload to the CHARfunction. ...
    (comp.lang.fortran)
  • 47bit to 10 char A,,,Z revisted
    ... I just moded arb255 to do the conversion to the 26 ... The fact is you can't code all binary bit strings ... where you allow only 1 to 10 character in a string. ... and always give a 100,000 char file of A..Z ...
    (sci.crypt)
  • Re: Sets and portability (was) Re: Is ISO Pascal compatible with J&W (original) Pascal ?
    ... strings, the user can control the length by the data they process; ... >> The computer world is more complex than it's ever been (eg Unicode) ... The Pascal `Char' type can be this size (unlike C, ... > Note that ansi->wide conversion is codepage sensitive. ...
    (comp.lang.pascal.misc)