7 ms·
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,
by caspper69 2y ago
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 around a global state object to every single method invocation.
- pdimitar 2y agoHard to take your comment seriously when you go out of your way to degrade a discussion opponent, FYI.
- deleted 2y ago[deleted]
- caspper69 2y agoMy comment was not intended to be personally degrading to OP. Apologies if it was taken that way.
- pdimitar 2y agoI did not say you are targeting OP. I meant that you are degrading your parent commenter. This: "You gain nothing (other than some smug ivory tower sense of superiority) by making your functions pure and passing around a global state object to every single method invocation." ...is neither productive nor actually true. But I'll save the latter part for your other reply.
- caspper69 2y agoI'll take my medicine. :) I'm not above being put in my place and being shown the light. (And when I said OP, I did mean the parent poster) You should also understand that the "you" in my comment you quoted is the colloquial you and not necessarily the parent poster. So lay it on me.
- pdimitar 2y agoOK, I will. But I also got a notification about a big comment you posted but it is now deleted. Did you want to rewrite it or did you give up on it?
- caspper69 2y agoI could not initially reply to you. Your comment rubbed me the wrong way, because I had no intention of trying to degrade anyone, and frankly, I was offended. But I thought better of my hasty and emotional response. I would rather take a deep breath, re-focus, re-engage, and be educated in a thoughtful dialog than get into a mud slinging contest. I am always willing to be enlightened.
- Jtsummers 2y agoA tip, in your profile you can set a delay which is a number of minutes before your comments will become visible to other people. Mine is set to 2 right now. This gives you time to edit your comment (helpful for some longer ones) but also to write some garbage response and then think better and delete it before anyone's the wiser. It's also helpful to give you time to re-read a mostly good, but maybe not polite, response and tone down your response.
- caspper69 2y agoMuch appreciated :)
- robertlagrant 2y agoThat is a good tip.
- pdimitar 2y agoCommendable, still let's not forget that the part I quoted was the beginning of a mud-slinging contest that you seemed willing to start. ;) So indeed, let's re-focus and re-engage. To that end, I will post you a longer reply Later™.
- rafaelmn 2y agoYou get functions that are easily testable in isolation with all state provided in parameters. You also get explicit dependencies and scoping controlled by caller. I don't mind globals but saying you get nothing for avoiding them is :/
- Gibbon1 2y agoI tend to use getter and setter functions to access globals and manage state. Advantage only the function that depends on the global needs to bring in the dependency.
- wruza 2y agoIf that’s so useful, make your language support the concept of lexical environments instead. Otherwise it’s just manual sunsetting every day of week. Our craft is full of this “let’s pretend we’re in a lisp with good syntax” where half of it is missing, but fine, we’ll simulate it by hand. Dirt and sticks engineering. (To be clear, I’m just tangentially ranting about the state of things in general, might as well post this under somewhere else.)
- Panzer04 2y agoJust need to make sure your module doesn't get too big or unwieldy. I work in a codebase with some "module" C files with a litany of global statics and it's very difficult to understand the possible states it can be in or test it. I agree that so long as overall complexity is limited these things can be OK. As soon as you're reading and writing a global in multiple locations though I would be extremely, extremely wary.
- billmcneale 2y agoYes, 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.
- caspper69 2y agoThis 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?
- stickfigure 2y agoSure. 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.
- Tainnor 2y agoI can't agree more, I was dying this death a thousand times over at my last job.
- Tainnor 2y agoI 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.
- caspper69 2y agoYou know what helps manage all this complexity and keep the state internally and externally consistent? Encapsulation. Provide methods for state manipulation that keep the application state in a known good configuration. App level, module level or thread level. Use your test harness to control this state. If you take a step back I think you’ll realize it’s six of one, half dozen of the other. Except this way doesn’t require manually passing an object into every function in your codebase.
- Tainnor 2y agoThese 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 important business-critical code... no, please pass it around, so I can see at a glance (and with help from my compiler) which parts of the code need what kind of information.
- caspper69 2y ago
- serbuvlad 2y agoIt's one register. You gain that much performance from the single optimization of not updating rbp in release builds.