Средний

11 мин

21K

Есть в жизни вещи, которые приносят мне и радость, и печаль одновременно. Например, горький шоколад и markdown. Серьёзно, зачем он нужен? В половине случаев мы даже не используем этот язык целиком!

HTML — лучший язык программирования!

Вы наверняка слышали о людях, которые говорят, что из языков программирования знают только HTML. Да, все мы в этот момент закатывали глаза и пытались доказать, что HTML — это только язык разметки, а не программирования.

Да, наверно, мы правы, но у того, кто так говорит, есть то, чего нет у нас.

Нормальная жизнь.

[Примечание] Когда я говорю о markdown, то имею в виду конкретно CommonMark, если не указано иное. Дело в том, что это неоднозначная спецификация синтаксиса. Я люблю этот проект и ценю усилия разработчиков. Поломана не спецификация, а сам язык.

Хорошее

Markdown — минималистичный язык для форматирования тривиальных документов. Он должен справляться с одной простой задачей: получать файл Markdown и выводить его в виде файла HTML. Его синтаксис довольно удобочитаем и его легко писать. В отличие от кода на языке C, можно сразу видеть вывод, который будет создан. Полужирный текст — это всегда <b></b>, аналогично и для курсива.

Обучение практически не требуется, достаточно одного взгляда на шпаргалку, и вы готовы писать.

Плохое

Мы не знаем, чего хотим

Нам нужен UI? Нам нужен язык программирования? Мы не знаем. Единственная причина разрастания фич заключается в нечётких спецификациях.

Если вам нужен МИНИМАЛЬНЫЙ легкочитаемый язык разметки, то у вас есть markdown. Вроде бы всё просто?

Ну…

(Вывод взят из dingus)

# Hello

*I am an*
__Unambiguous__
> Grammar

<h1>Hello</h1>
<p>
    <em>I am an</em>
    <strong>Unambiguous</strong>
</p>
<blockquote>
    <p>Grammar</p>
</blockquote>

Hello
=====

_I am an_
**Unambiguous**
> Grammar

<h1>Hello</h1>
<p>
    <em>I am an</em>
    <strong>Unambigious</strong>
</p>
<blockquote>
    <p>Grammar</p>
</blockquote>

Как мы видим, markdown — это НЕ то, чего мы просили. Эти два ввода создают ОДИНАКОВЫЙ вывод. И это лишь вершина айсберга?

В нём так много плохих решений, что если вы попытаетесь использовать его, он начнёт активно противодействовать вам как раз в тот момент, когда вы вроде бы точно знаете, что делаете.

Образец А: полужирный, курсив, полужирный курсив, ???

В markdown можно обозначать полужирное начертание разными способами. **bold**, __bold__, <b>bold</b> — это часть способов записи допустимого полужирного. И это только для commonmark. Если вы пользуетесь чем-то, что не позиционирует себя, как «CommonMark™ Compliant®©», то вполне можете столкнуться с допустимыми вещами, которые генерируют одинаковый ввод. Например:

• _*bold*_

• *_bold*_

• _*bold_*

• *_bold_*

Поистине великолепно.

И я даже не буду начинать говорить о всяких многослойных штуках наподобие этой:

***Peter* Piper** _Picked___a___Pack_ *of** Pick_led_* Peppers

или такой:

*****\\*a*

На самом деле, это настолько распространено, что у нас есть отдельный класс уязвимостей парсеров под названием ReDoS (Regular Expression Denial of Service). Например, CVE уровня 6.9 для markdown-it.

markdown-it — это одна из самых наиболее проработанных, чистых и понятных библиотек для Markdown. Я просто обожаю markdown-it, но то, что даже эту библиотеку затронули уязвимости, показывает, насколько серьёзна ситуация.

Образец Б: __asm__ был хорошей идеей, но это?

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

Это позволяло, например, реализовывать SIMD-операции ещё до внедрения их поддержки в компилятор. Если вам любопытно, можете изучить краткий обзор ранних неудач генерации SIMD.

А теперь давайте возьмём эту чудесную идею и прикрутим её прямиком к самому раздутому, однопоточному, работающему в песочнице окружению, которому требуется простой и удобный способ написания документов. Так родился встроенный в Markdown HTML!

Встроенный HTML позволяет делать такие штуки:

# Hi

I am a <ins> simple </ins> _programmer_ doing
<span class="fancy-text"> elegant </span> programming.

<div class="animation">

And here is my portfolio

</div>

Разве это не просто? Разве это не здорово? Основная причина крайней сложности парсинга корректного markdown не в том, что синтаксис Markdown так сложно понять. Это лишь одна десятая часть проблемы. Главная проблема в том, что для выпуска парсера Markdown нужно также выпустить дружественный парсер HTML. А если вы используете HTML внутри Markdown, то почему бы не использовать HTML изначально?

...сказал автор этой статьи, использующий все известные человеку навороты, которых НЕТ в стандарте.

