В какой момент конфигурационный файл становится языком программирования?

Я уже некоторое время обдумываю конфигурационные файлы и их отношение к коду, и в зависимости от дня и направления ветра мои мнения, похоже, меняются. Все больше и больше, хотя я продолжаю возвращаться к осознанию, которое я впервые получил, изучая Lisp: между данными и кодом мало разницы. Это кажется вдвойне верно для конфигурационных файлов. При взгляде в правильном свете скрипт Perl-это немного больше, чем конфигурационный файл для perl. Это, как правило, имеет довольно тяжелый последствия для таких задач, как QA и разделение труда, например, кто должен отвечать за изменение конфигурационных файлов.

ползучесть от конфигурационного файла до полноценного языка обычно медленная и, похоже, вызвана желанием иметь общую систему. Большинство проектов, похоже, начинаются с небольших элементов конфигурации, таких как где писать журналы, где искать данные, имена пользователей и пароли и т. д. Но затем они начинают расти: функции начинают быть в состоянии быть включен или выключен, тайминги и порядок операций начинают контролироваться, и, неизбежно, кто-то хочет начать добавлять логику к нему (например, использовать 10, если машина X и 15, если машина Y). В определенный момент конфигурационный файл становится доменным языком, причем плохо написанным.

теперь, когда я побродил по сцене, вот мои вопросы:

1. какова истинная цель конфигурации
   файл?


2. если будет предпринята попытка сохранить
   конфиг файлы просто?


3. кто должен нести ответственность за создание
   изменения в них (разработчики, пользователи,
   админов и т. д.)?


4. должны ли они управляться с исходным кодом
   (см. Вопрос 3)?

Как я уже говорил ранее, мои ответы на эти вопросы постоянно меняются, но сейчас я думаю:

1. чтобы позволить не-программистам изменить
   большие куски поведения быстро


2. да, все, что не крупно
   зернистый должен быть внутри код


3. пользователи должны нести ответственность за
   конфигурационные файлы и программисты должны
   ответственность за конфигурации
   слой между конфигурационными файлами и кодом
   это дает более мелкозернистый контроль
   из приложения


4. нет, но более мелкозернистый средний слой должен быть