Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Global variables are not the problem

codestyleandtaste.com

Post reply on HN
Print view View original

21–30 of 165 posts

Re: Global variables are not the problem

#21

Post by rafaelmn »

caspper69 wrote: post #16
serbuvlad wrote: post #4

I 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…

You 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 :/

Re: Global variables are not the problem

#22

Post by Jtsummers »

The bug in the program reveals a poor understanding of object lifecycles by whoever wrote it. The `obj` argument to `simple` is not globally unique and so it makes a poor location to store global state information (a count of how often `simple` is called, in this example).

Never tie global state information to ephemeral objects whose lifetime may be smaller than what you want to track. In this case, they want to know how many times `simple` is called across the program's lifetime. Unless you can guarantee the `obj` argument or its `counter` member exists from before the first call to `simple` and through the last call to `simple` and is the only `obj` to ever be passed to `simple`, it is the wrong place to put the count information. And with those guarantees, you may as well remove `obj` as a parameter to both `simple` and `complex` and just treat it as a global.

State information needs to exist in objects or locations that last as long as that state information is relevant, no more, no less. If the information is about the overall program lifecycle, then a global can make sense. If you only need to know how many times `simple` was invoked with a particular `obj` instance, then tie it to the object passed in as the `obj` argument.

Re: Global variables are not the problem

#23

Post by bee_rider »

serbuvlad wrote: post #4

I 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 just seems like globals with extra steps. Suddenly if your context structure has a weird value in it, you’ll have to check every function to see who messed it up.

Re: Global variables are not the problem

#24

Post by bigcat12345678 »

bee_rider wrote: post #23
serbuvlad wrote: post #4

I 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 just seems like globals with extra steps. Suddenly if your context structure has a weird value in it, you’ll have to check every function to see who messed it up.

That's 2 parts: 1. Global variable (mutable) 2. Local function with context argument (mutations)

You have clear tracking of when and how functions change the global variable

Re: Global variables are not the problem

#25

Post by peanut-walrus »

Puts wrote: post #5

I think the author forgot the most useful use case for globals, and that is variables that has to do with the context the program is running under such as command line arguments and environment variables (properly validated and if needed escaped).

Do those change during program runtime though? I don't think many people have problems with global constants.

Re: Global variables are not the problem

#26

Post by levodelellis »

Jtsummers wrote: post #22

The bug in the program reveals a poor understanding of object lifecycles by whoever wrote it. The `obj` argument to `simple` is not globally unique and so it makes a poor location to store global state information (a count of how often `simple` is called, in this example). Never tie global state information to ephemeral objects whose lifetime may be smaller than what you want to track. In this case, they want to know…

Could you tell me where this was posted? I thought no one would see this after I got no comments the first day

No one I showed this to complained about the first example but online many people did. I wrote a completely different article which I think is much better that uses examples I would have used in the follow up. I'll post that article next week

Re: Global variables are not the problem

#27

Post by levodelellis »

serbuvlad wrote: post #4

I 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 exactly why I used this specific example. I seen many code bases that use clone to avoid mutation problems so I wrote this specifically to show it can become a problem too.

I wrote a better article on globals. I plan on posting it next week

Re: Global variables are not the problem

#28

Post by catlifeonmars »

grandempire wrote: post #15
zabzonk wrote: post #12

Earlier quoted context omitted.

how do you know that? just about every serious bug i have ever written was when i thought i understood multi-threaded code, but didn't.

Because as a programmer I have responsibility for the technical soundness of the program, and I don't create threads haphazardly. > when i thought i understood multi-threaded code, but didn't. All the more reason to carefully plan and limit shared state among threads. It's hard enough to get right when you know where the problems are and impossible if you spray and pray with mutexes.

Yeah but just because you do the right thing doesn’t mean that others will. That one person that creates threads haphazardly will wreak havoc and at scale this will happen. It’s an unstable equilibrium to put the onus of program soundness on the contributors to a program.

Re: Global variables are not the problem

#29

Post by catlifeonmars »

grandempire wrote: post #13
rileymat2 wrote: post #10

Earlier quoted context omitted.

You know it is /currently/ accessed on one thread. These are little landmines that add up over time.

The burden is on the programmer adding a new thread to know what they can safely access. The conclusion of your argument looks like 2000s Java - throw a mutex on every property because you never know when it will need to be accessed on a thread. Designs that spread complexity rather than encapsulate it are rarely a good idea.

That’s sounds more like a weakness of the language: that preventing data races is not automatically tracked for you, no?

Re: Global variables are not the problem

#30

Post by Jtsummers »

levodelellis wrote: post #26
Jtsummers wrote: post #22

The bug in the program reveals a poor understanding of object lifecycles by whoever wrote it. The `obj` argument to `simple` is not globally unique and so it makes a poor location to store global state information (a count of how often `simple` is called, in this example). Never tie global state information to ephemeral objects whose lifetime may be smaller than what you want to track. In this case, they want to know…

Could you tell me where this was posted? I thought no one would see this after I got no comments the first day No one I showed this to complained about the first example but online many people did. I wrote a completely different article which I think is much better that uses examples I would have used in the follow up. I'll post that article next week

Second chance pool. This post is, per your submission history, from 2 days ago. HN has a second chance pool that lets articles continue collecting upvotes (more easily than digging through the full history). Some of those articles will get their timestamp updated to artificially inflate their ranking. This brings them to the front page again and gives them their "second chance". After a few hours or whatever time, the timestamp is reverted and they'll start falling back into their natural place in the rankings.

https://news.ycombinator.com/submitted?id=levodelellis

https://news.ycombinator.com/lists

https://news.ycombinator.com/pool

Post reply on HN