Сам по себе Markdown недостаточно мощный, чтобы удовлетворить разработчика с мозгом обезьяны навроде меня, который доволен, только если сайт выглядит достаточно хорошо™.

«Достаточно хорошо™» в данном случае подразумевает, что на нём есть хотя бы простейший LaTeX с поддержкой Tikz, возможность установки пакетов, PlantUML, Mermaid, собственной стилизации, собственных шорткодов, тэгов и классификации, настоящих сносок, поддержки Bibtex…

Не нужно мне и чтобы простой инструмент выполнял простую работу. Чтобы повесить картину на стену, мне нужен молоток. В данном случае, молоток — это markdown. Но если бы я хотел и рисовать им, то сразу же поломал бы холст.

Кроме того, это означает появление целой кучи CVE, в основном связанной с XSS-уязвимостями.

Каждый раз, когда мы разрешаем встроенный HTML, перехватчики плагинов или встроенные движки исполнения, мы увеличиваем поверхность атаки.

Результат оказывается предсказуемым: постоянно встречающиеся XSS-уязвимости во всех крупных реализациях Markdown, а также многое другое. И ситуация будет ухудшаться с появлением на рынке новых парсеров, написанных вайб-кодингом.

Образец В: запутанный и устаревший синтаксис

Как и все хорошие технологии, которые есть в WorldWide Web, Markdown был изобретён в старые добрые нулевые! Источником вдохновения для него стали уже существовавшие стандарты разметки неотформатированного текста в электронной почте и постах Usenet (ссылка).

Напомню, что до 2000-х даже самые серьёзные электронные письма выглядели вот так:

From: k...@rational.com (Kent Mitchell)
Subject: Re: Does memory leak?
Date: 1995/03/31

Norman H. Cohen (nco...@watson.ibm.com) wrote:
: The only programs I know of with deliberate memory leaks are those whose
: executions are short enough, and whose target machines have enough
: virtual memory space, that running out of memory is not a concern.
: (This class of programs includes many student programming exercises and
: some simple applets and utilities; it includes few if any embedded or
: safety-critical programs.)

This sparked an interesting memory for me.  I was once working with a
customer who was producing on-board software for a missile.  In my analysis
of the code, I pointed out that they had a number of problems with storage
leaks.  Imagine my surprise when the customers chief software engineer said
"Of course it leaks".  He went on to point out that they had calculated the
amount of memory the application would leak in the total possible flight time
for the missile and then doubled that number.  They added this much
additional memory to the hardware to "support" the leaks.  Since the missile
will explode when it hits its target or at the end of its flight, the
ultimate in garbage collection is performed without programmer intervention.

--
Kent Mitchell                   | One possible reason that things aren't
Technical Consultant            | going according to plan is .....
Rational Software Corporation   | that there never *was* a plan!

Вы видите, в чём красота такого оформления? Синтаксис цитат, вертикальное разделение символами вертикальной черты (|), ограничение в 80 символов по длине строки. Именно для этого нужен был markdown (и с чем он совершенно не справился, ведь в markdown нельзя разделить экран на N частей без чёрной магии встроенного HTML)

Но из-за этого легаси у нас теперь есть два способа создания заголовков: обычный и ATX. Два разных способа и больше, чем два CVE по написанию полужирного и курсива. У нас есть два разных способа создания горизонтальной линии, которые конфликтуют друг с другом и с синтаксисом заголовков setext. У нас есть два способа составления неупорядоченных списков. У нас есть упорядоченный список, которому не важно, как мы его упорядочим. И у нас есть синтаксис сносок, перемещающий всю эту грамматику в зависящую от контекста грамматику.

Этот язык в буквальном смысле C++ языков разметки. Почти всё в нём можно сделать двумя разными способами: некоторые из них допускают XSS и почему-то приводят к утечкам памяти в html.

Он используется повсюду и всюду же терпит неудачу.

Образец Г: нельзя просто выполнить парсинг, нужно ещё и использовать

Парсинг — это просто.

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

test [^1]

<p>test [^1]</p>

test [^1]



[^1]: hello

<p>test <a href=″hello″>^1</a></p>

По техническим причинам я добавил форматирование и заменил " на ″.

На самом деле, в CommonMark не поддерживаются сноски, там есть линки. Единственная существенная разница заключается в том, что в синтаксисе линка после определения можно поместить только одно слово.

Линки и сноски в стиле ссылок и требуют глобального ресолвинга определений. Значение токена зависит от объявлений в другой части документа. Это нарушает допущения о парсинге без привязки к контексту.

Всё это можно выразить гораздо более кратко.

Если вам нужен простой язык, не усложняйте.

Рендеринг — это тяжело

Наверно, это самая спорная часть моего жалобного поста. Потому что никто не хочет признавать, что мы пользуемся двумя разными способами, и они нам нужны.

Ванильному Markdown нужен транслитератор, то есть буквально функция отображения один к одному. На входе **bold**, на выходе <b>bold</b>.

