> These methods are being used for decades and well understood with all their advantages and disadvantages.
Just because something has been used for decades does not make it good - for example, avoidable mutable state. And it certainly does not make it well-understood - as a consultant the number of brain frying environment variable configurations I've had to deal with which no permies could tell me anything about defies belief.
> someone comes and tells that it's bad and considered harmful,
Yes, some things are bad and are actively harmful. Famously, unstructured programming using gotos. Would you like to go back to that? Believe me, you would not. But perhaps you are not a programmer?
> That thing wouldn't be a de-facto standard if it was too bad, right?
> Just because something has been used for decades does not make it good.
I'm not calling this is good with the persistence of the original author. I tell that it's one of the realities that we have, and instead of burning it with torches, why not build better conventions around it with better attitude and language?
Maybe we can try: "Instead of burying all config under environment variables, why not try doing it like this?", and slowly build something better, step by step. Nothing is inherently good or bad, but can be abused. So the abuse of environment variables as a shortcut needs to stop, one may say and I'd agree, and may also volunteer to help to build a better thing.
But, shunning it with anger and shouting "I'm the one who knows all right things!" sure creates backlash, like here.
All in all, I'm against the attitude, not the idea of improving a situation.
> Yes, some things are bad and are actively harmful.
It might be, but even your solution might not be right. Why the attitude?
> unstructured programming using gotos. Would you like to go back to that?
Did that on some older, limited hardware, and it was fun. It was not OK by today's standards, but I had to. I'll do it again if it's the only thing I can do to work on that particular hardware again.
> But perhaps you are not a programmer?
I just design algorithms and develop scientific applications which run on HPC clusters, nothing fancy.
> It's not a "de-facto standard", it's simply bad.
I didn't say it's good. I say it's a fact. I'm not disagreeing on its bad sides. I'm not OK with the attitude.
> "Instead of burying all config under environment variables, why not try doing it like this?", and slowly build something better, step by step
Use named files, that can be version controlled and documented, but are under direct access from the actual program and can be reported as an error if (for example) they are not found.
1. Make the thing completely configurable with a file.
2. Add an optional switch to select the location of the config file.
3. Always ship a well commented, sensible config file with the application. Document environment variables there, if any.
4. If it makes sense, add the ability generate a default config file if it's missing.
5. Always add a logger, with good debug and error output (Dovecot is my inspiration and role model there).
6. Document everything in the code, and in the documentation if possible (external documentation is not my strong part yet. I can't write it fast enough).
> But, shunning it with anger and shouting "I'm the one who knows all right things!" sure creates backlash, like here.
I think this is relative. I did read the post as well, and I didn't find the author with such a "negative" attitude (but then again, I'm not American).
Just because something has been used for decades does not make it good - for example, avoidable mutable state. And it certainly does not make it well-understood - as a consultant the number of brain frying environment variable configurations I've had to deal with which no permies could tell me anything about defies belief.
> someone comes and tells that it's bad and considered harmful,
Yes, some things are bad and are actively harmful. Famously, unstructured programming using gotos. Would you like to go back to that? Believe me, you would not. But perhaps you are not a programmer?
> That thing wouldn't be a de-facto standard if it was too bad, right?
It's not a "de-facto standard", it's simply bad.