Эта статья — просто идея, не судите строго.

TLDR: предлагаю рассмотреть хранение исходных кодов программ в некоем бинарном формате вместо голого текста.

Компилятор и IDE

Как примерно работает компилятор: сначала происходит лексический анализ, т.е. разбиение исходного кода на токены. Потом происходит синтаксический анализ — полученные токены объединяются в синтаксическое дерево. Потом семантический анализ: вывод типов данных, проверка видимости переменных, и т.д.

И только потом идут этапы, приводящие в конце концов к появлению исполняемого файла.

Как работает типичная IDE: да точно так же. Лексический анализ, синтаксический анализ, семантический анализ, вывод типов, и всё прочее. Т.е. по сути ребята пишут полкомпилятора, чтобы вы могли получить все современные возможности IDE.

Т.е. сам текст программы нужен только человеку на этапе ввода информации. Потому что ему для понимания происходящего AST-дерево не подойдёт.

Но что если хранить исходный код по-другому?

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

Какие есть плюсы:

1. Компиляция будет происходить значительно быстрее.
2. IDE не будет долго "индексировать" проект, подсветка синтаксиса и большая часть информации для автокомплита будут доступны сразу.
3. Не будет споров а-ля "табы vs пробелы", в файл попадет лишь дерево.
4. Если совсем упороться, то, наверно, можно даже настроить IDE так, чтобы писать на другом языке. Например, код был на Java, а ты себе показываешь его на котлине. Просто где-то в IDE пометить, чтобы в файл сохранялось джавовое AST. Здесь я не уверен, просто как мысль, что можно ещё сделать, если отказаться от оков текста.
5. Что если дать возможность менять шрифты, чтобы выделять какие-то отдельные важные функции жирным красным цветом?
6. IDE может хранить в этих бинарях свои данные для ускорения каких-то процессов отображения и автокомплита. Правда, файлы могут сильно разрастись.
7. Скорее всего, появится много чего интересного, что сейчас и в голову не приходит. Подход совершенно иной.

Минусы, конечно, тоже есть

Все инструменты, которые редактируют код или показывают дифф, должны быть написаны специально под язык. Это IDE, github, gitlab, и т.д. Для простых скриптовых языков это будет дополнительным усложнением. Если раньше можно было подправить файл любым текстовым редактором, и больше ничего не надо, то теперь нужно иметь под рукой специальный редактор. И этот редактор не напишешь за 5 минут, это точно будет полукомпилятор. Т.е если сейчас есть монструозные IDE, а есть редакторы типа nano, то в случае бинарного формата надо в любом случае многое уметь. Скорее всего, с языком должен сразу поставляться language server или условные сишные либы, которые можно забиндить в редактор.

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

Погрепать проект тоже будет не так просто, нужен будет специальный grep.

Откуда взялась идея

Когда-то давно в курилке Каруны я участвовал в обсуждении "табы vs пробелы", и мы пришли к выводу, что ни табы, ни пробелы не являются чем-то логичным. Пробелы задумывались для разделения слов, а табы — это вообще изначально механизм на печатной машинке, чтобы было удобнее печатать таблицы.

До сих пор это именно выравнивание по сетке:

Здесь я поставил табуляцию в строке между t и t, в результате чего вторая t выровнялась со строкой z=3. Спрашивается, зачем? Да ни зачем, просто печатные машинки когда-то так делали.

В современном мире никто не программирует в .txt файлах без подсветки, обычно используют мощные IDE, которые играючи тебе переделают табы в пробелы и наоборот. Тогда зачем мы вообще храним эту информацию в исходном коде? Просто потому, что мы используем текст, а значит, надо что-то выбрать для отступов. Но, возможно, это стоит пересмотреть?

И некоторые попытки в эту сторону, кстати, уже делаются.

Когда я опубликовал пост на эту тему в tg-канале, мне сразу скинули в комментах проект tree-sitter. Это немного не то, с компилятором не связано, но мысль примерно в том же направлении: инструментам работы с кодом удобнее работать сразу с деревом и обновлять его при необходимости на лету. Причем tree-sitter, если я правильно понял, как раз предоставляет библиотеки на Си, которые можно забиндить в любой инструмент. В общем, если это дерево хранить вместо текста кода, да ещё и чтобы компиляторы его понимали — то задача будет решена.