You have to remember why globals are considered "evil" today: 1) bad for modularity 2) bad if you have threads 3) bad for debugging (referential transparency et

You have to remember why globals are considered "evil" today: 1) bad for modularity 2) bad if you have threads 3) bad for debugging (referential transparency etc.) In the seventies, I think that threads simply didn't exist. As for modularity, it is pretty clear from the rest of the book that Moore doesn't consider it as something important. He prefers high performance, ad hoc code. This made sense given the limited power of CPUs at that time, and this still makes sense in the embedded world, sometimes. Finally, the negative impact of global variables is probably proportional to the size of the program. He is talking about programs that could easily fit in the L1 cache of yesterday's Pentiums (a few dozen of kilobytes max). Furthermore when one programs in Forth, one problem is that you simply can't declare local variables: all you have is two stacks. It often simplifies a lot the functions ("words" in Forth lingo) to "offload" some data into (global) variables. This actually helps with debugging, given that in older systems one had very few debugging tools, because one could interrupt the program and look at the state of those variables in order to guess what's going on.