Structured Fortran - was Re: Self modifying code, lambda calculus

[Chuck Guzis]

On 09/23/2015 01:39 AM, ANDY HOLT wrote:
>> From: "Chuck Guzis" <cclist at sydex.com>
>
> …
>> After all, languages are supposed to expose features of the
>> underlying machine to the programmer.
>
> Many believe that the purpose of languages is to HIDE (abstract) the
> underlying machine.

And I take your point.  At least on supercomputers, it has pretty much
been the pattern that vast amounts of code are spent on automatic
optimization.  There seems to be a situation where computers implement a
set of features that allow for higher performance, but then the HLL has
to have some way to express the use of these features.  SIMD
instructions can be very difficult to abstract.

Initially, it's usually done through a subroutine/function library, then
incorporated into the code generation and optimization.  Then, the
language committee haggles and comes up with language structures.

Take F90, for example.  One of the major focii of the effort was to
incorporate vector extensions into the language.  But how to cover the
most ground and yet come up with something that a non-vector machine can
do justice to.  Whatever you come up with, it must be intelligible to
humans (recall that the standard has a broad definition of "computer",
which includes humans).   Whatever the new extensions do, they must also
not break the syntax and meaning of the already existing base language.
   So you have to have language features to define vectors of varying
shapes, operations of various strides, control structures (e.g. sparse
vectors, control vectors, etc.).  This can engender some furious
battles.  I recall that IBM threatened to withdraw from X3J3 if its
Vectran extensions were not implemented.

Pointers were a hot topic in F90.  There was a contingent who fiercely
opposed the idea, as it can make automatic optimization very
difficult--and it's equally difficult to see why it's necessary, as
Fortran has survived for decades without them.

And there were the problems that someone always had a neat hardware
feature that no one else had who wanted a special language feature in
the standard.

The focus of FORTRAN has pretty much always been high performance
numerical calculation.  It can be used for other things, as can any
other language, but even Wirth confessed that FORTRAN code consistently
outran his Pascal on numerical problems.

But the problem with any language, is that the more one adds to the
language, the less comprehensible that language can become.  C++
certainly has taken this route, as has Fortran. F2000 is so far removed
from the classical simplicity of F66, that I wouldn't be tempted to use
it today, unless it was essential to my job.  I know how to write C++
fairly well, but find myself relapsing to C for simple programs.

Sometimes more isn't better.

--Chuck