It's just like saying guns are not the problem.
Perhaps a unicorn doesn't die as soon as you first use a global var. But it has two .45s pointed to it cranium left and right. And at any random moment Danni DeVito will start blasting.
Global variables are not the problem
151–160 of 165 posts
Re: Global variables are not the problem
#152Earlier quoted context omitted.
Only if it's const. Otherwise the data is copied into memory you can write to
Isn’t there a part of the data segment that is writable? Initialized vs uninitialized data segment right?
You're right, I know mutable and read-only are separates, I know I seen gcc and clang put static int and global int in the same page, and I know I heard people say global variables are on the heap thousands of times. I guess I forgot global writable data doesn't necessarily mean heap nor the read-only section of memory
Re: Global variables are not the problem
#153Earlier quoted context omitted.
Right but closing over a state with a function and giving that closure a name seems to quack like a duck to me. Maybe it's just because I'm a scheme guy and we're more upfront about this.
The situation is ugly because there is global state by design. But I don't see why the fact that the closure is stored in a mutable location would be a concern for you. Can you think of any conditions where someone would modify it? I'm not really seeing it, and I don't know what your alternative suggestion is going to be to stop them technically. I can tell you when someone would modify a counter variable - every tim…
I think we're talking past each other here. The issue is that the enclosed state of counter is exposed globally and can be accessed without synchronization. I suppose yes one could also reassign counter to a different function (and you'd need to be aware of that) but my point is that you still need some kind of sync if you're calling counter all over the place, just like you would with a global variable
Re: Global variables are not the problem
#154Earlier quoted context omitted.
These methods existed. The problem was that when you added some code somewhere deep down in layers of layers of business code, you never knew whether the code you'd call would need to access that information or whether it had already previously been set. Hiding state like that is IMHO just a recipe for disaster. Sure, if you just use global state for metrics or something, it may not be a big deal, but to use it for i…
I’m having a difficult time understanding the practical difference between watching an internal state object vs an external one. Surely if you can observe one you can just as easily observe the other, no? Surely if you can mutate a state object and pass it, its state can get mutated equally deep within the codebase no different than a global, no? What am I missing here? To me this just sounds like a discipline issue…
> Surely if you can mutate a state object and pass it, its state can get mutated equally deep within the codebase no different than a global, no?
Yes, that's one reason why shared mutable state should IMHO be kept to a minimum and immutable objects/structs should be preferred.
// this function will implicitly look up the tenant from some global context
fun createUser(username: String, password: String)
fun createUser(username: String, password: String, tenant: Tenant)
The second one is almost impossible to accidentally misuse, the first one can lead to all sorts of weird bugs.
Re: Global variables are not the problem
#155Earlier quoted context omitted.
Yes, you gain testability. If your global state contains something that runs in prod but should not run in a testing environment (e.g. a database connection), your global variable based code is now untestable. Dependency Injection is popular for a very good reason.
This sounds like a design deficiency. If you have something that should only run in testing, perhaps your test harness should set the global variable appropriately, no?
Sure. And a million programmers have all screamed out in horror when they realize that their single test passes, but fails when run as part of the whole suite. Test contamination is a hell paved with global variables.
Re: Global variables are not the problem
#156Global variables are a programming construct, which like other programming constructs is neither bad nor good. Except, due to the takeover of workplaces by the best practices cult, instead of reasoning about tradeoffs on a case by case basis (which is the core of coding and software engineering), we ascribe a sort of morality to programming concepts. For example, global variables have drawbacks, but so does re-writin…
> Except, due to the takeover of workplaces by the best practices cult, instead of reasoning about tradeoffs on a case by case basis (which is the core of coding and software engineering), we ascribe a sort of morality to programming concepts.
You're just strawmanning here. Maybe some of the people who say that global variables should be avoided ("should be avoided" never means "absolutely can't be used ever", btw) are people who have experience working on large projects where the use of implicit state routinely makes code hard to reason about, causes concurrency issues and introduces many opportunities for bugs.
> There's also fewer stuff for say copilot to fill in incorrectly, increasing your ability to use AI.
That argument makes no sense to me. If some piece of code is relying on implicit global state to have been set, why would copilot be any better at figuring that out than if it had to pass the state as an argument, something which is clearly stated in the function signature?
Re: Global variables are not the problem
#157Earlier quoted context omitted.
Depends a bit on the language. A global variable in a language with parallel operation is often a terrible idea. The problem with globals and parallel operations is they are an inherent risk for race conditions that can have wild consequences. In some languages, for example, a parallel write to a field is not guaranteed to be consistent. Let's assume in the above example `counter` was actually represented with 2 byte…
Yes, mixing some concepts in programming is a terrible idea. Perhaps this is also widely unpopular, but it's the parallelism that needs to be treated with care and the additional caution, as often the parallelism itself is the terrible idea. Concurrent code often has unpredictable performance due to cache behavior and NUMA, unpredictable lock contention, and the fact that often there is no measure of whether the bott…
> What most people want from concurrency (like computing the response to independent HTTP requests) can be done by separate processes
OS processes are way too heavyweight for many use cases.
Re: Global variables are not the problem
#158The problem with global variables is that they imply that there's only one of that thing. This assumption - no matter how certain it seems - will inevitably be proven false in any sufficiently long-lived software component.
Re: Global variables are not the problem
#159Earlier quoted context omitted.
> To me this just sounds like a discipline issue rather than a semantic one. Using an explicit parameter obviates the need for discipline since you can mechanically trace where the value was set. In contrast, global values can lead to action at a distance via implicit value changes. For example, if you have two separate functions in the same thread, one can implicitly change a value used by the other if it's thread-l…
I'm sorry I just think we're going in circles. A few posts up I clearly said use encapsulation and then mutate state via known methods. These would be just as traceable in your IDE/debugger. Further, I have also repeatedly mentioned both module-level and thread-level "globals". And I understand how concurrency works. Take care.
> These would be just as traceable in your IDE/debugger.
A debugger can trace a single execution of your program at runtime. It can't statically verify properties of your program.
If you pass state to your functions explicitly instead of looking it up implicitly, even in dynamically typed languages there are linters that can tell you that you've forgot to set some state (and in statically typed languages, it wouldn't even compile).
Re: Global variables are not the problem
#160Earlier quoted context omitted.
This sounds like a design deficiency. If you have something that should only run in testing, perhaps your test harness should set the global variable appropriately, no?
Sure. And a million programmers have all screamed out in horror when they realize that their single test passes, but fails when run as part of the whole suite. Test contamination is a hell paved with global variables.
I can't agree more, I was dying this death a thousand times over at my last job.