3 ms·

Thus far a lot of what he says seems smart... until I got to this: "Make variables as GLOBAL as possible. Why not? You can save some space and clarify your req

by earlz 12y ago

Thus far a lot of what he says seems smart... until I got to this: "Make variables as GLOBAL as possible. Why not? You can save some space and clarify your requirements. For instance, how many Is, Js and Ks do you need? In most cases a single copy in COMMON would suffice (you have to declare them, remember, and may as well put them in COMMON); you can redefine it locally if you must; and it is of interest that you must." Maybe I'm just misunderstanding him, or it's a difference in languages

Dewie 12y ago
Moore seems to have a very different conceptualization of what good software is compared to the common wisdom.
- astrobe_ 12y ago
  ... of which decade? Dijkstra's considered harmful was published in 1968.
  - Dewie 12y ago
    Of this decade. He still seem to have unconventional opinions on software (maybe not on global variables in particular any more, though).
    - bunderbunder 12y ago
      He does have unconventional opinions on software. Just consider the programming language that eventually grew out of the thoughts laid out in this essay: It's untyped, point-free, syntax-free, and lacks local variables (at least in most versions).
astrobe_ 12y ago
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.
- wtetzner 12y ago
  There's another problem with global variables, though. They make it harder to reason about your program. Who knows which of the functions you're calling are updating which global variables? Of course, as you said, things are a bit different in Forth.

by earlz 12y ago

Dewie 12y ago

Moore seems to have a very different conceptualization of what good software is compared to the common wisdom.

astrobe_ 12y ago
... of which decade? Dijkstra's considered harmful was published in 1968.
- Dewie 12y ago
  Of this decade. He still seem to have unconventional opinions on software (maybe not on global variables in particular any more, though).
  - bunderbunder 12y ago
    He does have unconventional opinions on software. Just consider the programming language that eventually grew out of the thoughts laid out in this essay: It's untyped, point-free, syntax-free, and lacks local variables (at least in most versions).

astrobe_ 12y ago

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.

wtetzner 12y ago
There's another problem with global variables, though. They make it harder to reason about your program. Who knows which of the functions you're calling are updating which global variables? Of course, as you said, things are a bit different in Forth.