языки конфигурации
(программистское)
Языки для файлов конфигурации: полный раздрай. Всё чем-то не подходит и почти всем не нравится, но приходится терпеть.
JSON хорошо передает основную функциональность (дерево ключей-значений), которой хватает в 99% случаев, но он крайне неприятен для чтения и записи людьми. Если конфигурационные файлы в JSON генерируются машинным образом из другого языка, тогда все нормально, но вы не решили проблему, а просто внесли еще один язык в свою систему. В куче случаев конфигурация достаточно проста для того, чтобы JSON можно было читать/писать руками, но не хватает комментариев и раздражают глупые синтаксические ошибки (запятые в конце списков итп.).
YAML решает все эти проблемы и дает эстетически приятный, компактный поток текста. Но во-первых, whitespace становится значащим для корректности и возвращаются любимые вопросы табов и пробелов, по которым мы так соскучились. И во-вторых, правила упрощения кавычек заходят слишком далеко, порождая прекрасные баги типа "норвежской проблемы" (строки yes/no считываются как альтернатива true/false, поэтому код страны Норвегии "no", если его писать без кавычек, может быть воспринят как false). В итоге в Hacker News вчера висело обсуждение на 500 комментариев того, как ужасен YAML, и как все с его помощью стреляли себе в ногу и больше не хотят.
Неплохая идея TOML, но синтаксис для таблиц внутри таблиц не супер интуитивный. CUE lang - интересная, но странная, смесь конфигурации и валидации.
Реально отлично бы выглядел JSON с следующими изменениями: #-комментарии, ключи-строки можно писать без кавычек (но значения-строки надо с кавычками), запятые опциональны и разрешаются после последнего элемента списка. Это выходит где-то 30% на пути от JSON к YAML. Но такого стандарта, удобного для всех, нет.
(P.S. Указали на JSON5, который близок к тому, что я написал в конце, и решает большинство проблем)
Языки для файлов конфигурации: полный раздрай. Всё чем-то не подходит и почти всем не нравится, но приходится терпеть.
JSON хорошо передает основную функциональность (дерево ключей-значений), которой хватает в 99% случаев, но он крайне неприятен для чтения и записи людьми. Если конфигурационные файлы в JSON генерируются машинным образом из другого языка, тогда все нормально, но вы не решили проблему, а просто внесли еще один язык в свою систему. В куче случаев конфигурация достаточно проста для того, чтобы JSON можно было читать/писать руками, но не хватает комментариев и раздражают глупые синтаксические ошибки (запятые в конце списков итп.).
YAML решает все эти проблемы и дает эстетически приятный, компактный поток текста. Но во-первых, whitespace становится значащим для корректности и возвращаются любимые вопросы табов и пробелов, по которым мы так соскучились. И во-вторых, правила упрощения кавычек заходят слишком далеко, порождая прекрасные баги типа "норвежской проблемы" (строки yes/no считываются как альтернатива true/false, поэтому код страны Норвегии "no", если его писать без кавычек, может быть воспринят как false). В итоге в Hacker News вчера висело обсуждение на 500 комментариев того, как ужасен YAML, и как все с его помощью стреляли себе в ногу и больше не хотят.
Неплохая идея TOML, но синтаксис для таблиц внутри таблиц не супер интуитивный. CUE lang - интересная, но странная, смесь конфигурации и валидации.
Реально отлично бы выглядел JSON с следующими изменениями: #-комментарии, ключи-строки можно писать без кавычек (но значения-строки надо с кавычками), запятые опциональны и разрешаются после последнего элемента списка. Это выходит где-то 30% на пути от JSON к YAML. Но такого стандарта, удобного для всех, нет.
(P.S. Указали на JSON5, который близок к тому, что я написал в конце, и решает большинство проблем)