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

91–100 of 165 posts

Re: Global variables are not the problem

#91

Post by silon42 »

wruza wrote: post #74
rafaelmn wrote: post #21

Earlier quoted context omitted.

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

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

So, making it implicit again? No.

Re: Global variables are not the problem

#92

Post by cauefcr »

js8 wrote: post #80

Any program that uses a database has a very similar problem to global variables. As Gilad Bracha has pointed out, types are antimodular, and your database schema can be considered one giant type that pervades your program, just like globals can be. I don't think we have tools to compositionally solve this, across different programming languages.

Migrations? Generate bindings for your queries automatically with query+schema definitions? (sqlc)

Re: Global variables are not the problem

#94

Post by wruza »

silon42 wrote: post #91
wruza wrote: post #74

Earlier quoted context omitted.

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

So, making it implicit again? No.

You can have it either way, it’s not for you but for people who disagree with what they deem a preference that is the only option when there’s no alternative.

Re: Global variables are not the problem

#96

Post by nejsjsjsbsb »

js8 wrote: post #80

Any program that uses a database has a very similar problem to global variables. As Gilad Bracha has pointed out, types are antimodular, and your database schema can be considered one giant type that pervades your program, just like globals can be. I don't think we have tools to compositionally solve this, across different programming languages.

Your program is also one giant type.

Re: Global variables are not the problem

#97

Post by nejsjsjsbsb »

paulsutter wrote: post #58

SQL databases are global variables

What does the ideal look like then? Data storage encapsulation in the app? Perhaps different DB users with granular access, accessed from different non-global parts of the program. Chuck in some views later when you need performance pragmatism!

Re: Global variables are not the problem

#98

Post by nejsjsjsbsb »

macintux wrote: post #60
paulsutter wrote: post #58

SQL databases are global variables

And man, the bugs they cause.

Man, the bugs they prevent. Vs everyone rolling their own multithreaded file reader/writer code in C. How many programmers would think to journal transactions and ship them for backup for example.

SQL or 15000 lines of C++ or Go or Rust doing whatever with files.

Re: Global variables are not the problem

#99

Post by Someone »

billforsternz wrote: post #41

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

> These variables are not on the heap. They are statically allocated. Their visibility is the only thing that differentiates them from global variables and static variables defined outside of functions.

In C++, there is a difference: function-static variables get initialized when control first passes into the function. That difference matters in cases where the initial value (partly) comes from a function call or from another global. For example, in C++ one can do:

  int bar = -1;

  void foo() {
    static char * baz = malloc(bar);
    …
  }

  void quux() {
    bar = 13;
  }
That’s fine as long as the code calls quux before ever calling foo.

They added that feature not to support such monstrosities, but because they wanted to support having static variables of class type.

If they were to design that today, I think they would require the initialization expression to be constexpr.

Post reply on HN