YAML из Ада

Вы перечислили DHall, cue, HCL. Но пропустили достаточно популярный jsonnet. Который точно также работает со структурами данных, вместо того чтобы шаблонизиоровать текст, и на мой взгляд мощнее перечисленных.

А вот шаблонить ямл как текст, как делает helm это конечно дичь. Я тоже в шоке что это обрело такую популярность.

А по поводу самого yaml. Да есть странности. Но я вот за всю практику (8 лет примерно) никогда не попадал на описанные проблемы. Всегда если сомневался просто использовал кавычки. Мне его читать удобнее, поэтому конфигам на ямле я рад. А вот указанные toml и xml мне читать гораздо сложнее, томл со средней и большой вложенностью совсем не в читаемую кашу превращается. Конечно наверное с большой вложенностью все форматы не читаемы для человека. А вот при умеренной вложенности, на мой взгляд yaml удобнее всего читать. IMHO

Возможно дело ещё в том, что я кроме случаев использования helm не шаблоню ямл, а в большинстве случаев генерирую его программно. А если пишу или правлю руками, то использую кавычки почти всегда когда точно не уверен. Простые правила, но видимо благодаря ним я до сих пор не испытываю ненависти к ямлу, хотя от коллег часто слышу.

Наконец кто-то это сказал вслух. Yaml это исчадие ада, не читаемое, не удобное, но обросшее мифами, что оно якобы читаемое и удобное. Я не знаю насколько у людей должна отсутствовать собственная точка зрения, когда им показывают откровенно плохую вещь и говорят что она хорошая, потому, что её автор написал, что она хорошая и кто-то на конференции тоже сказал, что это хорошо. Нет это плохо. Это было очевидно для меня с момента его появления, я избегаю его везде, но объяснять людям верующим в прекрасные технологии, что эти технологии дерьмо нет накакого желания, вера аргументами не бьётся. И чем больше я вижу как со временем мои предположения оказываются верными, тем больше я доверяю себе, а не докладчику со смузи на очередной модной конференции, у которого из аргументов только awsome, flexible, designed for humans

Yaml не хватило схемы вместо версии парсера, как у JSON. Большая часть проблем с валидацией бы отпала.

Предлагаю в качестве альтернативы рассмотреть также JSON5.

YAML мог бы стать тем самым остро нужным "стандартом JSON с комментариями". Вместо этого он стал вот этой вот огромной химерой, которая ухитряется быть менее читаемой и интуитивной чем сам JSON, который он в теории должен был улучшить. Отвратительно.

Вот упомянутый выше JSON5 выглядит жизнеспособным.

Оборачиваешь строки кавычками и всё становится хорошо.

Ну вот, обещали Ada, а тут Python.

Причем истоки этого кошмара — в противоречивом ТЗ. Типа, сейчас мы сделаем формат, который будет одновременно человекочитаемым, иметь произвольную древовидную структуру, типизацию на все случаи жизни... а еще модное на момент создания форматирование отступами. И многострочные строки, куда без них. На выходе естественно ужастик со слоганом "они думали, что страшнее XML ничего нет... " :)

томл вместо ямла - это такое лекарство, которое хуже болезни, как виндовые ини-файл, только более прОклято.

rule of thumb для ямла очень прост - не злоупотребляйте опциональностью кавычек для строк и используйте { } если не уверены в синтаксисе мап/списков.

NestedText, кажется, нигде не упоминался.

Наверное, немаловажный нюанс - это область применения. JSON хорош там, где нужен стандартизированный и надёжный формат данных, т.е. почти везде. Тем не менее, в статье упоминается, что YAML задумывался как человекопонятный формат, который удобно писать руками, и есть масса рутинных ситуаций, где большинство описанных ТСом проблем никогда и не встретятся, а скорость и удобство ручной работы при этом в разы возрастёт.

Например, я работаю с October CMS, где CRUD'ы конфигурируются как раз простыми YAML-файлами. Изо дня в день приходится писать что-то вроде:

fields:
    is_active:
        label: 'foo.catalog::lang.products.fields.is_active.label'
        type: switch
        span: full
        default: true
        comment: 'foo.catalog::lang.products.fields.is_active.comment'
    vendor_code:
        label: 'foo.catalog::lang.products.fields.vendor_code.label'
        type: text
        span: auto
    category:
        label: 'foo.catalog::lang.products.fields.category.label'
        type: relation
        nameFrom: title
        span: auto
        emptyOption: 'foo.catalog::lang.products.fields.category.empty_option'
    title:
        label: 'foo.catalog::lang.products.fields.title.label'
        type: text
        span: auto

Аналогичный конфиг набивать руками в виде JSON или нативного массива в PHP гораздо сложнее и неудобнее. При этом за годы работы и тонны написанных конфигов я ни разу не встретился с каким-либо неочевидным поведением парсера YAML.

Мой вывод: каждый инструмент хорош на своем месте, если ты знаешь его особенности и можешь использовать его максимально эффективно.

Я правильно понимаю, что все перечисленные проблемы - всего лишь следствие того, что строки не обязательно заключать в кавычки?

Я удивительную вещь сейчас скажу, но объектную нотацию JavaScript можно писать прямо... на языке JavaScript. Таким образом, вы получаете и комментарии, и типизацию, и валидацию и все остальное, что потом элементарно можно преобразовать в обычный JSON. А еще, это все можно подключать в виде модуля, подсвечивать, тайпчекать и линтить в IDE, использовать асинхронные API прямо внутри... И лишних кавычек в ключах нет. Тут, конечно, встанет вопрос использования JS-рантайма, если вы, к примеру, пишете на питоне, но можно воспринимать этот рантайм как своего рода парсер...

Имхо json5 (или jsonc, не знаю точно, в чем отличие) покрывает практически все необходимости. И главное, это ведь просто литерал, который валиден в JS. Т.е. если взять какой-нибудь Prettier, отформатировать им литерал из js-файла и положить в json5-файл, то вот это он и будет один в один.

По сравнению с json, json5 опциональны кавычки для ключей словаря, есть комментарии, и завершающие запятые игнорируются. Парсится он так же быстро, как парсится json (если сравнивать библиотеки на C). Непонятно, почему бы в какой-то момент просто не взять и не сделать в json-парсерах дефолтную поддержку json5, это ведь ничего не сломает.

Действительно, а зачем специальные форматы если можно взять какой lua или python, но чтоб все переменные были неизменяемые.

Данный пост является нытьём и он более субъективен, чем мои обычные статьи.

Батенька, вы не умеете ныть про ямль, давайте научу.

Лет восемь-десять назад мне посчастливилось участвовать в локализации игры по популярному сериалу по не менее популярным книжкам.

Моей задачей было вынуть текст на перевод и потом переведённое засунуть назад.

То, что эти деятели писали игру на рельсах, оставим на их совести. В конце концов там есть до фига бэкэндов локализации, включая божественный геттекст. Но эти рыцари решили использовать симпл, то есть тупо ямльки. Их было в проекте что-то около 2054 штук. Валидатором (самым добрым из) признаны были валидными 2 (прописью: два блин!) из 2054. Остальными ни одного. И я руками писал парсер невалидного ямль и рассоватор обратно переведёнышей.

Ямль идиотский формат, но люди тупее и злее.

Был (да и есть) такой простой и хороший формат: cfg. Поддерживается стандартной библиотекой libconfig. Незаслуженно забыт и здесь никем не упомянут.

Почему никто не рассматривает S-expressions?

(server_config
    (port_mapping ;; Expose only ssh and http to the public internet.
        "22:22" "80:80" "443:443")
    (serve
        "/robots.txt"
        "/favicon.ico"
        "*.html"
        "*.png"
        "!.git" ;; Do not expose our Git repository to the entire world.
    )
    (geoblock ;; The legal team has not approved distribution in the Nordics yet.
        dk fi is no se)
    (flush_cache
        (on push memory_pressure)
        (priority background))
    (allow_postgres_version "9.5.25" "9.6.24" "10.23" "12.13")
)