Однако современному Markdown нужно поддерживать, например, сноски, что превращает простой транслитератор в полнофункциональный компилятор. А после того, как мы сделали этот шаг, нам придётся карабкаться по лестнице.

Мне нужна личная система управления знаниями

(* например, шаблоны/шорткоды tera)

Клянусь, из-за того объёма работы в Obsidian с Markdown, который мне нужен для моих задач, решение Notion превратиться во внутреннюю копию Word / Excel кажется вполне разумным.

Каким может быть решение?

Если спросить об этом у чувака с великолепной бородой и тридцатилетним опытом работы на языке ассемблера 8086, то он ответит, что решение заключается в тексте без форматирования.

Если спросить у бро с Macbook и openclaw, который на трёх Mac mini создаёт стартап за день, то он ответит, что нужен mdx.

Если спросить у человека, зарабатывающего кодингом на C, то ответом будет ReStructured Text (.rst)

Если спросить меня, то я скажу, что решения нет. Все они поломаны тем или иным образом. Текст без форматирования прекрасен, но я не могу показать его тем, кто не знает, что такое разыменование нулевого указателя. ReStructured text чудесен, если вы только читаете его и никогда не пишете. А mdx так увлёкся копированием html, что забыл об удобочитаемости.

А самая большая проблема всех них в том, что у них нет системы сборки. Ради скорости мы экономим усилия. Если бы у них имелась система сборки со здравым, недвусмысленным, легкочитаемым синтаксисом, созданным именно для решения необходимых задач, думаю, все проблемы были бы решены.

Не разрешайте встроенный HTML, манипулировать текстом допускается только чётко определённым шорткодам и функциям.

Разрешайте исполнение хуков до, во время и после компиляции.

И, что самое важное, определяйте всё. Нам нужна специализированная система сборки, а не чудовище Франкенштейна, которое мы имеем наглость называть языком.

Я не говорю, что Markdown / Markup должен быть языком программирования; я говорю, что мы пытаемся его так использовать, а поскольку ему не хватает формального фундамента, он терпит поражение на обоих фронтах.

Я искренне считаю, что при наличии правильных ограничений полноценная система сборки на основе более разумного языка разметки с поддержкой хуков на этапе компиляции может решить многие связанные с этим проблемы. На данном этапе нам пора окончательно отказаться от Markdown и искать ответы в другом месте. Желательно с тривиально парсимой грамматикой

Что я имел в виду всем этим

Если вы поняли, о чём я говорю, то можете пропустить этот раздел.

С точки зрения формальной теории языков:

Язык разметки (Encyclopedia Britannica)

Стандартная система кодирования текста, состоящая из набора символов, вставляемых в текстовый документ для управления его структурой, форматированием или взаимоотношениями между его частями…

Язык программирования (Encyclopedia Britannica)

Язык для выражения набора детальных команд для цифрового компьютера…

ОЧЕВИДНО, что Britannica нам не поможет, поэтому давайте воспользуемся другими инструментом, которому я всегда доверяю — здравому смыслу. Дадим такое определение языку программирования:

Язык является языком программирования, если он полон по Тьюрингу

За определение языка я беру единственный источник истины, то есть «иерархию Хомского», основа которой появилась в 1956 году.

В пищевой пирамиде языков контекстно-независимые языки — это пшеница, а регулярные языки — это белок. Регулярный язык — это то, что может парсить обычное регулярное выражение. Контекстно-независимый язык — это то, что может описать BNF/EBNF , а контекстно-зависимый — это то, что мы называем синтаксисом C++. Надеюсь, вам не придётся иметь дело со вторым.

Рекурсивно перечислимые языки странные и не относятся к теме этого поста. Но просто чтобы разжечь ваше любопытство, скажу, что это валидный язык типа 0.

HALT={(P,x)∣P halts on input x}

Что подводит нас ко второму пункту.

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

Если говорить простым языком, вычислимая по Тьюрингу функция — это функция, которая или вернёт значение, или умрёт, пытаясь это сделать (то есть остановится) за конечное или бесконечное время.

Вычислимая по Тьюрингу:

def good_function(inp: int):
	ret : int = 0
	for i in range(inp):
		ret += i
	return ret

Невычислимая по Тьюрингу:

def busy_beaver(n: int):
	... # удачи

Зачем я начал эту вводную лекцию курса computer science о языках программирования/
классификации языков? Потому что хочу объяснить, что простые желания могут привести к серьёзным изменениям.

Грань между набором математических аксиом, ведущим к доказуемости, и тем, который ведёт к недоказуемости, — это отсутствие рекурсии (самореференции), которая проявляет себя как обычная операция умножения. У тривиальной операции могут быть нетривиальные последствия.

Хотите ещё больше хаоса?

Мой опыт работы с Markdown довольно автономен. Я пользовался им на форумах и в основном пишу на нём в Obsidian. В посте приведены мои личные мысли. Я никого не поддерживаю, но считаю, что одни люди более правы, чем другие.