[Chicago] Using globals across files

[Robare, Phil]

Jason Rexilius on Tuesday, March 28, 2006 4:01 PM wrote
> globals are not across-the-board bad.. abusing them is 
> bad (which happens often enough for people to get the 
> idea that they are bad) but there are times when a truly 
> global variable (like a counter) is usefull.

This gets back to the old saw that every program has two types of
readers: The compiler and the maintainer.  The compiler does not care
about whether your code is thread safe, whether it is efficient, or
whether it computes what you thought you were computing - as long as it
is syntactically correct it will pass it on to the interpreter.

The things we label as "bad" are the things that start to bite us when
the program gets large, or makes the program hard to change, or makes it
hard to understand.  It was all the way back in February of 1973 the
SIGPLAN Notices published a short article "Global Variables Considered
Harmful" (by W. Wulf & Mary Shaw of Carnegie Mellon) that first publicly
laid out the case against using global variables. (This was a follow up
to Edsger Dikstra's famous '68 letter "Go To Considered Harmful" that
made the case for using the control structures of Algol (do, while, for,
if-block-else-block) in place of Fortran's computed go-to's).  Both of
these papers made their argument based upon the difficulty of
understanding what was happening at some point in the program if you had
to understand what was going on elsewhere.  It is interesting to look
back at that paper (it is available at
http://portal.acm.org/citation.cfm?id=953355 as a pdf) and realize that
what they are proposing became functional programming and object
oriented programming.

So back to the point, a global counter would be considered harmful if
you used it's value to control the flow of the program.  You may not do
it, but it is such a seductive lure to the inexperienced that modern
language design has eschewed such structures.  And modern programmers
(at least in other languages) have discovered the singleton pattern to
evade such strictures.