Okay, so, I don't think the author cares about the situation where your entire system is, like, 1) set env var 2) launch long-running network service 3) never spawn another process inheriting the environment. That's the trivial, happy case. This post is probably more useful if you look at it from the perspective of a system invoking many different processes that come and go, somewhat recursively, likely integrating many independently-developed codebases.
With non-trivial use of environment variables, you're just back to arguing about dynamically-scoped variables vs. lexically-scoped variables (comparing environment variables to lexically-scoped global variables seems besides the point). There are uses for dynamic scope and it keeps getting reinvented, but we know it comes with gotchas and typically prefer lexically-scoped variables.
eg., environment variables are handy because you can pass them to your grandchildren without the direct children needing to know about them. Environment variables are hazardous because you can inadvertently pass environment variables to your children without knowing you inherited them from your parent.
Environment variables can save you from having to teach your program to pass on the correct configuration. Environment variables can damn you when your children rely on them and hence omit facilities to propagate configuration in some nuanced manner. etc.
I'm taken aback by the rancor in our comments. It shouldn't come as a surprise that people developing different kinds of software arrive at different best practices. I'm enjoying this kind of post much more when resolving the cognitive dissonance by trying to understand where the other side is coming from and how the experiences that shaped our respective aesthetic intuition differ.
With non-trivial use of environment variables, you're just back to arguing about dynamically-scoped variables vs. lexically-scoped variables (comparing environment variables to lexically-scoped global variables seems besides the point). There are uses for dynamic scope and it keeps getting reinvented, but we know it comes with gotchas and typically prefer lexically-scoped variables.
eg., environment variables are handy because you can pass them to your grandchildren without the direct children needing to know about them. Environment variables are hazardous because you can inadvertently pass environment variables to your children without knowing you inherited them from your parent.
Environment variables can save you from having to teach your program to pass on the correct configuration. Environment variables can damn you when your children rely on them and hence omit facilities to propagate configuration in some nuanced manner. etc.
I'm taken aback by the rancor in our comments. It shouldn't come as a surprise that people developing different kinds of software arrive at different best practices. I'm enjoying this kind of post much more when resolving the cognitive dissonance by trying to understand where the other side is coming from and how the experiences that shaped our respective aesthetic intuition differ.