4 ms·

Now I'm flashing back to a system that passed important configuration via globals, so to call functions that relied on these globals, you had to carefully make

Now I'm flashing back to a system that passed important configuration via globals, so to call functions that relied on these globals, you had to carefully make sure that the global environment was in the right state before you called certain functions. It was awful.

mettamage 7y ago
Sounds like OpenGL or HTML canvas to me, if I'd had to make a contemporary comparison with what I know. Fun times, having bugs with OpenGL because of this. Oh, fun times :-D
- mrfredward 7y ago
  Oh man. It's not as bad now with shaders, but I remember how horrible learning fixed pipeline OpenGL was. You'd try to write some simple code, the result would be a black screen, and you'd just keep adding glEnable/glDisable calls to your code over and over until you figure what invisible piece of global state was ruining your day.
  - mettamage 7y ago
    Oh man, I'm not sure if I'm imagining it, but that sounds like me in 2012.
all2 7y ago
This sounds like a system we use at work. Go take a look at Tera Term. In the realm of programming languages it... works. It gets the job done for simple tasks. If you want to do anything complex, watch out.
jetcata 7y ago
I’ve worked on similar systems, never again. God objects are something that should be avoided so that code is readable and maintainable.
- roywiggins 7y ago
  One common pattern in this system was that you'd first save the current environment, run the special "environment preparation" function, then the real function, and then write back the saved environment over the modified one, so that you didn't leave the environment changed after you returned. Unless of course you meant to change it. This was sometimes documented, you'd write in which globals a function expected and which it modified into a docstring. This was probably only in the top ten of the problems that this thing had, but I do remember it vividly. Making any change was like pulling out a Jenga block and replacing it without toppling the tower.
  - eru 7y ago
    > One common pattern in this system was that you'd first save the current environment, run the special "environment preparation" function, then the real function, and then write back the saved environment over the modified one, so that you didn't leave the environment changed after you returned. That sounds exactly like dynamic scoping.
closed 7y ago
This reminds me of a lot of Matlab code I had to read in grad school :/.
code_duck 7y ago
Aha, I see you're familiar with my first programs in PHP 4.
matheusmoreira 7y ago
Locales in C are an example of this. https://github.com/mpv-player/mpv/commit/1e70e82baa9193f6f027338b0fab0f5078971fbe https://github.com/mpv-player/mpv/commit/1e70e82baa9193f6f02... > The locale (via setlocale()) is global state, and global state is not a reasonable way to do anything. > It will break libraries, or well modularized code. > (The latter would be forced to strictly guard all entrypoints set set/restore locales, assuming a single threaded world.) > On top of that, setting a locale randomly changes the semantics of a bunch of standard functions. > If a function respects locale, you suddenly can't rely on it to behave the same on all systems.

mettamage 7y ago

Sounds like OpenGL or HTML canvas to me, if I'd had to make a contemporary comparison with what I know. Fun times, having bugs with OpenGL because of this. Oh, fun times :-D

mrfredward 7y ago
Oh man. It's not as bad now with shaders, but I remember how horrible learning fixed pipeline OpenGL was. You'd try to write some simple code, the result would be a black screen, and you'd just keep adding glEnable/glDisable calls to your code over and over until you figure what invisible piece of global state was ruining your day.
- mettamage 7y ago
  Oh man, I'm not sure if I'm imagining it, but that sounds like me in 2012.

all2 7y ago

This sounds like a system we use at work. Go take a look at Tera Term. In the realm of programming languages it... works. It gets the job done for simple tasks. If you want to do anything complex, watch out.

jetcata 7y ago

I’ve worked on similar systems, never again. God objects are something that should be avoided so that code is readable and maintainable.

roywiggins 7y ago
One common pattern in this system was that you'd first save the current environment, run the special "environment preparation" function, then the real function, and then write back the saved environment over the modified one, so that you didn't leave the environment changed after you returned. Unless of course you meant to change it. This was sometimes documented, you'd write in which globals a function expected and which it modified into a docstring. This was probably only in the top ten of the problems that this thing had, but I do remember it vividly. Making any change was like pulling out a Jenga block and replacing it without toppling the tower.
- eru 7y ago
  > One common pattern in this system was that you'd first save the current environment, run the special "environment preparation" function, then the real function, and then write back the saved environment over the modified one, so that you didn't leave the environment changed after you returned. That sounds exactly like dynamic scoping.

closed 7y ago

This reminds me of a lot of Matlab code I had to read in grad school :/.

code_duck 7y ago

Aha, I see you're familiar with my first programs in PHP 4.

matheusmoreira 7y ago

Locales in C are an example of this. https://github.com/mpv-player/mpv/commit/1e70e82baa9193f6f027338b0fab0f5078971fbe https://github.com/mpv-player/mpv/commit/1e70e82baa9193f6f02... > The locale (via setlocale()) is global state, and global state is not a reasonable way to do anything. > It will break libraries, or well modularized code. > (The latter would be forced to strictly guard all entrypoints set set/restore locales, assuming a single threaded world.) > On top of that, setting a locale randomly changes the semantics of a bunch of standard functions. > If a function respects locale, you suddenly can't rely on it to behave the same on all systems.