Comments 186
Ну, с двоеточием, по-моему, все знают. И, к тому же, насколько я знаю, - 22:22
в любом случае не спарсится как "22:22"
, а даст { "22": "22" }
.
Вот про "Норвегию" не знал, поэтому автора плюсую. :)
Кратчайший ликбез по сабжу, "Learn X in Y minutes, where X=yaml" - это yaml-документ в 200 строк.
Про "yes/no is boolean" там есть.
Почитайте, может еще что новое для себя узнаете )
Зачем изучать сложное, если есть простое?
Например, формат Tree, который проще и нагляднее всех названных в статье. Изучается за пару минут. Парсер пишется за час.
Я знал, что увижу этот комментарий как только прочитал заголовок статьи
Я смотрю на YAML и мне больно.
Я смотрю на Tree и думаю, что YAML был не так уж и плох.
P.S.
Почему по ссылке утверждается что JSON нельзя парсить поточно? Я не знаю есть ли такие парсеры или нет, но чисто концептуально я не вижу проблем написать такой. В чем конкретно там проблема-то?
Как я понял - в том, что файл в любой момент может закончиться с незакрытым объектом, и тогда весь результат разбора летит в мусор.
С тем же успехом можно говорить, что в YAML встретится невалидный синтаксис и результат разбора пойдёт в мусор.
И тут мне вспомнилось, как в не самой незаметной и мелкой игре Insurgency: Sandstorm не менее полугода жил баг: настройки разгрузки постоянно слетали в дефолтные, т е. настроишь для инсурга-снайпера штук 5 профилей, и для остальных ролей не меньше, а при следующей загрузке игры там пустота. Полгода так было, не меньше. Все плакали. Игра на движке UE4, файлы конфигураций в JSON. Лично я сначала написал батник, который тупо копировал JSON с сохранёнными профилями на место файла профилей перед запуском игры. Но это достало в конец, и я начал исследование проблемы: вносишь правки в профиль, закрываешь игру, копируешь файл профилей в сторону, запускаешь игру - профили слетели. Штош, и новый файл профилей в сторону. Потом просто парсишь профили - вуаля, новый профиль - просто дефолтный валидный JSON, а в твоём файле профилей оказывается незакрытой одна скобка. Ставишь скобку в нужном месте, файл скармливаешь игре - хоба, игре этот файл нравится, профили не слетают. Просто движок парсил невалидный JSON, и, напоровшись на ошибку, заменял его дефолтным валидным файлом. Написал багрепорт, через неделю поправили. При том, что я не программист и вообще в IT так и не влился.
Полгода был в проде этот баг, Карл. О нём писали всё, включая разрабов, которые в чейнджлогах новых патчей писали, что да, мол, есть такая проблема, до сих пор не вылечили.
После этого случая стал подозревать, что в игростудиях процент нерукожопов такой же, как везде - не более 10-15 :)
С тем же успехом незакрытый тег может быть в XML, но поточные SAX парсеры были чуть ли не с момента создания стандарта.
всё прекрасно json парсится поточно
Что конкретно там написано каждый может почитать сам: https://github.com/nin-jin/slides/tree/master/tree#поточная-обработка
А Робинович вам и не такое напоёт.
Там голословное уважением и ничего для подтверждения. Поточный xml используется в jabber, ничего не мешает поточно читать JSON.
В том же JSON.NET есть JsonReader который позволяет читать по одному токену, и если надо целиком объекты, можно прочитать файл любого размера условным кодом:
var serializer = new JsonSerializer();
var reader = new JsonTextReader(...);
reader.ReadStartArray();
while (reader.Read() && reader.TokenType != EndArray)
{
var myObject = serializer.Deserialize<MyObject>(reader);
...
}
Если на главном уровне это список объектов, то парсер который выдаёт по объекту за раз волне реален и удобен. Если у вас мапа и в одном из полей огромный список, то апи не будет простым. А если у все весь файл это одна строка, то парсер подавится, хотя это уж слишком крайний случай.
Кейс со списком на мой взгляд это самый распространённый для огромного джейсона. Хотя это случай можно заменять на формат https://jsonlines.org/ . Парсер легко делается на базе обычного парсера и читалки строк вашего языка програмирования.
Изучается за пару минут
...если ты его автор.
Мне он напоминает помесь питона и перла, причём самых плохих их сторон: вложенность через отступы (когда при копи-пасте можно потерять пробелы/табы и потом не понимать, где же уехал отступ) и обилие небуквенных символов (типа $,/,@,\) для обозначения разных структур. И в лучших традициях перловских однострочников, всё это write-only вещь.
Зависит от инстирументов.
У меня IDE вечно деформирует yaml при вставке в yaml файл.
А вот с Питоном всё норм.
Не выдумывайте, при копипасте отступы никуда сами не уезжают. Пунктуация есть в любом языке. Формат tree имеет лишь один спецсимвол - \
. Язык json.tree добавляет ещё 3: /
для списков, *
для словарей и -
для комментариев. Всё.
Вот каждый каждый каждый раз при копировании больших кусков у меня первая строка остаётся с правильным отступом, а все остальные на -1 отступ. Vs code
Я уже просто привык и даже не замечаю, как постоянно правлю это. Но сколько раз я попадал на невалидный yaml из-за этого
Это потому что вы вставляете в конец строки, а не в начало. Надо ставить каретку в начало, вставлять код и табом регулировать его общий уровень отступов.
То есть, если не регулировать - отступы всё-таки именно что "сами уезжают"?
Блин, ну это жесть какая-то. Каждый раз на это тратить время. Мне проще выделить все последующие строки и нажать таб. Но в любом случае, без дополнительных действий просто так не вставляется
Вам в любом случае надо тратить время на адаптацию вставленного кода. Благо массовая регулировка отступов делается за секунду. А если вы намекаете на автоформатирование, то при разбалансировке скобочек, оно такого накреативит, что порой потом пол часа приходится исправлять.
пол часа приходится исправлять
Три действия: отменить переформатирование, добавить пропущенную скобку, применить форматирование. И это только в тех случаях, когда ошибка уже была совершена при копировании.
Отменить форматирование со всеми правками, сделанными пока не заметил косяк.
Долго искать место, где и какой не хватает скобки, долбясь глазами в кривое форматирование.
Делать правки с пропущенной скобкой? В файле куча ошибок будет, какие правки?
Но вообще разговор был про блоки отступами. Не скопировал скобку - вылезет ошибка, ты быстро поправишь. Но если блоки только отступами, то никто не подсветит тебе корявый отступ. А некоторые ИДЕ ещё и форматируют при вставке, что только усугубит ситуацию.
От скопипащенного кода почти всегда куча ошибок, пока вы не адаптируете код к контексту.
Если блоки отступами, то корявость ты видишь сам, даже без подсветки.
Если блоки отступами, то корявость ты видишь сам, даже без подсветки.
Но автоформатирование и подсветка синтаксиса решают описанные вами проблемы скобок. Не очень понимаю, зачем вы с этим спорите.
Я чаще копирую код из этого-же файла, где контекст уже есть. Фигня в том, что блоки отступами порождают совершенно новый класс проблем.
![Как продолжить структуру? С какого места надо копировать и как вставлять, чтобы у child2 был свой child с именем? Как продолжить структуру? С какого места надо копировать и как вставлять, чтобы у child2 был свой child с именем?](https://habrastorage.org/getpro/habr/upload_files/fe1/582/0fb/fe15820fb92bba25768830a1c74f5cb9.gif)
Такая же проблема может быть и в условном питоне, где ты вставляешь какой-нибудь блок, и код валидный, но делает не то что надо.
> Если блоки отступами, то корявость ты видишь сам, даже без подсветки
Полагаться на слабую плоть, которая может устать и не заметить косяк, когда рядом есть чудо-машина? Ну уж нет. Я что, зря деньги платил?
Если блоки отступами, то корявость ты видишь сам, даже без подсветки.
Это если с 8 пробелов на 0 выскачило, а вот если с 8 на 6 и еще в схеме которую ты не очень хорошо знаешь, то не особо и видно.
Оцените три ключа spec в https://kubernetes.io/docs/concepts/workloads/controllers/cron-jobs/
Не стоит использовать пробелы для отступов.
Оценил: многочисленные spec тут явно лишние.
Я бы переписал как-то так:
![](https://habrastorage.org/getpro/habr/upload_files/f66/945/f16/f66945f1603853f1f00815d9b2e8b9e2.png)
Оценил: многочисленные spec тут явно лишние.
Не лишние. В данном yaml описаны 3 вложенные друг в друга сущности:
На верхнем уровне находится CronJob.
В spec.jobTemplate CronJob'ы находится описание Job'ов которыми этот CronJob будет управлять.
В spec.template Job'ы находится описание Pod'ов которыми данная Job будет управлять.
В xml это были бы 3 разных spec из разных namespace'ов, но xml это же по-старпёрски, поэтому его никто не использует :(
А то, что вы написали - это совсем другая модель, в которой отсутствуют концепции Pod и Job, в которой CronJob напрямую управляет контейнером (причем одним), в которой нет метадаты и т.д.
Это пока ты не копируешь код с табами в код со спейсами.
Причем отдельный кайф когда ты вставляешь код, который должен быть вложен.
Делать правки с пропущенной скобкой? В файле куча ошибок будет, какие правки?
Вы предполагаете, что после вставки и до того момента, как выяснится, что закралась ошибка — с файлом вообще ничего никогда не происходит?
Очень наивно.
Но если блоки только отступами, то никто не подсветит тебе корявый отступ
Перейдите уже с notepad.exe хотя бы на sublime…
По совету проверенных камрадов перешёл на сублайм vscode. Попробовал язык с отступами и вставку там. Хочу сделать копию child внутри ещё одного child. Но что-то никак не выходит это сделать простым копипастом. Проблема в том, что любой из вариантов после копипаста валидный, но не правильный для меня.
![Да как тебя копировать? Да как тебя копировать?](https://habrastorage.org/getpro/habr/upload_files/c28/fa1/075/c28fa10754b1bdbc98c848587d490c04.gif)
Попробовал поганый язык со скобками, там если что-то скопировать лишнее, почему-то сразу видно ошибку.
![](https://habrastorage.org/getpro/habr/upload_files/df9/c14/6f5/df9c146f51c7e13bd6714b008d142125.gif)
А если попробовать воссоздать проблему, аналогичную ямловской, то она почему-то не воссаздаётся. Там таких проблем нет как класс.
![](https://habrastorage.org/getpro/habr/upload_files/fea/b72/b3f/feab72b3f9e41c9f5b255c7aa8937709.gif)
Но ведь каретка стоит в правильном месте - внутри объекта, куда надо вставить. Это же бред, гнать её в начало строки, тратить на это время, потом отступами вручную регулировать правильность отступов. Если вложенность большая - это просто ад.
В случае жсона, после вставки не будет никакой неоднозначности. А для форматирования я просто жму комбинацию клавиш, и всё, документ отформатирован правильно.
Учитесь пользоваться редактором, а не жалуйтесь, что ваши привычки к костыля от другого типа языков сюда не подходят.
В жсоне со скобками всё копируется и вставляется нормально в любой ситуации. Чтобы скопировать что-то из ямла с отступами нужно прикладывать доп. усилия.
Но костыли именно в жсон, ага.
А вы с какой целью врёте? Думаете есть кто-то, кто не сталкивался со сломанным из-за запятой и криво отформатированным из-за несбалансированных скобок json?
Сталкивался. И сразу получал ошибку. В случае ямлов/tree код в большинстве случаев будет валидный, но неправильный с точки зрения пользователя.
При отсутствии схемы (а иногда даже с её наличием) это куда хуже, так как порой можно потратить кучу часов за дебагом. Это что-то на уровне js-овского неявного преобразования `'1' + 1`. И это не лечится, это фундаментальная проблема таких форматов.
Обстоятельный подход, респект.
В саблайме новые строки маркируются слева, рядом с номером, полоской, поэтому зрительно потерять свежую вставку довольно сложно. Есть (был для 3 точно) и плагин для маркировки несохраненных строк.
На первой картинке вы забываете оттабить скопированный текст, хотя на второй поставить запятую — не забываете.
То есть, в одном случае вы пренебрегаете форматом, в другом нет — и это вопрос лишь практики и упрямства, а не недостатка формата.
На второй же ошибку видно только если у вас и начало и конец в пределах даже не поля зрения, а непосредственно области вставки: даже в пределах одного экрана но парой десятков строк ближе к центру блока вы бы ее наверняка пропустили.
Ну и третья картинка явно иллюстрирует разное и неочевидное поведение редактора касательно отступов — тут, скорее, в багтрекер писать надо.
На первой картинке вы забываете оттабить скопированный текст, хотя на второй поставить запятую — не забываете.
То есть, в одном случае вы пренебрегаете форматом, в другом нет — и это вопрос лишь практики и упрямства, а не недостатка формата.
Что значит оттабить? Ведь каретка при вставке находится в нужном месте (я хочу добавить поле, так что каретка на уровне полей объекта child2), я готов вставить объект в нужное поле, но нет, вставка проваливается. Нажатие таба не починит ничего. Или мне надо нажать shift+tab, привести скопированный текст в начало строки, потом скопировать, а потом вернуть текст на место?
И это именно что проблема формата, и вот почему. Каждый отступ - это по-сути открывающая скобка. И когда я копирую из глубокой структуры с несколькими отступами, то выходит, что я копирую несколько открывающих скобок (поставлю точки вместо пробелов для наглядности)
..child:
....name: 'child1'
....child:
......name: 'child2'
Структура, которую я хочу скопировать, выглядит так
child:
..name: 'child2'
Это аналогично вот такому куску json: `"child": { "name": "child2" }`
Но из-за отступов я не смогу скопировать именно такую структуру. Я копирую либо вот так (если каретка при копировании стоит в начале поля)
child:
......name: 'child2'
Это аналог вот такого json: `"child": { { { "name": "child2" } } }`
Либо вот так (когда каретка стоит в начале строки)
....child:
......name: 'child2'
Но это аналог вот такой записи `{ { "child": { "name": "child2" } } }`
То есть в YAML и других языках с отступами нет простого способа скопировать вложенную структуру с правильным соблюдением этой структуры. Один из способов правильно скопировать и вставить такой:
Выделить нужный кусок
Пригнать самый левый его кусок к началу строки нажатием shift+tab
Скопировать
Вернуть текст на место
Вставит в нужное время
Не очень удобно. Другой - вставлять в начало строки. Но если надо вставить одну структуру в другую, то потом надо самому правильно выставлять отступы вручную. Это тоже не очень удобно
На второй же ошибку видно только если у вас и начало и конец в пределах даже не поля зрения
У меня везде стоят такие настройки, что, если в файле ошибка, то он подсвечивается красным на вкладе, в дереве файлов. В самом файле есть "карта кода", слева, там все ошибки. Пропустить ошибку сложно
![Все ошибки видны сразу Все ошибки видны сразу](https://habrastorage.org/getpro/habr/upload_files/c13/8bb/46c/c138bb46c9c950d4149712a3e06b0802.png)
Что значит оттабить?
Выровнять, для формата с выравниванием
И это именно что проблема формата
Ну, в таком случае, запятые и скобки — проблема формата json, вопрос исчерпан: вот вам два формата с разными проблемами, выбирайте, какмие вам решать привычнее.
Вообще вы очень странно из приспособленности редактора к формату со скобками и его неспособности работать с отступами выводите достоинства и недостатоки формата.
Это то же самое, что сказать, что писсуар плох, потому что в него нельзя по-большому.
если в файле ошибка, то он подсвечивается красным на вкладе
Скриншот слишком мыльный и маленький, но если вы заметите ошибку заглянув в секцию импорта в начале другого файла — то у каджита для вас плохие новости: этот файл надо еще открыть, и открыть в начале — а не посередине.
Да, есть дерево. Но чтобы это работало с деревом, файлы должны быть жирными (и вы перестанете видеть ошибку в файлах), чтобы видеть ошибвку в файлах вам надо растаращить дерево так, что в нем подсвеченные файлы уедут из области видимости вообще.
В общем, работать это будет ненадежно и отнюдь не сразу.
Из всех имеющихся редакторов, только Idea нормально вставляет yaml-куски как надо. VSCode и Sublime вставляют неправильно. Собственно, статья именно про это - ямл очень проблемный. Если для работы якобы более простого формата для пользования людьми, нужно пользоваться только определёнными редакторами, потому что другие не могут нормально реализовать его странный функционал, то не такой уж этот формат нормальный. Как минимум, он плох для людей, раз вызывает проблемы на ровном месте.
в таком случае, запятые и скобки — проблема формата json
Да, с одной стороны проблема. Но с другой, скопировав неправильно кусок жсона или вставив его в неположенное место, мы получим ошибку. А вот с в случае с ямлом мы скорее всего получим валидный ямл, но не верный для нас, и отловить эту ошибку будет сложнее.
Скриншот слишком мыльный и маленький
Скриншот был о том, что я вижу ошибку даже в самом длинном файле сразу, даже если мой экран далеко от места ошибки. Если честно, я удивлён, что надо мотать до места ошибки, чтобы увидеть её наличие. Я думал, во всех нормальных редакторах ошибочное место видно из любого места в файле, и переход к ошибке очень простой.
Пфхм.
Следите за руками:
только Idea нормально вставляет yaml-куски как надо. VSCode и Sublime вставляют неправильно. Собственно, статья именно про это — ямл очень проблемный.
Выходит, если notepad не подсвечивает синтаксис json, то json проблемный. А в sublime или vscode — не проблемный. Хопа — проблемный, хопа — не проблемный.
Ну, это немножко ы-ы-ы.
Но с другой, скопировав неправильно кусок жсона или вставив его в неположенное место, мы получим ошибку
А вот не факт, отнюдь.
Из-за отсутствия видимой иерархии, без принудительной преттификации перед вставкой легко промахнуться.
Скриншот был о том, что я вижу ошибку даже в самом длинном файле сразу, даже если мой экран далеко от места ошибки.
На нем с трудом можно разобрать коротусенький питоновский файл, наполовину состоящий из импортов.
как это должно иллюстрировать процитированное — для каджита остается полной загадкой.
Выходит, если notepad не подсвечивает синтаксис json, то json проблемный. А в sublime или vscode — не проблемный. Хопа — проблемный, хопа — не проблемный.
Другая возможная интерпретация той же цитаты: если один формат корректно обрабатывает большинство редакторов, а другой - только один, вероятно, первый формат менее проблемный, чем второй.
как это должно иллюстрировать процитированное — для каджита остается полной загадкой.
Через факт наличия красной подсветки ошибки, я так понял. Для неё вообще не принципиально, что за файл используется в качестве примера.
Другая возможная интерпретация
И все они являются подменами вида плохо поддерживаемый где-то ⇒ плохой. Только одна приведена в качестве иллюстрации (и гиперболизирована для наглядности), а другая — на сурьёзных щщах.
Через факт наличия красной подсветки ошибки
Там просто не понятно, куда смотреть, и от замыла вытекают глаза.
Да и речь шла о большом куске кода, а там реального кода и на полэкрана не набралось бы — странно иллюстрировать проблему больших чисел маленькой выборкой.
Ок, вот скриншот побольше. Наличие ошибки (я там запятую удалил) видно в 3-х местах: слева на карте кода (которая была на предыдущем скрине, поэтому там размыто всё), в полосе прокрутки и на вкладке. Так что если уж и пропустил запятую/скобку/кавычку при копировании, заметить это просто
![](https://habrastorage.org/getpro/habr/upload_files/dc1/ff8/f46/dc1ff8f46277cd6e20c413f6e6a4bd64.png)
Спасибо, теперь стало гораздо яснее, о чем вы говорили.
Установил code-oss, открыл какой-то древний grafana dashbord.
Копирование рандомных кусков json в рандомные места показало, что:
- дупликация ключей подкрашивается не красным а желтым (ну да, все равно заметно — удобно)
- индикатор ошибки указывает не на место, где случилась ошибка, а на место, где поломался парсер — в том числе далеко за пределами экрана, и если не приглядываться то это легко пропустить
- легко и непринужденно вставляется строчка или блок не туда и json остается валидным
Что, собственно, было очевидно с самого начала, потому что вы выбирали узкоспецифичные и граничные случаи.
И проблема, на поверку, снова свелась не к тому, что yaml такой плохой, а к нерепрезентативной и смещенной выборке и кривой поддежке в самом code.
А работает ли в VSCode вертикальное выделение текста (выделение мышкой с нажатым Alt)?
Если да, то быть может поможет
Не знаю поможет или нет, но можно установить плагин YAML by RedHat
Как подразумевается работа, например, с curl?
curl -X POST https://site -d {"login":"login","password":"pwd"}' -H 'Content-Type: application/json'
Только не нужно. Сразу же с самого начала автор не указывает, для какой области применения формат, и, видимо, не понимает разницы. Для сериализации одни требования (и здесь лучше всего подходит бинарный CBOR, расширяемый, Интернет-стандарт, машине удобно), для файлов конфигурации другой, для написания документов типа электронных книг - третий (XML всё еще неплох в этой сфере, хотя SGML был лучше).
Потом идёт синтаксически значимый whitespace, причем еще и с разными значениями для пробела и таба - на этом месте проклянут все, кто после cron и make видел Tuxedo. Причем не учитывается очевидная вещь: по скобкам не только понятно машине (и позволяет отформатировать как надо автоматически), но, главное, удобная навигация для человека (нажатие % в vim для перехода на парную).
В общем-то этого уже достаточно, чтобы выкинуть в помойку, но вещь, которая не лежит на поверхности - это отвратительная модель данных, то есть её отсутствие в принципе. Как насчёт типов данных? Хотя бы тех самых минимальных, что в JSON - разделения на строки и числа? А ведь надо, если мы собрались конкурировать с JSON, уметь передавать еще и бинарные данные (в JSON для этого костыляют base64, CBOR проблемы не имеет) - в то время, как нет даже банальной поддержки многострочности, вместо этого предлагается массив строк, то есть лишние телодвижения в коде.
Я конечно понимаю, что Everything Is A String можно подать как фичу, но тогда это надо уметь сделать правильно - например, как в Tcl.
В общем, неуд.
Ещё один мастер диагонального чтения..
Сразу же с самого начала автор не указывает, для какой области применения формат, и, видимо, не понимает разницы.
Так расскажите же в чём разница.
Для сериализации одни требования (и здесь лучше всего подходит бинарный CBOR, расширяемый, Интернет-стандарт, машине удобно)
Tree - бинарный формат, расширяемый, машине удобно.
для файлов конфигурации другой
Конфиги на Tree прекрасно читаются и пишутся человеком, благодаря чёткому пониманию, как оно парсится, отсутствию лишней пунктуации, и невозможности наговнокодить в одну строку.
для написания документов типа электронных книг - третий (XML всё еще неплох в этой сфере, хотя SGML был лучше)
А xml.tree ещё лучше.
Потом идёт синтаксически значимый whitespace, причем еще и с разными значениями для пробела и таба - на этом месте проклянут все, кто после cron и make видел Tuxedo.
Хз, какое отношение к теме имеет этот Tuxedo, но пробелы так-то везде синтаксически значимы. Даже в написанном вами тексте, если убрать пробелы - получится ерунда. Tree не допускает больше одного пробела подряд. В других языках обычно серийные пробелы удаляются форматтерами, или ругаются линтерами. А в XML и HTML они даже влияют на DOM и получение из него строк.
по скобкам не только понятно машине (и позволяет отформатировать как надо автоматически), но, главное, удобная навигация для человека (нажатие % в vim для перехода на парную).
Сколько я видел автоформаттеров - такая порнография неудобочитаемая получается, что лучше не надо. Сами себе создали проблему с форматированием абы как, потом решаете её костылиями-автоформаттерами и костылями-хоткеями, а потом ждёте от всех языков привычных вам проблем с привычными вам костылями. А попробовать пожить без костылей - боитесь, и выдумываете несуществующие проблемы.
Как насчёт типов данных? Хотя бы тех самых минимальных, что в JSON
А ведь надо, если мы собрались конкурировать с JSON, уметь передавать еще и бинарные данные (в JSON для этого костыляют base64, CBOR проблемы не имеет)
В Tree тоже с этим никаких проблем. Засунули бинарник - получили бинарник.
нет даже банальной поддержки многострочности, вместо этого предлагается массив строк, то есть лишние телодвижения в коде
Нет там никаких лишних телодвижений. Текстовое представление любого узла - многострочный текст.
Я конечно понимаю, что Everything Is A String
Вы нихрена не поняли, но бросились с апломбом строчить комментарий, вводить людей в заблуждение, и менторски выставлять оценки. Everything is Raw Binary Data.
А теперь проявите минимальное уважение к чужому труду по разработке, полевым испытаниям, тулингу и подробному разжёвыванию, и прочитайте статью внимательно, без предубеждения, что автор идиот, раз сделал так, как посчитал правильным, а не так, как вы лично привыкли.
Так расскажите же в чём разница.
В следующем же предложении.
Tree - бинарный формат, расширяемый, машине удобно.
Чушь. Пример задания бинарной переменной, состоящей из пяти переводов строк и двух табов с пробелами - в студию.
Конфиги на Tree прекрасно читаются и пишутся человеком, благодаря чёткому пониманию, как оно парсится, отсутствию лишней пунктуации, и невозможности наговнокодить в одну строку.
Для человека они неудобны. Причем именно в силу отсутствия пунктуации.
Хз, какое отношение к теме имеет этот Tuxedo,
Видно отсутствие опыта. Там в ud32 поля "имя значение" на каждой строке должно быть разделено ровно одним табом, должна быть пустая строка в конце, и люди регулярно напарываются на, например, лишний пробел - которого попросту не видно.
но пробелы так-то везде синтаксически значимы. Даже в написанном вами тексте, если убрать пробелы - получится ерунда. Tree не допускает больше одного пробела подряд. В других языках обычно серийные пробелы удаляются форматтерами, или ругаются линтерами
Это фигня. В любом нормальном языке whitespace (а не пробелы) НЕ являются синтаксически значимыми, их можно насыпать сколько угодно для удобства форматирования.
Сколько я видел автоформаттеров - такая порнография неудобочитаемая получается, что лучше не надо. Сами себе создали проблему с форматированием абы как, потом решаете её костылиями-автоформаттерами и костылями-хоткеями, а потом ждёте от всех языков привычных вам проблем с привычными вам костылями. А попробовать пожить без костылей - боитесь, и выдумываете несуществующие проблемы.
Перевожу: "в моем (не очень обширном) опыте мне попадались исключительно плохие автоформаттеры". Лично я, например, ими не пользуюсь как отдельными тулзами, но возможность автоматически редактором поправить форматирование (читай, отступы) после той же копипасты - ценю.
json.tree
А xml.tree ещё лучше.
Рассматривается базовый формат, а не нашлёпки.
Нет там никаких лишних телодвижений. Текстовое представление любого узла - многострочный текст.
Телодвижения значат, что вместо парсера работа переложена на программиста, который пишет код работы с данными. Даже массивов нет - дайте-ка массив из трех четырехстрочных элементов, например. Валидность проверять опять же руками потому что парсеру нечем - у него крайне скудный синтаксис.
Вы нихрена не поняли, но бросились с апломбом строчить комментарий, вводить людей в заблуждение, и менторски выставлять оценки. Everything is Raw Binary Data. А теперь проявите минимальное уважение к чужому труду по разработке, полевым испытаниям, тулингу и подробному разжёвыванию, и прочитайте статью внимательно, без предубеждения, что автор идиот, раз сделал так, как посчитал правильным, а не так, как вы лично привыкли.
Про фейковую бинарность я уже привёл выше. Статью я читал целиком (пропустил только JS-часть после середины). Понял же я главное - автор не имеет ни эрудиции, ни опыта, зато обладает неудержимым NIH-стремлением сделать велосипед с квадратными колесами и поведать о нём миру. Причем критику не то что не воспринимает, а даже не понимает (как видно и по соседним веткам). Увы, уважать такое я никак не могу.
Чушь. Пример задания бинарной переменной, состоящей из пяти переводов строк и двух табов с пробелами - в студию.
Тут можно найти int32 от 0 до 255. Дальше сами.
Рассматривается базовый формат, а не нашлёпки.
То есть про концепцию отделения языков от формата, лежащую в основе XML, вы не в курсе.
Даже массивов нет - дайте-ка массив из трех четырехстрочных элементов, например.
То есть статью вы не прочитали, но ждёте, что я вам тут её в комментариях по кусочкам буду пересказывать.
Валидность проверять опять же руками потому что парсеру нечем - у него крайне скудный синтаксис.
Валидность проверяется интерпретаторами языков. Есть готовые интерпретаторы. Но благодаря строгости и простоте формата, легко написать свой.
Нет, для того, чтобы 22 считался ключом, после двоеточия должен быть пробел
А его заметно блин в редакторе???????
Буду знать, но я просто всегда если в "строке" есть двоеточие, то беру её в кавычки давно уже на автомате.
До сих пор никаких фатальных проблем с YAML лично не встречал, хотя регулярно с ним работаю. Формат, понятно, весьма расплывчатый, но говорить, что это прямо "ад" это слишком сильно. Расплывчатость формата можно считать данью некоторому удобству. Никто ведь не говорит, что JavaScript это ад только из-за того что там ;
опциональна. Или что PowerShell это ад, потому что в одних случаях можно просто перенести строку, а в других случаях нужен обратный апостроф, в одних случаях можно задать массив просто как 1, 2, 3
, а в других нужен полный синтаксис @(1, 2, 3)
(и кавычки, к слову, там тоже "опционально опциональны" :). В большинстве случаев везде работает простое правило "сомневаешься - не сокращай". Поставь просто лишние кавычки, скобки, точку с запятой и т.п.
Тоже неинтуитивное поведение, кстати. В большинстве языков пробел возле спецсимвола считается незначимым.
первый раз слышу, хотя годами работаю с docker-compose.yml
Всю жизнь говорил: умолчания — зло. Хочешь строковое значение — не выйоживайся и не экономь два байта, обрами кавычками.
Вот всегда то же самое хочется сказать при написании кода на python или конфигов на yaml - не выйоживались бы и ввели скобки. Сэкономили блин...
У меня была такая фигня лент надцать назад, когда телефоны были большими, а память — маленькой
Бяку три дня искали всей командой, пока прод простаивал. Смысл в следующем: жил-был код (сложное условие 1) if (сложное условие 2)
. В процессе жизни возникло новое условие, параллельное условию 1. Тот, кто менял код, естественно, написал (сложное условие 1) || (сложное условие 3) if (сложное условие 2)
. На следующее утро команда приходит и выясняет, что код что-то делает не так. Стали искать, какого, собственно, Цоя (изменений было больше одной строчки). Вся команда думала, что интерпретатор воспринимает вышеприведённую строчку как ((сложное условие 1) || (сложное условие 3)) if (сложное условие 2)
(то есть как и планировалось), и поэтому при поиске на неё даже не смотрела — "а чего тут может быть непонятного???" Но на самом деле оказалось, что строчка воспринимается как (сложное условие 1) || ((сложное условие 3) if (сложное условие 2))
, то есть всё совсем не так, как кажется.
С тех пор я навсегда зарёкся что скобки лучше поставить там, где не надо, чем не поставить там, где надо.
(За давностью событий в деталях могу ошибаться, но смысл был как раз в том, что if
приклеивался не к тому, к чему было надо.)
Вы перечислили DHall, cue, HCL. Но пропустили достаточно популярный jsonnet. Который точно также работает со структурами данных, вместо того чтобы шаблонизиоровать текст, и на мой взгляд мощнее перечисленных.
А вот шаблонить ямл как текст, как делает helm это конечно дичь. Я тоже в шоке что это обрело такую популярность.
А по поводу самого yaml. Да есть странности. Но я вот за всю практику (8 лет примерно) никогда не попадал на описанные проблемы. Всегда если сомневался просто использовал кавычки. Мне его читать удобнее, поэтому конфигам на ямле я рад. А вот указанные toml и xml мне читать гораздо сложнее, томл со средней и большой вложенностью совсем не в читаемую кашу превращается. Конечно наверное с большой вложенностью все форматы не читаемы для человека. А вот при умеренной вложенности, на мой взгляд yaml удобнее всего читать. IMHO
Возможно дело ещё в том, что я кроме случаев использования helm не шаблоню ямл, а в большинстве случаев генерирую его программно. А если пишу или правлю руками, то использую кавычки почти всегда когда точно не уверен. Простые правила, но видимо благодаря ним я до сих пор не испытываю ненависти к ямлу, хотя от коллег часто слышу.
Наконец кто-то это сказал вслух. Yaml это исчадие ада, не читаемое, не удобное, но обросшее мифами, что оно якобы читаемое и удобное. Я не знаю насколько у людей должна отсутствовать собственная точка зрения, когда им показывают откровенно плохую вещь и говорят что она хорошая, потому, что её автор написал, что она хорошая и кто-то на конференции тоже сказал, что это хорошо. Нет это плохо. Это было очевидно для меня с момента его появления, я избегаю его везде, но объяснять людям верующим в прекрасные технологии, что эти технологии дерьмо нет накакого желания, вера аргументами не бьётся. И чем больше я вижу как со временем мои предположения оказываются верными, тем больше я доверяю себе, а не докладчику со смузи на очередной модной конференции, у которого из аргументов только awsome, flexible, designed for humans
Я не знаю насколько у людей должна отсутствовать собственная точка зрения, когда им показывают откровенно плохую вещь и говорят что она хорошая, потому, что её автор написал, что она хорошая и кто-то на конференции тоже сказал, что это хорошо.
Сразу священными писаниями запахло :))
Я уже давно смотрю на технологии с точки зрения веры и религии. И у молодых программистов это сейчас кажется развито больше чем раньше, просто нужно это учитывать, сложность технологий растёт, необходимость делать выбор в ограниченные сроки без полного понимания остаётся, да еще и в пиар некоторые техи умеют лучше чем другие. Но вообще, как только ты предагаешь опцию про которую никто никогда не говорил на конференциях и не писал статей, сразу вопрос, а почему бы не поступить как вот там дядя говорил?
Да, всё так, это апелляция к авторитету.
С одной стороны да, а с другой меня всегда можно обвинить в https://ru.m.wikipedia.org/wiki/Склонность_к_подтверждению_своей_точки_зрения И простого решения кто прав неи. Все эти термины всегда обоюдоостры и играясь с ними можно вывернуть всё как угодно, всегда нужно видеть людей, их задачи и мысли, а не паттерны поведения.
Хотя я нашёл хак, как побеждать в апелляции к авторитету, например выступить на конференции и в споре ссылаться на свой доклад, тогда некоторых отпускает и они начинают разумно общаться не боясь что они сейчас, о боже, сделают что-то, что авторитетом не одобрено.
Меня лично отпустило, полосе того, как я пару раз особо не думая, вернувшись с конференции попытался на чистой инициативе затащить кое какие плюшки в проект)
В общем, оба раза закончилось это дело полным крахом, так что теперь я 7 раз думаю, а потом делаю. Но как мне кажется, это обычный нормальный здоровый путь из джуна в сеньоры, а потом и на пенсию)
Ну вот про пенсию тоже верно подмечено, и хочется не быть старпёром, а иногда такую ересь предлагают, что хоть вешайся. Но новые крутые штуки безусловно есть, особенно отметил бы прогресс в языках, typescript и rust показали как можно хорошо подумать, и сделать крутую вещь. А то, что coffeescript и ruby умерли, хотя хайпа в своё время подняли море, говорит о том что нужно подождать буквально лет 5 и ересь проветрится.
Я согласен с тем, что в Rust есть крутые идеи и процессе изучения у меня было ощущение, что наконец-то придумали "С++ здорового человека". И всё же попытки написать на нем что-то более или менее серьезное привели меня к мысли, что как-то не очень дружественен язык. В общем, удовольствия не получил, вернулся в свой С++ мирок и черпаю из Rust иногда вдохновение)
А вот про typescript согласен. При условии опыта работы с типизированными языками, typescript после JavaScript как глоток свежей воды в жаркий день)
Rust - концепт который показал, что так можно было. Я уверен что будущее системного программирования либо за тотальной переработкой раста или за его идеологическим наследником.
Мелькал Carbon не так давно на какой-то конфе) Чисто концептуально он мне понравился больше Rust, я бы поставил на него)
В FAQ Carbon прямым текстом написано If you can use Rust, ignore Carbon
Я вижу у раста несколько категории вещей, которые сделаны круто.
Управление памятью. Они первые, кто сделал то, что сделал и понять, насколько это круто-правильно и как можно было бы сделать по другому пока сложно. Нужны исследования и новые языки с другими попытками сделать так же, но по другому.
Система типов. Божечки, наконец-то не стали копировать ООП, дак-тайпинг или, прости лямбда, прототипинг. Сели, подумали и взяли хорошее из истории. Где-то получилось не очень, но в целом достойно твёрдой пятёрки и даже с плюсом.
Тулинг. Прям молодцы, что тулинг это для них одна из первоочередных задач.
Вот для понимания управления памятью нужно менять мозг, а за всё остальное рукоплещу.
Управление памятью. Они первые, кто сделал то, что сделал и понять, насколько это круто-правильно и как можно было бы сделать по другому пока сложно.
А вот с этого момента поподробнее можно? Интересно же.
наконец-то не стали копировать ООП, дак-тайпинг или, прости лямбда, прототипинг. Сели, подумали и взяли хорошее из истории.
И с этого тоже.
Про растовый borrowing, кажется, написано в любой рассказке про раст. Вкратце, нельзя просто так взять и отдать память на сторону. Памятью всегда кто-то владеет в течении какого-то lifetime. И по началу это создаёт огромную ментальную нагрузку. Плюс -- память не течёт, нет гонок и благолепие. Минус -- думать надо по другому.
Систем типов довольно много. Алгебраические типы (haskell, ocaml, ...), duck-typing (python, ...), прототипы (javascript, ...), классический [статический] ООП (c++, java, c#, ...). Нет абсолютно правильный системы типов, у каждой есть свои особенности и достоинства.
Система типов раста позволяет разнести данные и поведение. Есть структуры и есть реализации интерфейсов для этих структур. Но что интересно, поведение можно доопределить. Это похоже на кложурные протоколы. Можно взять существующий (встроенный, библиотечный) тип и реализовать для него интерфейс.
Вкратце, нельзя просто так взять и отдать память на сторону.
В общем, "ничего не понял, но было интересно".
Мануальчик какой-нибудь для внеклассного чтения не посоветуете?
rust book. Вот русский перевод: https://doc.rust-lang.ru/book/ch04-00-understanding-ownership.html
Только вот в современном мире:
малоактуально, но превозносится до небес
не люблю Go, но duck typing они сделали правильно, в прототипах тоже ничего плохого нет, если у программиста есть мозг. По обоим пунктам правильное решение - это скриптовый язык с динамической типизацией, а не возиться кучу времени с тем, что не может вменяемо сделать даже четыре двусвязных списка (типичная ситуация для принадлежности элемента в ядре).
Так что из объективно бесспорного хорош только тулинг.
...только сам Rust - как раз очень яркий образчик действия этих самых механизмов веры и религии.
Да, всё так, даже слово "холивары" не просто ирония, а по сути. К "больше чем раньше" я б добавил еще, что в индустрию пришло больше людей, что неизбежно означает падение среднего уровня - раньше доля профессионалов была больше.
Шол в жожоба адепт
Если из YAML выкинуть всё это говно непонятное и вызывающее UB - он лучше и читаемее JSON. Я использую их для конфигов своих сервисов, проблем не испытаываю, но при этом игнориую все эти доп. фичи. Выстрелить в ногу, конечно, возможности остаются, но сильно ограничены.
Типа как с оператором goto. Раз сам Дейкстра сказал что это зло значит зло.
Yaml не хватило схемы вместо версии парсера, как у JSON. Большая часть проблем с валидацией бы отпала.
YAML мог бы стать тем самым остро нужным "стандартом JSON с комментариями". Вместо этого он стал вот этой вот огромной химерой, которая ухитряется быть менее читаемой и интуитивной чем сам JSON, который он в теории должен был улучшить. Отвратительно.
Вот упомянутый выше JSON5 выглядит жизнеспособным.
Теперь у нас есть 14 стандартов (с)
YAML был разработан параллельно с JSON, а не как замена ему и появился примерно в то же время.
Поэтому было бы странно, если бы он стал "стандартом JSON", не являясь основанным на JSON.
То, что JSON документ является валидным YAML документом, было формализовано позднее, и в общем-то это заслуга простоты JSON, а не из-за того что YAML специально был придуман с оглядкой на это.
Оборачиваешь строки кавычками и всё становится хорошо.
Ну вот, обещали Ada, а тут Python.
Причем истоки этого кошмара — в противоречивом ТЗ. Типа, сейчас мы сделаем формат, который будет одновременно человекочитаемым, иметь произвольную древовидную структуру, типизацию на все случаи жизни... а еще модное на момент создания форматирование отступами. И многострочные строки, куда без них. На выходе естественно ужастик со слоганом "они думали, что страшнее XML ничего нет... " :)
Не вижу противоречий в этом ТЗ. Просто авторы ямла не справились с ним. Бывает.
В поисках волшебника найдёшь сказочника. Хорошее ТЗ это не перечисление всего хорошего что сделать надо и всего плохого, что не надо.
Тут в комментах выложили минимум 2 успешных выполнения этого тз.
Ну "модного форматирования отсутпами" ни в одном из них нет. И нет, я не к тому, что форматировать пробельными символами плохо само по себе. Просто в сочетании с другими требованиями оно порождает YAML.
"Я всю ночь не спал. Не мог заснуть! Всё думал, чем у вас восьмой инженер занимаетсякто выполнил эти условия кроме Tree?" /s
Вот, например, это загадочное кастование 1:30 в 90 как раз от слишком буквально понятого человекочитания. Это ж типа чтобы человек написал полторы минуты "по человечески", а парсер считал 90 секунд по компьютерному. Вместо того чтобы либо молча интерпретировать как строку, либо упасть с ошибкой. Но это же так фу-фу, недружественно.
томл вместо ямла - это такое лекарство, которое хуже болезни, как виндовые ини-файл, только более прОклято.
rule of thumb для ямла очень прост - не злоупотребляйте опциональностью кавычек для строк и используйте { } если не уверены в синтаксисе мап/списков.
NestedText, кажется, нигде не упоминался.
Непустой массив: после названия ставим двоеточие, а затем на каждой строке увеличиваем отступ и перед значением ставим маркер
-
:nonempty_arr:
- val1
- val2
Пустой массив: после названия ставим двоеточие и []
, иначе утиностипизирует в null:empty_arr: []
Да, я понимаю, что массивы можно писать и в одну строку, тогда как раз и будут нужны эти квадратные скобки:
nonempty_arr2: [val1, val2]
Но почему-то именно непустое объявление пустого массива меня сломало. С тех пор если я выбираю формат конфигов — то только pretty-printed JSON.
И как там, в pretty-printed JSON, непустое объявление пустого массива (а также объекта и строки) вас не смущает? Странно, что именно это вас «сломало».
А можно с примером что именно должно в нем смущать?
Пример смотрите в комментарии выше (на который я отвечал).
В комментарии DirectoriX не было примера такого массив в pretty-printed JSON. И, если я правильно понял что "непустое объявление пустого массива" означает необходимость писать "[]"... То что именно должно в этом смущать?
В JSON как и во всех нормальных форматах, есть синтаксис, которому нужно следовать независимо от того пустой массив или нет.
В YAML же, синтаксиса для массивов 2 (как минимум). при этом один синтаксис используется для массивов простых объектов И позволяет объявлять пустой массив, а второй синтаксис позволяет делать массивы сложных обхектов, НО не позволяет объявлять пустой массив. Что приводит к интересным моментам как, например, невозможность просто удалить строку с последним элементом массива (т.к. это сделает этот ключ равным null, ан е пустому массиву) и вместо этого необходимость переписать этот массив на однострочный синтаксис. А когда потом потребуется снова добавить значение - переписать обратно.
Такая несогласованность не может не "ломать" разработчика привыкшего к "форматам трезвого человека". А вот в JSON я что-то подобных проблем не припомню, отсюда и просьба привести пример.
И, если я правильно понял что "непустое объявление пустого массива" означает необходимость писать "[]"...
О том и речь. Но комментатора выше это смутило настолько, что он решил отказаться от yaml в пользу pretty-printed JSON, при том, что он от такого перехода вообще ничего не выиграл, ведь ровно то, что его «смутило» в yaml, присутствует и в pretty-printed JSON, только yaml, в отличие от этого, предлагает более удобный синтаксис в определённых ситуациях, а pretty-printed JSON — нет.
Есши перечитаете, то поймете, что комментатора выше смутило не просто [] для пустого массива, а слишком сильная разница в описании пустого массива и не пустого массива
Разницы никакой. Массив можно описывать либо «со скобками», либо «с отступами». Не нравится второй вариант — всегда используйте первый, в чём проблема? Да, второй вариант не покрывает всех возможных вариантов задания массивов, но такова плата за удобство. Кроме того, пустые массивы в реальной жизни встречаются кратно реже заполненных, так что и определяющим фактором в отказе от yaml этот факт тоже выглядит крайне странно.
В JSON недопустима висячая пунктуация, так что добавление/удаление последнего элемента списка при многострочном форматировании приводит к необходимости менять предыдущий элемент.
Под "последним" я подразумевал "последний оставшийся. Т.е.
"array": [
{"foo": 1}
]
"array": [
]
А вот в YAML удалив последний элемент из
array:
-foo: 1
мы получим
array:
что есть null а не пустой массив. И вместо этого нужно переключится на другой синтаксис массива
array: []
И когда после этого требуется добавить значение обратно - в JSON все так же логично и consistent, в вот в YAML мы не можем в этот пустой массив добавить новый `foo: 2` - для этого нужно переключаться обратно на многострочный синтаксис массива.
Так понятнее?
Это не очень большая проблема. Элементы массива можно описывать так:
"arr": [
1
, 2
, 3
]
Тогда при удалении последнего элемента массива не нужно трогать предыдущую строку.
Многострочный текст в pretty-printed JSON особенно хорош.
Тут, понимаете, скорее всего недоработка самого приложения. Если оно читает конфиг, который пишут руками (а YAML практически только для этого и используется), то оно должно в той или иной степени нормально обрабатывать различные "вольности" в этом конфиге, как, например, использовать разумное значение по умолчанию вместо пропущеного. В данном случае, лично я, даже не задумывась, в самом приложении просто сразу заменял бы null
на пустой массив.
любой парсер обязан допускать дубликаты ключей, поведение при этом не определено. А вообще я так тожеькомменты пишу иногда, но это не сработает если коммент нужно проставить в массиве.
Мне кажется, такого рода комментариям (поясняющим значения настроек) самое место в description в JSON схеме. По крайней мере, если не предполагается, что JSON-файлы будут редактировать в обычных текстовых редакторах, не умеющих эти пояснения из схемы подтягивать и отображать как подсказки.
А вот комментарии по поводу конкретных значений настройки ("тут мы поставили 3, потому что с 2 тормозит, а с 4 вылетает") да, только как-то так и писать. Но надо думать, как возможность их наличия в схему зашить...
Наверное, немаловажный нюанс - это область применения. 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.
Мой вывод: каждый инструмент хорош на своем месте, если ты знаешь его особенности и можешь использовать его максимально эффективно.
Однака yaml часто пытаются запихать туда куда он не лезет. И вообще общий вывод опыта программирования за уже почти 20 лет, ечли это сделано чтобы было удобно писать а не читать, получается плохо. Потому что мы чаще читаем чем пишем.
Я правильно понимаю, что все перечисленные проблемы - всего лишь следствие того, что строки не обязательно заключать в кавычки?
Да, но авторам было лень заключать строки в кавычки потому что именно это напрягало их в json. И они объявили войну кавычкам, изобрели это и проиграли.
Лень нажать одну кнопку? Воистину человеческая лень не имеет границ)
Я с вами полностью согласен. Но к сожалению некоторые программисты поражены такой вредной мыслью как: "если это одинаковое действие нужно повторять, то от него нужно избавиться" Там подключается миллион мифов что повторение действий это неэффективно, что это место для ошибки и нужно сделать так чтобы никакого повторящегося действия не было. Я встречал это когда при парсинге надо проверять аргументы или еще когда нибудь когда есть похожие куски кода которые хорошо бы оставить как естьа не пытаться обобщить, не все обобщения полезны. Толи это из Совершенного кода, толи из Рефакторинга вылезло, толи ещё откуда, но такое поверие весьма распостранено, хотя по моему мнению гораздо более вредно чем полезно.
Я удивительную вещь сейчас скажу, но объектную нотацию JavaScript можно писать прямо... на языке JavaScript. Таким образом, вы получаете и комментарии, и типизацию, и валидацию и все остальное, что потом элементарно можно преобразовать в обычный JSON. А еще, это все можно подключать в виде модуля, подсвечивать, тайпчекать и линтить в IDE, использовать асинхронные API прямо внутри... И лишних кавычек в ключах нет. Тут, конечно, встанет вопрос использования JS-рантайма, если вы, к примеру, пишете на питоне, но можно воспринимать этот рантайм как своего рода парсер...
я так и перешёл на то, что все конфиги у меня .js а не .json Отлично работает.
Не только JavaScript, но и в Python.
Хотя в Python чаще немного другой подход к таким конфигам. Там просто пишется файл который присваивает нужные переменные, константами или кодом.
Например:
- https://docs.djangoproject.com/en/4.1/topics/settings/
- https://www.sphinx-doc.org/en/master/usage/configuration.html
Имхо json5 (или jsonc, не знаю точно, в чем отличие) покрывает практически все необходимости. И главное, это ведь просто литерал, который валиден в JS. Т.е. если взять какой-нибудь Prettier, отформатировать им литерал из js-файла и положить в json5-файл, то вот это он и будет один в один.
По сравнению с json, json5 опциональны кавычки для ключей словаря, есть комментарии, и завершающие запятые игнорируются. Парсится он так же быстро, как парсится json (если сравнивать библиотеки на C). Непонятно, почему бы в какой-то момент просто не взять и не сделать в json-парсерах дефолтную поддержку json5, это ведь ничего не сломает.
В json5 спеке есть всякие NaN, +Inf, -Inf, которых может не быть в некоторых языках. Поэтому просто так везде добавить поддержку не получится.
Если сериализацию-десериализацию производить не просто так, а с учётом схемы — проблемой это не станет.
В каких языках нет IEEE754 и насколько они актуальны в 2023 году?
Хм… Сходу могу назвать SQL, где NaN/INF хоть и могут быть, но не являются флоатами/даблами в большинстве реализаций (Ну например MySQL… Ну или PostgreSQL, где это numeric).
Ещё ANSI C (Насколько я нагуглил). Но возможно ошибаюсь, нашёл только для C++.
P.S. Ну я то не спорю, но мне казалось всегда, что это довольно специфичные типы, которые хоть и являются частью системы типов (потомком флоата) большинства языков, но не могут быть представлены однозначной последовательностью битов в двоичном представлении. Ну, типа, как выглядит, например, -INF
в LE, чтобы его можно было записать в двоичном виде и потом прочитать на любом языке, получив тот же -INF
в качестве значения флоата?
Ну, типа, как выглядит, например,
-INF
в LE, чтобы его можно было записать в двоичном виде и потом прочитать на любом языке, получив тот же-INF
в качестве значения флоата?
А это разве не часть стандарта? Сам его текст найти в свободном доступе не удалось, но беглый гуглёж предложил вот такое описание:
For single-precision values:
Positive infinity is represented by the bit pattern 7F800000
Negative infinity is represented by the bit pattern FF800000
For double-precision values:
Positive infinity is represented by the bit pattern 7FF0000000000000
Negative infinity is represented by the bit pattern FFF0000000000000
То есть, как раз вполне конкретное битовое представление.
Так а почему в двоичном, если JSON текстовый? В бинарном CBOR, конечгно, порядок байт указан.
Действительно, а зачем специальные форматы если можно взять какой 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")
)
Потому что они по уровню синтаксиса как JSON, только ещё хуже в плане типизации и экосистемы.
Человеку сложно с ними работать. Вот даже вы запутались с тем, где оставлять закрывающую скобку. А в реальном коде часто можно встретить вереницы скобочек.
Почему-то в S-expressions обычно используется стиль, в котором закрывающие скобки находятся в конце последней строки, причём при закрытии нескольких списков подряд все скобки объединяются в одну кучу. В большинстве текстовых редакторов работать с таким представлением довольно неудобно — проще выносить закрывающие скобки в отдельные строки. Возможно, предполагалось, что будет использоваться редактор, обрабатывающий как отдельные элементы именно S-expressions, а не строки.
Это не только в S-expressions так, этой болезнью многие инструменты болеют...
Вечная проблема со скобками при многострочном форматировании - они только мешаются. Разместишь на отдельной строке - куча строк тратится впустую, код не влезает в экран. Закинешь на антресоль - валяются там кучей, что к чему не понятно, пока каждую не достанешь и не посмотришь. Решается это только одним способом - выносом мусора.
А можно не быть фанатом и использовать гибридные варианты. Я, например, часто так пишу:
call_some_function(arg, another_fn(
arg, arg,
arg,
));
До 3-х скобок без всякой подсветки читаются нормально, дальше уже лучше разносить по строкам
Тут важен не только уровень вложенности, но и является ли составной аргумент последним. Скажем, если добавить функции call_some_function третий аргумент — то без изменения форматирования читаться такое нормально уже не будет, несмотря на уровень вложенности всего в два.
Да, есть такое, но мы же в контексте про кучу закрывающих скобок друг за другом. Хотя иногда и так пишу, обычно это какие-то методы логгирования так устроены, что в середине текст, который нужно залоггировать, который форматируется отдельным вызовом, а вокруг какие-то параметры логгера
log(параметр_логгера, format(
"длинный-длинный текст с плейсхолдерами"
arg, arg,
arg,
), еще_параметр_логгера);
Потому что выросло поколение, которое не в курсе про Лисп.
Статья немного странная. Описаны нюансы YAML о которых стоит знать, но сходу определить, что этот формат плох, от автора весьма странно. Всё зависит от задачи. YAML с приходом DevOps стал очень популярен, и для этого есть причины. Для человека, который пишет конфигурации YAML оказался более читабелен и удобен, чем JSON. Так-же при diff в YAML будет видно явное различие, у JSON, только если он написан с pretty форматированием, с соблюдением whitespace. у YAML этой проблемы нету, т.к. структура файла изначально определена стандартом. JSON типизирован и предсказуем, у YAML есть нюансы. Всё зависит от задачи и реализации парсера/врайтера. Приложение, которое считывает конфигурацию из YAML рассчитывает на определённую модель данных, которые может конфигурационный yaml содержать, по этому особых проблем с использованием YAML я не вижу. Нюансы, которые могут возникнуть либо вы о них быстро узнаете, когда увидите, что конфигурация себя ведёт не правильно, но скорее всего с большинством описанных проблем вы даже и не столкнётесь.
Так-же при diff в YAML будет видно явное различие, у JSON, только если
он написан с pretty форматированием, с соблюдением whitespace. у YAML этой проблемы нету, т.к. структура файла изначально определена стандартом.
Это абсолютно неверно. Для YAML это выполняется при тех же условиях: pretty форматирование. Следующие два входных YAML-файла дают один и тот же список из 2 элементов:
- Hello
- World
и
['Hello', 'World']
Чуть сложнее? Пожалуйста:
a:
aa: bb
cc: dd
b:
pp: qq
ss: tt
a:
{aa: bb, cc: dd}
b: {pp: qq,
ss: tt}
В последнем примере отступы сломаны, и ничего. Причём это самые основы, от описанного тут 1.1 vs 1.2 vs 1.2.2 не зависит.
Как известно, любой JSON документ является валидным YAML-документом. С pretty-форматированием или без него, пофиг, он валиден и должен читаться.
С другой стороны, дифф вам может показать различия, которые не имеют значения, в тех же примерах я мог написать aa: bb, а мог "aa" :"bb" и было бы то же самое. Это частая проблема, если меняется версия генератора для автоэкспортёра состояния.
Так что советую переуточнить своё представление.
YAML из Ада