5 ms·

Certainly a taste for global state, it seems.

atemerev 2y ago
Dogmatically rejecting global state even if it simplifies things in some particular case _is_ poor taste. Even a goto can be elegant sometimes.
- zelphirkalt 2y ago
  Usually though it just creates long term issues, putting off important work to later.
  - bmacho 2y ago
    Sometimes later never comes, so it's a net win compared to languages where you are forced do this important work now.
    - lolinder 2y ago
      But when later does come, it can take dev-years to fully disentangle the global state and allow code reuse. Did you gain dev-years in productivity by using it in the first place? Probably not. If you have good reason to believe that an app will stick around for more than a year, be maintained by more than 3 people, or grow to more than 500k lines of code (sub in whatever metrics make sense to you), don't put off removing global state for later. You will regret it eventually, and it doesn't cost much to do it right the first time. (Also, no mainstream language I'm aware of forces you to not use global state. Even Java, famed for its rigidity, has global state readily available if you really do need it.)
      - trevorhinesley 2y ago
        You’re describing the pain of poor architecture rather than the pain of global state. The tool itself is neutral. Sharp knives and all that.
        lolinder 2y ago
        Global state is a tool that will almost always lead to bad architecture in an app where architecture matters. I'm sure you can point to a counterexample or two where a set of devs managed to keep disciplined indefinitely, but that doesn't change the fact that allowing people to reach into a mutable variable from anywhere in the system enables trivially accessible spooky action at a distance, and spooky action at a distance is a recipe for disaster in a medium to large code base. In a project with more than a few people on it, your architecture will decay if it can decay. Avoiding global state removes one major source of potential decay.
        trevorhinesley 2y ago
        “Almost” is key there. I respect your position, but it’s an always/never take, and the longer I am in this industry, the more I find myself leaning into “it depends.” Here’s a take that articulates this being done well on a large codebase better than I can in a short comment: https://dev.37signals.com/globals-callbacks-and-other-sacrileges/ https://dev.37signals.com/globals-callbacks-and-other-sacril...
        lolinder 2y ago
        > it’s an always/never take No, it isn't—I'm the one who inserted the word "almost" into that sentence! Where did you get the idea that I meant always/never? Like I said, you can point to exceptions but that doesn't change the rule. It's better to teach the rule and break it when you really know what you're doing—when you understand that you're breaking a rule and can articulate why you need to and why it's okay this time—than it is to spread the idea that globals are really just fine and you need to weigh the trade-offs. The odds are strongly against you being the exception, and you should act accordingly, not treat globals as just another tool. Sometimes amputation is the right move to save someone's life, but you certainly should not default to that for every papercut. It's a tool that comes out in extreme circumstances only when a surgeon can thoroughly justify it.
        trevorhinesley 2y ago
IshKebab 2y ago
Don't forget ungreppable code! And what are type hints anyway?
simpaticoder 2y ago
Global state is wonderful when the world is small. Rubyfolk then keep the world small, which has many other benefits.
- lolinder 2y ago
  Sorry, I like Ruby, but this is nonsense. Rails apps get enormous very quickly, like apps written in every other framework. In most work you can't just declare that your world will be small, your world is as big as your problem is.
techscruggs 2y ago
Well, taste for a Global Interpreter Lock, at least.

Dogmatically rejecting global state even if it simplifies things in some particular case _is_ poor taste. Even a goto can be elegant sometimes.

zelphirkalt 2y ago
Usually though it just creates long term issues, putting off important work to later.
- bmacho 2y ago
  Sometimes later never comes, so it's a net win compared to languages where you are forced do this important work now.
  - lolinder 2y ago
    But when later does come, it can take dev-years to fully disentangle the global state and allow code reuse. Did you gain dev-years in productivity by using it in the first place? Probably not. If you have good reason to believe that an app will stick around for more than a year, be maintained by more than 3 people, or grow to more than 500k lines of code (sub in whatever metrics make sense to you), don't put off removing global state for later. You will regret it eventually, and it doesn't cost much to do it right the first time. (Also, no mainstream language I'm aware of forces you to not use global state. Even Java, famed for its rigidity, has global state readily available if you really do need it.)
    - trevorhinesley 2y ago
      You’re describing the pain of poor architecture rather than the pain of global state. The tool itself is neutral. Sharp knives and all that.
      - lolinder 2y ago
        Global state is a tool that will almost always lead to bad architecture in an app where architecture matters. I'm sure you can point to a counterexample or two where a set of devs managed to keep disciplined indefinitely, but that doesn't change the fact that allowing people to reach into a mutable variable from anywhere in the system enables trivially accessible spooky action at a distance, and spooky action at a distance is a recipe for disaster in a medium to large code base. In a project with more than a few people on it, your architecture will decay if it can decay. Avoiding global state removes one major source of potential decay.
        trevorhinesley 2y ago
        “Almost” is key there. I respect your position, but it’s an always/never take, and the longer I am in this industry, the more I find myself leaning into “it depends.” Here’s a take that articulates this being done well on a large codebase better than I can in a short comment: https://dev.37signals.com/globals-callbacks-and-other-sacrileges/ https://dev.37signals.com/globals-callbacks-and-other-sacril...
        lolinder 2y ago
        > it’s an always/never take No, it isn't—I'm the one who inserted the word "almost" into that sentence! Where did you get the idea that I meant always/never? Like I said, you can point to exceptions but that doesn't change the rule. It's better to teach the rule and break it when you really know what you're doing—when you understand that you're breaking a rule and can articulate why you need to and why it's okay this time—than it is to spread the idea that globals are really just fine and you need to weigh the trade-offs. The odds are strongly against you being the exception, and you should act accordingly, not treat globals as just another tool. Sometimes amputation is the right move to save someone's life, but you certainly should not default to that for every papercut. It's a tool that comes out in extreme circumstances only when a surgeon can thoroughly justify it.
        trevorhinesley 2y ago

IshKebab 2y ago

Don't forget ungreppable code! And what are type hints anyway?

simpaticoder 2y ago

Global state is wonderful when the world is small. Rubyfolk then keep the world small, which has many other benefits.

lolinder 2y ago
Sorry, I like Ruby, but this is nonsense. Rails apps get enormous very quickly, like apps written in every other framework. In most work you can't just declare that your world will be small, your world is as big as your problem is.

techscruggs 2y ago

Well, taste for a Global Interpreter Lock, at least.