yaml programming

[amarao]

Медленно погружаюсь в нюансы esp32 с использованием esphome. Я никогда не думал, что эмбедд можно будет программировать на ямле.

... И я это говорю, как что-то хорошее. Декларативное описание функций устройства, это какая-то тихая революция, которую я пропустил. Это ж что-то невообразимо офигенное. Может быть, за этим будущее?

Comments

[amarao]

Тебе и твоему сообществу хорошо. Мне нет.

yaml лучше, чем lisp. Кривые truthy из новых версий yaml, кстати, убрали, это была ошибка дизайна.

А вот ваше сообщество скобки любит. Ну, бывает. Кому-то и xml сладок.

awkravchuk

[awkravchuk]

Окей.
Прост когда легендарный Жора Шуклин, благодаря которому я стал более лучшим инженером, просто читая в молодости срачи в его жежешечке и статьи на хабре, осознанно отворачивается от просветления, мне почти физически больно.

Ну и насчёт конкретно этого обсуждения, yaml не лучше, чем lisp, всё, что угодно, лучше чем yaml, ему место в той же помойке, где и xml. Truthy пофиксили, хах, а как там с номерами портов? В

ports:
- 22:22
- 80:80
- 443:443

первое значение всё так же конвертируется при считываении в 1342? Оставим в сторонке лиспы, б-г с ними, но ямл — это же реально формат-червь-пидор)

Re: awkravchuk

[amarao]

!markdown

Да, это ошибка дизайна yaml'а, но в целом, любые строки с двоеточиями должны быть в кавычках.

Основная причина моей любви к ямлу (я сейчас не про любовь-любовь, как к расту, а про предпочтение по сравнению с другими форматами) состоит в том, что yaml решает множество проблем других форматов, куда более трагичных и проблемных.

xml не читаем. (можем подискутировать, но я всё-таки это считаю за общепризнанный факт). Даже hand-crafted well formtatted xml всё равно не читаем.

json не позволяет нормального сохранения многострочных строковых переменных, не позволяет комментарии и trailing comma, что приводит к многочисленным ошибкам операторов.

yaml - единственный формат, в котором ты можешь писать с отступами многострочный текст с отступами.

example: |
python_code:
import yaml

def foo():
with open("1.yaml") as f:
yaml.safe_load(f.read())

some_other_yaml:
non
multiline
variable


Одна эта фича стоит принудительного кавычинга любых подозрительных строк (чем обычно линтеры и занимаются, включая нарушающую линтер no в некавыченной строке).

Да, они сделали несколько ошибок и медленно их исправляют (можешь ещё добавить версию 1.0 в качестве забавного float'а вместо строки).

toml более строг, но вложенные словари на нём мучение. Я не вижу альтернативы.

Так же как и лиспу, который мне визуально напоминает корову в бомболюке (я про необходимость изворачиваться со скобками).

Re: awkravchuk

[yurikhan]

С маркдауном что-то пошло не так.

Скобки в лиспе энейблят тривиальную реализацию в редакторе структурных операций (выделить поддерево, повысить/понизить узел). А при достаточной практике или настройке редактора их начинаешь видеть вот так.

Re: awkravchuk

[amarao]

Весь лисп нужен для решения одной-единственной проблемы, которую и так уже решили множеством методов (как записывать древовидные структуры).

А жизнь требует решения более сложных проблем - сохранение структуры текста при структурированном тексте внутри (да-да, ямловый `foo: |`), возможность иметь операцию вставки в список, которая инвариантна вне зависимости от того, какой элемент списка вставляют (traling comma).

Вообще, мне немного странно сравнивать язык программирования и язык разметки данных (потому что yaml очевидно не умеет того, что лисп, то есть быть тьюринг-полным, а лисп, в свою очередь, крайне неудобен для представления данных).

То есть для меня лисп несёт в себе очень много визуального шума и boilerplate'а (те самые скобочки), то есть увеличивает базовый friction при использовании.

Это ровно та же причина, почему я очень сильно не люблю java и C# - у них во имя высших целей пожертвовано локальной эргономикой.