4 ms·

Ship your dependencies. Let me repeat that. Ship your damn dependencies! Semi-related, environment variables are pure evil. Operating systems shouldn’t allow e

Ship your dependencies. Let me repeat that. Ship your damn dependencies! Semi-related, environment variables are pure evil. Operating systems shouldn’t allow environment variables and programming languages shouldn’t allow global variables. C++ headers are insane and miserable. Makes me sad. And causing me endless grief. One distinction the author doesn’t quite make (unless I missed it) is the difference in shipping a pre-compiled static lib and shipping code intended to be compiled in a static lib. The first is almost the same thing as shipping a shared lib. You need a pure C API to ensure compatibility. The second you can do whatever because users will compile with their own settings and types will be consistent.

saagarjha 6y ago
> Semi-related, environment variables are pure evil. Operating systems shouldn’t allow environment variables and programming languages shouldn’t allow global variables. Defending absolutist opinions is usually difficult and I this one is no different. What do you have against environment variables, which provide a unified interface to expose user-facing tunables? Where do you store shared program state?
- forrestthewoods 6y ago
  Global variables are evil. Environment variables are global variables. Lord knows how much time I’ve wasted helping people figure out why something works on one machine but not another. The answer is often because they had something in some obscure envvar that may have been set once upon a time by lord knows what. The alternative? Users launching a program should explicitly specify configuration information. Choose sane defaults. Let them be configurable via cmdline args or a config file. Ideally both. An explicitly specified config file is so much cleaner than envvar imho. Scripts that locally override global envvar is super sketch, hidden, and error prone. TBH I think the fact that Docker exists is testament to the INSANITY of Linux environment configuration. It’s so incredibly hard to reliably launch a program that we built ecosystems of containers to encapsulate system wide configuration. And even that is hard and error prone.
  - pjc50 6y ago
    > It’s so incredibly hard to reliably launch a program This is just silly. Global state is inevitable. If it's not in the environment it would be in the filesystem or the Windows registry.
    - forrestthewoods 6y ago
      Windows registry is also evil. Because it’s basically the same thing. Global state may be inevitable. But that doesn’t mean you should throw the towel and sprinkle global state all over the place. You should try really really hard to have the barest minimum global state. You might be surprised how little you actually need.
- jcranmer 6y ago
  At my work, the development environment relies way too heavily on environment variables to configure things like "where is the build located," which breaks things like being able to easily use the built products on a different machine. Annoyingly, this also means that the tooling can't be regular scripts, since it has to change the environment variables of your current shell, which also means that you can't write regular scripts to abstract over the tooling because it's actually crazy shell shenanigans and not executables that are doing everything. Admittedly, that is a bad design, and it is a problem in large part because it is a bad design and not because of using environment variables by itself. In general, though, my preference is that environment variables be the last resort of the programmer for configuration. Providing command-line switches or files in well-known locations is almost always a better idea, and environment variables should largely be reserved only for when the use is of a debugging or other unusual configuration.
- fctorial 6y ago
  Explicit is better than implicit.

saagarjha 6y ago

> Semi-related, environment variables are pure evil. Operating systems shouldn’t allow environment variables and programming languages shouldn’t allow global variables. Defending absolutist opinions is usually difficult and I this one is no different. What do you have against environment variables, which provide a unified interface to expose user-facing tunables? Where do you store shared program state?

forrestthewoods 6y ago
Global variables are evil. Environment variables are global variables. Lord knows how much time I’ve wasted helping people figure out why something works on one machine but not another. The answer is often because they had something in some obscure envvar that may have been set once upon a time by lord knows what. The alternative? Users launching a program should explicitly specify configuration information. Choose sane defaults. Let them be configurable via cmdline args or a config file. Ideally both. An explicitly specified config file is so much cleaner than envvar imho. Scripts that locally override global envvar is super sketch, hidden, and error prone. TBH I think the fact that Docker exists is testament to the INSANITY of Linux environment configuration. It’s so incredibly hard to reliably launch a program that we built ecosystems of containers to encapsulate system wide configuration. And even that is hard and error prone.
- pjc50 6y ago
  > It’s so incredibly hard to reliably launch a program This is just silly. Global state is inevitable. If it's not in the environment it would be in the filesystem or the Windows registry.
  - forrestthewoods 6y ago
    Windows registry is also evil. Because it’s basically the same thing. Global state may be inevitable. But that doesn’t mean you should throw the towel and sprinkle global state all over the place. You should try really really hard to have the barest minimum global state. You might be surprised how little you actually need.
jcranmer 6y ago
At my work, the development environment relies way too heavily on environment variables to configure things like "where is the build located," which breaks things like being able to easily use the built products on a different machine. Annoyingly, this also means that the tooling can't be regular scripts, since it has to change the environment variables of your current shell, which also means that you can't write regular scripts to abstract over the tooling because it's actually crazy shell shenanigans and not executables that are doing everything. Admittedly, that is a bad design, and it is a problem in large part because it is a bad design and not because of using environment variables by itself. In general, though, my preference is that environment variables be the last resort of the programmer for configuration. Providing command-line switches or files in well-known locations is almost always a better idea, and environment variables should largely be reserved only for when the use is of a debugging or other unusual configuration.
fctorial 6y ago
Explicit is better than implicit.