3 ms·

Isn't source code basically a configuration file for the compiler/interpreter? Source code is input, not configuration. Every time you run the compiler, you g

by Goladus 13y ago

Isn't source code basically a configuration file for the compiler/interpreter? Source code is input, not configuration. Every time you run the compiler, you give it different source code. The whole point of the compiler is to transform source code. Configuration is "input" that is not expected to change very often, but that the application developer can not guarantee will never change. Configuration falls into a few categories: 1. Context-specific inputs that can not be predicted or discovered automatically by the application. (For example, the DNS zones the process is expected to host - named.conf) 2. Inputs that are not expected to change very often, but should be easy to change if necessary. (ssh client or server settings) 3. For applications with interactive user interfaces, customization and changes to the default interface. For the vast majority of applications, a text file capable of expressing simple data structures is more than sufficient. Others advocate using only a database, but only to make configuration dynamic so explicit reloads aren't necessary, not to make it more like a programming language. The source-vs-configuration question is usually only be an issue when dealing with large, complex applications with very general specifications.

ericHosick 13y ago
> Source code is input, not configuration. Every time you run the compiler, you give it different source code. Interpreted languages (JIT) re-interpret the same source code every time they are run (though they don't have to). What about monkey patching (http://en.wikipedia.org/wiki/Monkey_patch http://en.wikipedia.org/wiki/Monkey_patch)? An example usage is altering behavior (the source code) based on running the code in a testing environment -vs- production (as one example). How about dependency injection? How about lambda expressions? What about best known practices like favor composition over inheritance? If we hard code a solution using inheritance that is input but if we build out a solution using composition that is a configuration? These are all tools available to programmers that provide ways of changing behavior at the source code level even though that behavior may not change very often. This is starting to look like a real gray area to me: input -vs- configuration. I guess we can try and distinguish between the types of input a system consumes (based on the static nature of the input) but I don't know how useful that is as an abstraction.
- Goladus 13y ago
  Monkey patching is 3rd-party modification to the application itself; or specially modified inputs that simulate such a modification. It's not configuration. Dependency injection is a software design pattern. There's no point calling it configuration. A lambda expression, from a programming perspective, is just an anonymous function, a function so trivial it does not need an associated identifier. > If we hard code a solution using inheritance that is > input but if we build out a solution using composition > that is a configuration? No, a solution using composition is not configuration. Maybe it might help to think of the intended audience: Configuration is intended for end-users or system administrators, NOT programmers. Configuration specifically refers to inputs that you remove from code and place somewhere that is (a) easily modified by anyone and (b) very hard to break. All of the tools or techniques you list are targeted at programmers (and programmers doing programming, not configuring their text editor or IDE). > This is starting to look like a real gray area to me: > input -vs- configuration. Of course it's a grey area. Configuration is ultimately a type of input. But there's still a semantic distinction to make, just like there's a semantic distinction between a desert and a grassland even though the border between the two isn't distinct. Also, I should make it clear there's an assumption we're talking about application configuration, not configuration in the ITIL sense, where it has an extremely generic meaning. > I guess we can try and distinguish between the types > of input a system consumes (based on the static nature > of the input) but I don't know how useful that is as > an abstraction. Primarily, the distinction informs decisions about how access to various options and features are provided. Do you require the code itself to be modified? Do you make it a compile-time flag? Do you have the application load it from a default file in a standard location (like /etc/myapp.conf) or do you read the input from stdin? It's possible to have a solid understanding of where to put things without actually using the word "configuration" but why not just use the term since it is already there?
  - kyllo 13y ago
    Code vs config is not supposed to be a grey area, but it quickly becomes one when you try to make the application so configurable that you're actually moving business logic to the config files. That's why that is an anti-pattern.

by Goladus 13y ago

ericHosick 13y ago

> Source code is input, not configuration. Every time you run the compiler, you give it different source code. Interpreted languages (JIT) re-interpret the same source code every time they are run (though they don't have to). What about monkey patching (http://en.wikipedia.org/wiki/Monkey_patch http://en.wikipedia.org/wiki/Monkey_patch)? An example usage is altering behavior (the source code) based on running the code in a testing environment -vs- production (as one example). How about dependency injection? How about lambda expressions? What about best known practices like favor composition over inheritance? If we hard code a solution using inheritance that is input but if we build out a solution using composition that is a configuration? These are all tools available to programmers that provide ways of changing behavior at the source code level even though that behavior may not change very often. This is starting to look like a real gray area to me: input -vs- configuration. I guess we can try and distinguish between the types of input a system consumes (based on the static nature of the input) but I don't know how useful that is as an abstraction.

Goladus 13y ago
Monkey patching is 3rd-party modification to the application itself; or specially modified inputs that simulate such a modification. It's not configuration. Dependency injection is a software design pattern. There's no point calling it configuration. A lambda expression, from a programming perspective, is just an anonymous function, a function so trivial it does not need an associated identifier. > If we hard code a solution using inheritance that is > input but if we build out a solution using composition > that is a configuration? No, a solution using composition is not configuration. Maybe it might help to think of the intended audience: Configuration is intended for end-users or system administrators, NOT programmers. Configuration specifically refers to inputs that you remove from code and place somewhere that is (a) easily modified by anyone and (b) very hard to break. All of the tools or techniques you list are targeted at programmers (and programmers doing programming, not configuring their text editor or IDE). > This is starting to look like a real gray area to me: > input -vs- configuration. Of course it's a grey area. Configuration is ultimately a type of input. But there's still a semantic distinction to make, just like there's a semantic distinction between a desert and a grassland even though the border between the two isn't distinct. Also, I should make it clear there's an assumption we're talking about application configuration, not configuration in the ITIL sense, where it has an extremely generic meaning. > I guess we can try and distinguish between the types > of input a system consumes (based on the static nature > of the input) but I don't know how useful that is as > an abstraction. Primarily, the distinction informs decisions about how access to various options and features are provided. Do you require the code itself to be modified? Do you make it a compile-time flag? Do you have the application load it from a default file in a standard location (like /etc/myapp.conf) or do you read the input from stdin? It's possible to have a solid understanding of where to put things without actually using the word "configuration" but why not just use the term since it is already there?
- kyllo 13y ago
  Code vs config is not supposed to be a grey area, but it quickly becomes one when you try to make the application so configurable that you're actually moving business logic to the config files. That's why that is an anti-pattern.