Языки диаграмм

Есть языки, которые описывают схемы и диаграммы. Например, пишешь что-то такое:

Потом натраливаешь на файл программу и получается картинка:

Казалось бы, все автоматически, красиво, удобно. Но нет.

Когда я верстал первую книгу в Латехе, то использользовал для графиков пакет TikZ. Там то же самое: схематично описываешь сущности, а пакет их рендерит. Исходник:

и результат:

Во второй книге я отказался от TikZ по следующим причинам.

Во-первых, синтаксис диаграмм забывается очень быстро. Если работаешь с ними каждый день, то проблемы не возникает. Однако чаще всего ты рисуешь диаграмму раз в полгода и не трогаешь ее. Когда открываешь файл опять, нужно вспоминать все заново. Откуда и куда вести стрелку, нужна ли точка с запятой, ставить => или ->> для уголка и все в том же духе. Каждый раз как в первый раз.

Далее, дьявол кроется в деталях. Помните правило 20/80? Большую часть диаграммы вы покроете за 20 процентов времени, и возникнет иллюзия — какой я молодец, что использую язык! Быстро управился. А потом провозитесь три часа в попытке сдвинуть первый прямоугольник влево, а второй — вправо. И рамка будет кривая. И позиционирование будет неудобное. Захочется сдвинуть вручную, но нелья — у нас же не Фотошоп или Иллюстратор, а код.

Наконец, все эти языки не имеют понятия о восприятии. Когда я рисую диаграмму, то думаю о пользователе: насколько ему удобно. Поэтому отталкиваюсь от самых важных элементов; насколько хорошо они контрастируют со второстепенным; насколько легко проследить процесс; нет ли объектов, которые этому мешают.

Стоит ли говорить, что ничего подобного в языках разметки нет. Они рисуют прямоугольники и стрелки, полагая, что пользователь разберется сам. Но это бред — пользователю нужен процесс, кем-то осмысленный и показанный наглядно. А не нагромождение прямоугольников.

Когда я сел за вторую книгу, то пытался сделать схемы в TikZ как раньше. Но обнаружил, что синтаксис забыт начисто, а вспоминать не хочется. В итоге нарисовал в Monodraw — программе ASCII-диаграмм — и экспортировал в SVG. Это проще и быстрее. Если нужно подвинуть фигуру на клетку влево, я сделаю это в один клик. Не нужно вспоминать, какое свойство отвечает за сдвиг и в каких единицах оно измеряется.

Против Monodraw можно сказать только то, что она под Мак. Для командной работы, возможно, не подойдет. С другой стороны, пусть в команде будет один человек, который отвечает за диаграммы. Если их редактируют все подряд, это беда.

Экстраполируя, можно сказать, что языки построения схем — блажь. Их любит “серьезный” бизнез, где вещи внедряют лишь затем, что так принято. Хорошим примером служит UML — циклопическая абстракция о том, что и как описывать. В нее вбухали невероятно много денег и времени; всерьез считали, что если отобразить классы диаграммой, логика программы станет очевидной. И что — кто-то пользуется UML сегодня? Доводилось ли кому-то посмотреть на UML и сказать: точно, я все понял?

Наконец, если программы для диаграмм сводят с ума, остается надежное средство — рисовать руками. Берете маркеры и рисуете на доске то, что нужно. Затем снимок → коррекция → красивая картинка.

Как-то раз я делал презентацию об HTMX для команды, и сама мысль о какой-то программе вызывала дрожь. В итоге нарисовал на доске и отфотал. Пара слайдов из презентации:

Местами кривовато, но я и не особо старался.

А можно заморочится и нарисовать на бумаге. Например, Bob Nystrom в своих знаменитых книгах Crafting Interpreters и Game Programming Patterns рисовал схемы гелевой ручкой на бумаге, а потом сканировал. Просто сказка:

Какой итог можно подвести? Мне кажется, такой:

• языки диаграмм — прохладная затея, потому что машина не понимает, что первично, а что вторично, что удобно пользователю, а что нет;

• языки диаграмм — идеальный пример правила 80/20. Быстро получаешь почти готовый результат, но на доводку уходит много времени;

• откройте исходник диаграммы через полгода — будет трудно вспомнить, что и как поправить;

• не бойтесь ручного труда — рисунки на доске или бумаге по-прежнему смотрятся отлично.