Numbers and truth values

[Alex Martelli]

John Nagle <nagle at animats.com> wrote:
   ...
>      I'd have to consider that a bug.
> 
>      Some very early FORTRAN compilers allowed you to redefine
> integer constants:
> 
>       
>       CALL SET(25,99)
>       WRITE (6,100) 25
>      100 FORMAT(I6)
> 
>       SUBROUTINE SET(IVAR, INEWVAL)
>       IVAR = INEWVAL
> 
> would print
> 
>      99
> 
>      It was generally agreed by 1970 or so that this was a bad idea,
> and was taken out of the language.

It was still perfectly legal in the Fortran 1977 standard for a compiler
to cause this effect, because the Fortran source you quote has
*undefined behavior* -- the compiler doesn't have to diagnose this error
and can cause any effects as a consequence.

The point of Fortran is to let the compiler generate the fastest code it
can, NOT to "tenderly hold your hand" lest scary bugs disturb your
blessed and dreamy innocence.

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.

Python is not particularly focused on coddling the programmer lest he or
she (horrors!) make a mistake, either; rather, it embodies well 4 of the
5 principles that make up the "Spirit of C" according to the Preface to
C's ISO Standard -- "trust the programmer", "don't stop the programmer
from doing what needs to be done", "keep the language small and simple"
(the 4th one, "offer only one way to perform an operation", is not
germane here).  Making the language more complicated (e.g., with more
reserved words) because you _don't_ trust the programmer and badly wants
to stop him/her from doing something is not well consistent with these
principles.  Maybe somebody assigning a value to True or False is a
common error, but much of my livelihood over the last 10 years has been
about mentoring/coaching programmers in Python, and that's one error I
have *NEVER* observed, so I'd need a lot of empirical evidence to
convince me it's worth adding two more reserved words to Python's
reasonably short list (I feel much the same way about None, by the way).
pychecker, pylint, and friends, are a much better way to detect and warn
about all sort of anomalies of this kind.


Alex