You're right that mutable state should be kept to a minimum, but immutable state is fine. There usually isn't much need to mutate env vars. Some thoughts/remar

You're right that mutable state should be kept to a minimum, but immutable state is fine. There usually isn't much need to mutate env vars. Some thoughts/remarks: - If we don't change a variable/value then it's immutable. Some languages let us enforce this (e.g. 'const'), which is nice, but we shouldn't worry too much if our language doesn't. - We're violating 'single source of truth' if we have some parts of our code reading the env var, and some reading from a normal language variable. This also applies to arguments through. - Reading from an env var is an I/O effect, which we should minimise. - We can solve the last 2 problems by reading each env var once, up-front, then passing the result around as a normal value (i.e. functional core, imperative shell) - Env vars are easy to shadow, e.g. if our script uses variables FOO and BAR, we can use a different value for BAR within a sub-command, e.g. in bash: BAR=abc someCommand This will inherit 'FOO' but use a different value of 'BAR'. This isn't mutable state, it's a nested context, more like: let foo = 123 bar = "hello" baz = otherCommand quux = let bar = "abc" in someCommand As TeMPOraL notes, env vars are more like dynamically scoped variables, whilst most language variables are lexically scoped.