SQL databases are global variables
Yes, and code that mutates them in an unmanaged way should be banned.
What is the managed way in this context?
Global variables are not the problem
81–90 of 165 posts
Re: Global variables are not the problem
#82Global variables (in languages where they otherwise make sense and don't have footguns at initialization and whatnot) have two main problems: 1. They work against local reasoning as you analyze the code 2. The semantic lifetime for a bundle of data is rarely actually the lifetime of the program The second of those is easy to guard against. Just give the bundle of data a name associated with its desired lifetime. If y…
I don't think #1 is necessarily true. Take a common case for a global variable, a metric your app is exposing via prometheus. You have some global variable representing its value. Libraries like to hide the global variable sometimes with cuteness like MetricsRegistey.get_metric("foo") but they're globally readable and writable state. And in your function you do a little metric.observe_event() to increment your counte…
It helps with reasoning in some sense, and the net balance might be positive in how much reasoning it enables, but it definitely hurts local reasoning. You need broader context to be able to analyze whether the function is correct (or even what it's supposed to be doing if you don't actively work to prevent entropic decay as the codebase changes). You can't test that function without bringing in that outer context. It (often) doesn't naturally compose well with other functions.
Re: Global variables are not the problem
#83I find the concept of a context structure passed as the first parameter to all your functions with all your "globals" to be very compelling for this sort of stuff.
That's only needed if you use multiple threads. In a single thread global vars are just fine, and much simplier than passing around ctx
Re: Global variables are not the problem
#84SQL databases are global variables
Or caches! I have gotten shit before for using global variables, and sometimes that is justified, but I almost never see anyone given shit over treating Redis as a big ol’ global map.
When it comes to "patterns" and "anti-patterns", double standards are common.
Re: Global variables are not the problem
#85Surely both of the examples in the article are using global variables? Nobody ever said global variables are ok if they are an object? (Or did they?)
Re: Global variables are not the problem
#86From the article> "Static Function Variable: In C inside a function, you can declare a static variable. You could consider this as a local variable but I don't since it's on the heap, and can be returned and modified outside of the functions. I absolutely avoid this except as a counter whose address I never return." These variables are not on the heap. They are statically allocated. Their visibility is the only thing…
Just in case anyone still doesn't understand what that means to be statically allocated. It means that they are allocated in the Data Segment, which is a separate area of virtual memory from the stack and the heap.
Re: Global variables are not the problem
#87Earlier quoted context omitted.
Yes, and code that mutates them in an unmanaged way should be banned.
What is the managed way in this context?
Well personally I favour event sourcing and so in my systems the SQL database (if there is one) is only written to by the event rollup component. But even if you're not that extreme you probably want to have some clear structure to where your database writes happen rather than randomly writing it from any arbitrary line of code. The important thing is to have a structure that everyone working on the code understands so that you all know where any write to the database must have come from, not the specifics of what that structure is.
Re: Global variables are not the problem
#88> If you run the code you'll see 1 2 3 4 3 printed instead of 5.
I'm really confused, as this behaviour appears to be completely obvious to me.
Re: Global variables are not the problem
#89I find the concept of a context structure passed as the first parameter to all your functions with all your "globals" to be very compelling for this sort of stuff.
That's only needed if you use multiple threads. In a single thread global vars are just fine, and much simplier than passing around ctx
And do you always know beyond any reasonable doubt that your code will be single-threaded for all time? Because the moment this changes, you're in for a world of pain.
Re: Global variables are not the problem
#90I find the concept of a context structure passed as the first parameter to all your functions with all your "globals" to be very compelling for this sort of stuff.
Hard disagree. If I have 500 functions, I don't want to extrapolate out the overhead of passing a state object around to all of them. That's a waste of effort, and frankly makes me think you want to code using an FP paradigm even in imperative languages. Module-level and thread-level "globals" are fine. You gain nothing (other than some smug ivory tower sense of superiority) by making your functions pure and passing…
I got into this argument with my former coworkers. Huge legacy codebase. Important information (such as the current tenant of our multi-tenant app) was hidden away in thread-local vars. This made code really hard to understand for newcomers because you just had to know that you'd have to set certain variables before calling certain other functions. Writing tests was also much more difficult and verbose. None of these preconditions were of course documented. We started getting into more trouble once we started using Kotlin coroutines which share threads between each other. You can solve this (by setting the correct coroutine context), but it made the code even harder to understand and more error-prone.
I said we should either abolish the thread-local variables or not use coroutines, but they said "we don't want to pass so many parameters around" and "coroutines are the modern paradigm in Kotlin", so no dice.