5 ms·

Unlearning Object Programming might include discussion of the legitimate uses of global variables, and how Singletons are just obfuscated and inconvenient globa

Unlearning Object Programming might include discussion of the legitimate uses of global variables, and how Singletons are just obfuscated and inconvenient globals.

princeb 11y ago
think I did "unlearning object oriented programming" in university - it was called "programming in matlab with other applied mathematicians"
- jacobolus 11y ago
  That’s more like “being reduced to tears” than “unlearning” per se.
crdoconnor 11y ago
>discussion of the legitimate uses of global variables Short course, that one.
- Tloewald 11y ago
  Module names are, effectively, global variables. The reason global namespace shouldn't be polluted is that it's so damn useful. Not using it for anything is like never driving your car to avoid wearing out your tires.
  - crdoconnor 11y ago
    >The reason global namespace shouldn't be polluted is that it's so damn useful. No, the reason is because the more interacting components you stick on it, the harder your code becomes to reason about. It's more a restatement of the notion that software should be loosely coupled.
    - Tloewald 11y ago
      You realize that there's a war between people who write static code analysis software and "software architects", the former trying to detect global state buried in object hierarchies and the latter disguising global state as something else in the interest of "decoupling" things that need coupling. Every class property is effectively global state (has the printer been initialized? what objects of this type have been created?) If you don't think class properties are useful... Globals are a tool. Used badly they're terrible, but so are design patterns. For a long time many very useful pieces of software ran very well with lots of global state, but the egregious cases of misuse spoiled it for everyone. The problem with the "never use globals" approach is that if you need them, disguising them as something other than what they are makes things FAR, FAR more difficult to reason about.
      - jschwartzi 11y ago
        I agree. For example, the OO project that I'm working with at my job has a bunch of global state, but it's hidden in references to structs and pops up in a million different places throughout the system. It's still spaghetti code but it's spaghetti code with namespaces. The point of OO isn't to separate or eliminate global state itself. At some level everything is global(agreeing with you). The purpose of OO is to establish a strict separation of concerns. The idea is to say "We need a component of our system to deal with the Blargle operation," and then determining what elements of the system the Blargle functionality actually needs in order to be performed, then making sure that Blargle is aware of only those parts of the system. Additionally it means that system components that existed before Blargle was implemented are still blissfully unaware that Blargle is a thing now. All of the features of OO languages, like encapsulation, inheritance, design patterns, and messaging are there to allow you to write software where unrelated components can be implemented and reasoned about entirely in isolation. You can do this in any computer language, and systems like the Linux kernel are good examples of separation of concerns that don't happen to use an OO language. You can also do this with global variables, but it takes more discipline.
    - hvidgaard 11y ago
      There is some state that is global. Current user for instance, it is used globally, so why create a complex way of passing it around instead of just making it global?

Unlearning Object Programming might include discussion of the legitimate uses of global variables, and how Singletons are just obfuscated and inconvenient globals.

princeb 11y ago

think I did "unlearning object oriented programming" in university - it was called "programming in matlab with other applied mathematicians"

jacobolus 11y ago
That’s more like “being reduced to tears” than “unlearning” per se.

crdoconnor 11y ago

>discussion of the legitimate uses of global variables Short course, that one.

Tloewald 11y ago
Module names are, effectively, global variables. The reason global namespace shouldn't be polluted is that it's so damn useful. Not using it for anything is like never driving your car to avoid wearing out your tires.
- crdoconnor 11y ago
  >The reason global namespace shouldn't be polluted is that it's so damn useful. No, the reason is because the more interacting components you stick on it, the harder your code becomes to reason about. It's more a restatement of the notion that software should be loosely coupled.
  - Tloewald 11y ago
    You realize that there's a war between people who write static code analysis software and "software architects", the former trying to detect global state buried in object hierarchies and the latter disguising global state as something else in the interest of "decoupling" things that need coupling. Every class property is effectively global state (has the printer been initialized? what objects of this type have been created?) If you don't think class properties are useful... Globals are a tool. Used badly they're terrible, but so are design patterns. For a long time many very useful pieces of software ran very well with lots of global state, but the egregious cases of misuse spoiled it for everyone. The problem with the "never use globals" approach is that if you need them, disguising them as something other than what they are makes things FAR, FAR more difficult to reason about.
    - jschwartzi 11y ago
      I agree. For example, the OO project that I'm working with at my job has a bunch of global state, but it's hidden in references to structs and pops up in a million different places throughout the system. It's still spaghetti code but it's spaghetti code with namespaces. The point of OO isn't to separate or eliminate global state itself. At some level everything is global(agreeing with you). The purpose of OO is to establish a strict separation of concerns. The idea is to say "We need a component of our system to deal with the Blargle operation," and then determining what elements of the system the Blargle functionality actually needs in order to be performed, then making sure that Blargle is aware of only those parts of the system. Additionally it means that system components that existed before Blargle was implemented are still blissfully unaware that Blargle is a thing now. All of the features of OO languages, like encapsulation, inheritance, design patterns, and messaging are there to allow you to write software where unrelated components can be implemented and reasoned about entirely in isolation. You can do this in any computer language, and systems like the Linux kernel are good examples of separation of concerns that don't happen to use an OO language. You can also do this with global variables, but it takes more discipline.
  - hvidgaard 11y ago
    There is some state that is global. Current user for instance, it is used globally, so why create a complex way of passing it around instead of just making it global?