Numbers and truth values

[Alex Martelli]

Beliavsky <beliavsky at aol.com> wrote:
    ...
> > If this has changed in the Fortran 1990 standard or later, then I can
> > only say I'm happy I stopped using Fortran heavily before such standards
> > became widespread in commonly available compilers -- by the late '90s,
> > when I was still using _some_Fortran, it was Fortran '77, as that was
> > the version that was widely available and well optimized.
> 
> I don't think the official status of such has changed -- it's still
> illegal to change a constant and the compiler is still not required to
> catch the error

Oh good -- I'm happy to hear that the original spirit IS still around.

> -- but compilers may be more likely to reject
> such code as before, helping programmers spot errors. IMO that's a
> good thing.

In general, as an engineer, I think that making tools more complicated
so that a single tool can serve multiple purposes is not necessarily a
win.  I do not want one pair of shoes that are designed to be excellent
for running AND for dancing AND for mountain hiking: I'd much rather
have three specialized pairs of shoes instead, one pair for running, one
for dancing, one for hiking.

Similarly, I'd rather have one tool to take presumably-correct sources
and generate great machine code from them, and separate tools to nitpick
the bejeezus out of the sources to make really sure they ARE indeed
perfectly correct from all viewpoints.  Two (or more) simple, fully
specialized tools make for a better toolbox than one complex,
multi-purpose one.  Few except engineers seem to understand this.

> When is no longer using a language, one has the luxury of thinking
> about it in an ideological rather than practical manner.

I thought about Fortran in exactly the same way when I was doing most of
my coding in it, and also using it to teach "numerical computing" in
university.  Most errors came (and still come) from people who just
don't understand the underlying mathematical nature and realities of
floating point (and numerical computations more generally), and I never
expected a compiler to magically start warning the user about "you're
using a very badly conditioned algorithm for this computation":-), the
one thing that would have really saved me a lot of time in my advisory
and teaching roles.  Exactly the same problems keep surfacing in
programs in Python and any other language too, barely veiled by today's
growing propensity for double-precision and wider-yet floats; offering a
rich library of functions is NOT a viable replacement for understanding
and approaching computation correctly (users will just call extremely
general library functions, rather than understand their problem's
specific "geometries" and address them appropriately).

(Let me offer one more plug for my favorite "book about programming
without a single line of code in it", Foreman Acton's "Real computing
made real", now out in a wonderfully cheap Dover edition: Acton makes
this case better than I've ever seen it made elsewhere, and offers many
excellent examples of how numerical computation SHOULD be done).


Alex