🚀 go-pugleaf

In article <1990Dec7.195140.3022@arnor.uucp> artg@arnor.uucp writes:
>
>Many good, practical reasons argue against global variables.
>Modules (objects or processes) sharing variables are constrained to
>run on the same machine unless the distributed system running
>under them implements shared memory.    So sharing variables
>can prevent a distributed program from being reconfigured, and
>can make it impossible to do process migration.  Sharing, and unconstrained
>module interface design, explains why computer software functionality
>and construction has progressed so slowly.

I've explained to many programmers my view that global variables are to
data structures what the GOTO is to control structures (worse, in many
ways, if you ask me--I'll use the occasional GOTO, but my references to
global variables tend to be to someone else's, not to any that I invented.)
A lot of people give me this response: that they only use them when
"necessary".  When I go look at their code, there are always tons of
gratuitous global variables.

When is a global necessary?  I think the answer is: almost never.
I have used them when I needed to speed up code, but in almost every
case, I was speeding up code that I hadn't written, and that used
algorithms and data structures that I wouldn't have chosen.  I never
liked what I was doing to the code in the process.

To me, the worst part of unconstrained use of global variables is the
uncertainty: when reading the code, you find yourself looking at something
that has no readily-available context or meaning; you don't know what is
going to change it and when.

Not only does variable-sharing "prevent a distributed program from being
reconfigured", I've found that it can prevent ANY significant program from
being reconfigured!  It has probably prevented a great many programs from
being understood by anyone except the original programmer.  Forget about
GOTO-phobia, how about "`extern' variables considered harmful?
----
Michael Turner
turner@tis.llnl.gov