Почему мы все еще храним код в текстовых файлах? / forpes.ru

Главная
Почему мы все еще храним код в текстовых файлах?

Почему мы все еще храним код в текстовых файлах? +33

17.06.2025 18:43

fransua 265 27000 Источник

Это не риторический вопрос. Я знаю, так исторически сложилось, но... почему мы продолжаем использовать текстовые файлы?

Вы можете сказать, что это очень простое решение: что видишь, то оно и есть. Но мы имеем дело с несколькими слоями абстракции, а все абстракции текут. Это приводит к ошибкам, запутанным диффам и проблемам с производительностью.

Давайте углубимся в искусство хранения кода в виде текстовых файлов.

Текст

Компьютеры оперируют бинарными данными, поэтому для представления текста им приходится использовать кодировки. Существует много вариантов: UTF-8 или UTF-16; с BOM или без него; CR, LF или CRLF; little-endian или big-endian — это лишь самые популярные варианты. К сожалению, мир не смог договориться об одном стандарте, поэтому то и дело приходится сталкиваться с проблемами: испорченные диффы, ошибки в тулзах, проблемы с копированием, нечитаемый текст на фронте.

Вы можете возразить, что текст дает нам свободу самовыражения: мы может записать код лесенкой или побаловаться ASCII art в комментариях. Это прекрасно, но имеет слабое отношение к программированию. Современные языки дают большую свободу для выражения сложных концепций в коде. Но если мы говорим о форматировании, для меня это выглядит странно: почему мы должны заботиться о пустых строках, табуляции или пробелах, ограничениях по длине строк и других несущественных деталях? Слава всем богам, мы не добавляем информацию о предпочитаемом шрифте и цвете в нашу кодовую базу, я точно не хочу читать код в Comic Sans.

Файловые системы

Еще один уровень абстракции между кодом и хранилищем. Зачем нам имена файлов и ограничения с ними связанные? Разве это удобно использовать двухбуквенные расширения для указания используемого языка? А ограничения на глубину вложенности каталогов или inotify watch limit? Или вот мы запускаем код в докере, а контейнер не видит изменения файлов на хосте, куда это годится?

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

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

Парсинг

В спецификациях нашего языка задействовано много элементов форматирования: ключевые слова, скобки, разбиение строк, отступы. Возможно с ними проще читать код, но я уверен, что есть другой способ сделать код читабельным. Гораздо важнее эти элементы при парсинге кода компилятором и другими тулзами.

Обычно парсер разделяет ваш код на токены и строит Абстрактное Синтаксическое Дерево (AST). Затем он связывает идентификаторы, чтобы понять их назначение. Это очень быстрые операции, и ваш компьютер может разобрать множество файлов за секунды. Но не так много, как в вашем раздутом монорепозитории с миллионами строк кода. Поэтому иногда IDE тупит во время загрузки проекта.

Однако это еще не все, парсинг происходит много раз и после загрузки: при изменении кода, при переключении веток, при компиляции. В некоторых языках приходится парсить даже устанавливаемые зависимости (да, я про тебя, javascript). А еще у нас есть различные помощники для продуктивной работы: автодополнение, линтеры, статические анализаторы, форматтеры и AI-агенты. Все они читают наш код с диска и парсят его. Иногда используется один инструмент для всех этих задач, иногда разные. В таком случае их парсеры могут быть реализованы по-разному, что может привести к несогласованности: например, я иногда сталкивался с ситуацией, когда WebStorm сигнализирует об ошибках в импортах, но vite компилирует работающий JS без проблем.

Каким бы эффективным не был парсер, но он загружает ваш процессор и память. Сколько бы у вас не было ядер и планок памяти - они закончатся, когда вы откроете достаточно большой проект.

Диффы

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

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

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

Итого

Итак, давайте представим, что мы разрабатываем систему для разработчиков, где они могут писать код, читать его и обмениваться изменениями. Должны ли мы использовать текстовые файлы в качестве основного источника истины? Очевидно, нет. Это неудобно, ненадежно и может привести к несогласованности.
Но что если мы распарсим код в AST, присвоим уникальные идентификаторы блокам кода, свяжем их и сохраним в графовую базу данных? Мы сможем сэкономить на размере данных если использовать enum для ключевых слов. Чтение из локальной БД будет сравнимо по скорости с чтением с диска. Форматирование AST должно быть быстрее парсинга. При слиянии веток надо будет сравнивать измененные блоки, а не файлы, что реже будет приводить к конфликтам. Статический анализ и автодополнение будут работать с блоками и связанными идентификаторами, что должно значительно уменьшить потребление памяти.

Система версионирования AST

Я работаю над PoC CVS, которая хранит AST кода TypeScript в распределенной графовой базе данных с коммитами и ветками.
Вот репозиторий: https://github.com/franzzua/ast

Текущий подход очень прост и прямолинеен. Код парсится с помощью oxc. В результате получается AST: функции, выражения, вызовы. Затем вычисляются области видимости для каждого блока: каждая функция создает область видимости, поэтому идентификаторы должны разрешаться от внутренней области к внешней.

Затем каждому узлу присваивается уникальный идентификатор и блоки связываются друг с другом, так что если есть вызов функции с именем sayHello, вместо ее имени ставится id вызываемой функции. После этого я сохраняю полученный граф в TerminusDB. Она требует схему данных, поэтому я попросил Gemini сгенерировать схему для AST oxc и подправил ее.

Сейчас эта штука может разбирать простой код в граф, сохранять его в базу данных, а затем загружать и форматировать как исходный текст. Дальше я собираюсь реализовать интерфейс для сравнения и слияния. Я представляю это как нечто вроде режима исправлений в Google Docs: некоторые части заменяются, другие перемещаются куда-то или удаляются. Надеюсь, получится сделать его интуитивным и понятным. После этого можно будет настроить автоимпорт проекта из git коммит за коммитом и посмотреть, где лучше и понятнее диффы.

Мечты о будущем

Никто не мешает расширить схему и добавить возможность привязать к блоку кода что-то вроде комментария, но с поддержкой Markdown - получится документация. А если добавить несколько полей и статусов, то можно реализовать менеджер задач. Конечно же нужно будет прикрутить CRDT для парного программирования. Небольшую доску для проектирования и чатик с войсами и стикерами. Why not?

Преимущества

Чистые диффы
Производительность и сокращение выбросов CO2
Согласованность между вашими инструментами

Комментарии (265)

PerroSalchicha
17.06.2025 18:49
#28448980
Очевидно, нет. Это неудобно, ненадежно и может привести к несогласованности.

Но... почему?

Почему именно текстовый файл, я легко отвечу: это естественный для меня формат, он хранит код именно так, как я его буду читать. И я его могу прочитать абсолютно любым инструментом, который у меня есть под рукой, вплоть до голой ОС.

В то же время преимущества каких-то других форматов для меня не очевидны. Удобство? Нет ничего удобнее нативного для меня формата. Надёжность? Текстовый файл надёжен настолько, насколько надёжен носитель, на котором он записан. Лучше этого и не придумаешь. Размер хранилища? Да, в этом плане текстовый файл ни разу не оптимален, но... на моём компьютере весь текстовый контент едва ли займёт несколько процентов от самого маленького накопителя на 256Гб. А остальное занимает отнюдь не код, а всякого рода бинарники и медиаконтент.
1. BobovorTheCommentBeast
  17.06.2025 18:49
  #28449046
  Тут наоборот материшься на какого нибудь вендора IDE или тулзов, который хранит файлы не в текстовом формате (или в файлах, которые еще хранят кучу локальной\временной информации).
1. pnmv
  17.06.2025 18:49
  #28449356
  мне, почему-то, вспомнились какие-то лекции, по программированию, кажется, на perl: весьма юный лектор показывает пример какого-то кода, весьма компактный, внятный и читаемый, а потом, такой - "ну, это муторошно!", после чего выдает такую простыню, которую прочтешь то не с первого раза.
  1. blind_oracle
    17.06.2025 18:49
    #28452930
    Perl он, как и его регулярки, часто нечитаем) Write Once, Read Never
    
    pnmv
    17.06.2025 18:49
    #28453298
    Язык, как язык...
    
    Если не придерживаться, при разработке, php5-style, всё как-то не так грустно, пока слишком творческие личности не вмешиваются. Да и вообще, perlcritic никто не отменял.
    
    Регулярные выражения, при правильном приготовлении, замечательная вещь. И общие рекомендации, кстати, такие же, как везде - не городить длинных простыней, разбивая на кусочки.
    
    vdudouyt
    17.06.2025 18:49
    #28455582
    Из нечитаемого там только тот самый запускающий rm -rf однострочник, некогда настолько травмировавший неокрепшую психику джунов-миллениалов, что теперь утверждения о якобы write only природе Perl можно встретить буквально при каждом его упоминании (причем в основном от индивидуумов, более нигде с ним не сталкивавшихся).
    
    Реальный write only из того, что я видел это C++-поделки отдельных template only-мастеров. Но, конечно, меметичность совсем не та.
    
    blind_oracle
    17.06.2025 18:49
    #28455978
    Я писал на перле последний раз лет 15 назад всякое достаточно активно по работе, и если там налягать на контекстные переменные и всё такое - становится читать потом свой же код даже сильно сложно.
    
    Так что это чисто моё впечатление.
    
    Шаблоны в плюсах это страшно тоже, да.
    
    В Расте дженерики аналогично регулярно приводят к типам, которые мне в экран не влазят.
    
    ServiceBuilder<Stack<Either<ServiceBuilder<Stack<ShardedLittleLoadShedderLayer<RequestTypeExtractor>, Stack<MapResponseLayer<impl Fn(ShedResponse<Response<Body>>) -> Response<Body>>, Identity>>>, Identity>, Stack<Either<FromFnLayer<fn middleware(State<Arc<GeoIp>>, Extension<Arc<ConnInfo>>, Request<Body>, Next) -> impl Future<Output = Response<Body>>, Arc<GeoIp>, {unknown}>, Identity>, Stack<Either<ConcurrencyLimitLayer, Identity>, Stack<FromFnLayer<fn middleware(State<ValidateState>, Request<Body>, Next) -> impl Future<Output = Result<impl IntoResponse, ErrorCause>>, ValidateState, {unknown}>, Stack<Either<ServiceBuilder<Stack<SystemLoadShedderLayer<SystemInfo>, Stack<MapResponseLayer<impl Fn(ShedResponse<Response<Body>>) -> Response<Body>>, Identity>>>, Identity>, Stack<FromFnLayer<fn middleware(State<Arc<HttpMetrics>>, Extension<Arc<ConnInfo>>, Extension<RequestId>, Request<Body>, Next) -> impl Future<Output = impl IntoResponse>, Arc<HttpMetrics>, {unknown}>, Stack<FromFnLayer<fn middleware(Request<Body>, Next) -> impl Future<Output = Result<impl IntoResponse, ErrorCause>>, (), {unknown}>, Stack<FromFnLayer<fn middleware(Request<Body>, Next) -> impl Future<Output = Response<Body>>, (), {unknown}>, Stack<FromFnLayer<fn middleware(Request<Body>, Next) -> impl Future<Output = Response<Body>>, (), {unknown}>, Identity>>>>>>>>>>
    
    JBFW
    17.06.2025 18:49
    #28456576
    Так может быть писать надо было как-то попроще?
    
    Вообще, хорошее правило: если твой собственный текст без комментариев через месяц становится непонятен - значит, надо что-то думать над своим стилем написания программы
    
    blind_oracle
    17.06.2025 18:49
    #28456654
    Может быть. Но я писал на десятке разных языков наверное, и такая проблема была только с Перлом :)
    
    vdudouyt
    17.06.2025 18:49
    #28457272
    Ну не знаю, как по мне так примерно на уровне остальных ЯП с динамической типизацией )
    
    Кстати, чтобы избежать проблем со скоупингом переменных многие крупные кодовые базы на Perl написаны на его strict-подмножестве (use strict). Хотя, вон, в тех же PHP, Lua и до недавнего времени и Python как-то не особо парятся по этому поводу, и ничего.
    
    JBFW
    17.06.2025 18:49
    #28457592
    Люди с опытом начинают писать лучше...
    Хотя до сих пор использую некоторые свои блоки многолетней давности - нет никаких проблем с пониманием чего они там делают, все же написано в коде...
    
    JBFW
    17.06.2025 18:49
    #28456554
    Вы его видели? )
    
    Похоже, представление о коде на Perl складывается из творений какеров, которые умеют вместо
    
    print "hello world\n";
    
    написать что-то типа
    
    $<->^$2>>^&3@\#
    
    и потом радуются как круто и непонятно получилось
    
    blind_oracle
    17.06.2025 18:49
    #28456564
    Я на нём (ну, на mod_perl) писал всякие веб-бекенды несколько лет (давно уже правда). Так что да, видел.
    
    JBFW
    17.06.2025 18:49
    #28457676
    Стиль вероятно.
    
    Можно написать как-то так:
    
    sub func{ <>; my $a=$_."\n".Content-type: \"text/html\";\n\n";}
    
    А можно написать
    
    sub func { my $in = <>; my $a = $in . "\n" . 'Content-type: "text/html";' . "\n\n" ; return $a; }
    
    Чуть больше букв, зато для понимания смысла даже незачем знать Perl, всё и так понятно.
    
    UplandDivan
    17.06.2025 18:49
    #28457116
    Perl нечитаем? Это вы еще C++ >= 11 не видели )))
    
    UFO_01
    17.06.2025 18:49
    #28462952
    Сейчас пойдёт потеха. Имхо, у раста синтаксис куда более нечитаемый.
1. UserSergeyB
  17.06.2025 18:49
  #28453704
  Потому что вы так привыкли.
  
  На носителе не записан текст. Там двоичные данные, удобные ровно до тех пор, пока есть текстовый редактор.
  
  И если для кода когда-то найдется формат по-лучше, чем обычный текст, то он может когда-то стать нативным. Напишут для всех осей нативный инструмент, которым вы его сможете открывать и читать так, как вы его написали.
  1. omaxx
    17.06.2025 18:49
    #28454474
    Так это и про книги можно так сказать, что там не текст, а это всего лишь испачканные типографской краской стопки бумаги
    
    UserSergeyB
    17.06.2025 18:49
    #28455620
    Верно. Если вы язык, на котором она написана, не знаете, для вас это просто краска на бумаге.
    
    omaxx
    17.06.2025 18:49
    #28455648
    нет... для меня это все так же текст, но только на незнакомом мне языке
    
    UserSergeyB
    17.06.2025 18:49
    #28455688
    Почему вы решили, что там текст? Возможно на другом языке эта краска на бумаге образует картинку.
    
    omaxx
    17.06.2025 18:49
    #28455718
    вы сейчас имеете ввиду какой-то определенный язык или просто фантазируете?
    
    UserSergeyB
    17.06.2025 18:49
    #28455788
    Я про краску на бумаге. Вы сами привели такое сравнение.
    
    Вот например, если в книге на всю страницу напечатать огромный QR-код. Вы тоже подумаете, что это текст?
    
    omaxx
    17.06.2025 18:49
    #28455820
    Ну насколько я знаю, на свете нет людей, которые свободно читают в куар-кодах....
    
    Речь идет о том, что люди пишут тексты буквами уже тысячи лет, а как они записаны, краской на папирусе, на бумаге, в виде ascii или в виде юникода, это не принципиально.... текст в книге и текст на экране монитора выглядят примерно одинаково... ну найдется другой формат, ну и черт с ним, главное, чтобы текст оставался текстом
    
    UserSergeyB
    17.06.2025 18:49
    #28455914
    Я об этом и писал, что мы привыкли выражать свои мысли текстом.
    
    Хотя иногда удобнее для представления алгоритмов рисовать блок-схемы.
    
    Связка:
    
    двоичный формат хранения блок-схем;
    
    нативный редактор блок-схем;
    
    компилятор из блок-схем в машинный код;
    
    позволяет программировать вообще без текста.
    
    Просто исторически мы привязались к тексту. Но это не данность, и повод не искать что-то другое.
    
    omaxx
    17.06.2025 18:49
    #28455944
    тем не менее мы вот сейчас с вами общаемся именно текстом, а не смайликами, не стикерами, и не картинками...
    
    UserSergeyB
    17.06.2025 18:49
    #28455960
    Так надо было сказать, я бы прислал стикер :)
    
    omaxx
    17.06.2025 18:49
    #28455972
    а вы уверены, что он отобразится в моем браузере?
    
    UserSergeyB
    17.06.2025 18:49
    #28455980
    В крайнем случае посмотрите как на пятнышки на мониторе на неизвестном языке.
    
    Orisava
    17.06.2025 18:49
    #28456230
    Вы имеете отношение к 1С?
    
    UserSergeyB
    17.06.2025 18:49
    #28456304
    Нет.
    
    DvoiNic
    17.06.2025 18:49
    #28456312
    
    Связка:
    
    двоичный формат хранения блок-схем;
    
    нативный редактор блок-схем;
    
    компилятор из блок-схем в машинный код;
    
    позволяет программировать вообще без текста.
    
    Вы описали пресловутый Дуракон (его инкарнацию от Тышова). Попробуйте на нем что-нибудь более-менее серьезное "напрограммировать", удачи вам
    
    UserSergeyB
    17.06.2025 18:49
    #28456420
    Я описал любой процесс программирования. Есть исходник, редактор и компилятор.
    
    И если вы думаете, что графы (те же блок-схемы) хуже текста, то я вас расстрою.
    
    А программировать что-то серьезное можно на любом полном по Тьюрингу языке. И всё равно как он выглядит. Хоть буковки, хоть стрелочки, хоть картинки.
    
    DvoiNic
    17.06.2025 18:49
    #28456672
    В далеком 1993 в Москве была одна из первых в пост-СССР "компьютерных выставок". Там была куча стендов модного тренда - визуального программирования. Обещали, что через пару лет не будет никаких "текстов" - все будет в графах/блок-схемах. Так вот, пришла моя очередь расстроить вас...
    
    программировать что-то серьезное можно на любом полном по Тьюрингу языке. И всё равно как он выглядит. Хоть буковки, хоть стрелочки, хоть картинки.
    
    Да и плац можно подметать ломиком. Но если хотим, чтоб было быстро и чисто - берем метлу. а ломик применяется не чтоб было быстро и чисто, а чтоб "задолбать".
    
    UserSergeyB
    17.06.2025 18:49
    #28456772
    Но если хотим, чтоб было быстро и чисто
    
    Вы упёрлись в то, что обычный текст это максимум, чтобы делать быстро. И не можете (или просто не хотите) поверить, что бывает что-то ещё.
    
    Как в далеком прошлом, нужен человек, который придумает калькулятор, в то время, когда все пользуются счетами и говорят, что это удобно.
    
    DvoiNic
    17.06.2025 18:49
    #28456818
    пока текст - самое удобное. Емкое. И общепонятное.
    
    А визуальщина - не взлетела.
    
    UserSergeyB
    17.06.2025 18:49
    #28456938
    Пока ещё не дожили. И компьютеров когда-то не было.
    
    vadimr
    17.06.2025 18:49
    #28456834
    Графы безусловно хуже текста, потому что их выразительные средства более ограничены (хотя в смысле Тьюринга они могут быть эквивалентны). Представьте хотя бы простую рекурсию блок-схемой. Или макрос. Не говорю про самомодифицирующийся код.
    
    (У меня ожидается публикация статьи примерно на эту тему в журнале "Информационно-измерительные и управляющие системы", после её выхода я, наверное, напишу и на хабре).
    
    Кроме того, многие люди вообще в силу индивидуальных особенностей очень плохо воспринимают схемы. Хотя другие люди их любят.
    
    DvoiNic
    17.06.2025 18:49
    #28456980
    Кроме того, многие люди вообще в силу индивидуальных особенностей очень плохо воспринимают схемы. Хотя другие люди их любят.
    
    Ну, каждому инструменту своё место. "Схему электрическую принципиальную" можно выразить и в виде netlist'а (т.е. текстом), но в привычном виде с УГО она человеку понятнее. С визуальным программированием - наоборот.
    
    vadimr
    17.06.2025 18:49
    #28457408
    Если речь идёт про какой-нибудь усилитель, то да, но согласитесь, что микропроцессор понятнее на верилоге, чем в виде принципиальной схемы.
    
    Есть подозрение, что просто никто не поставил перед собой и не решил задачу текстового представления аналоговых схем, понятного человеку.
    
    DvoiNic
    17.06.2025 18:49
    #28457516
    согласитесь, что микропроцессор понятнее на верилоге
    
    микророцессор - абсолютно согласен. а вот "схема, в которой используется микропроцессор" (ну или любая другая безпроцессорная цифрятина - может быть понятнее в виде схемы). Аналог - там схема привычнее, но опять же, симуляторы хранят ее в некоем структурированном тексте.
    
    Есть подозрение, что просто никто не поставил перед собой и не решил задачу текстового представления аналоговых схем, понятного человеку.
    
    В школьные времена (примерно 1980-й) с приятелем схемами по телефону обменивались (если болел кто-то из нас, например). Словами описывали. (т.е. записать на бумагу - и было бы "текстовое представление"). Но это так себе занятие. Примерно как "программировать блок-схемами".
    
    Serge78rus
    17.06.2025 18:49
    #28456994
    Да есть уже достаточно давно такие языки, например GRAPH из среды SIMATIC STEP-7 для программирования PLC, приходилось писать на нем и я Вам скажу - это просто сущий ад. Основная, но далеко не единственная проблема - это очень низкая плотность информации на экране. Чтобы обозреть хоть сколь-нибудь сложную логическую конструкцию приходится постоянно крутить масштабирование, поскольку или ничего не лезет в экран и не видно логику, или шрифт становится мелким до полной нечитаемости. Хотя на простейших примерах все выглядит очень удобно, но это удобство исчезает напрочь когда начинаешь писать реальный достаточно сложный алгоритм управления.
    
    После этого тот же C с его if и else, пусть даже "многоэтажными", кажется верхом совершенства. И даже всеми проклятый goto уже не выглядит таким уж извращением.
  1. PerroSalchicha
    17.06.2025 18:49
    #28454722
    Там двоичные данные, удобные ровно до тех пор, пока есть текстовый редактор.
    
    Т.е. удобные вообще всегда, когда у вас есть компьютер или что-то близкое к нему.
    
    И если для кода когда-то найдется формат по-лучше, чем обычный текст, то он может когда-то стать нативным. Напишут для всех осей нативный инструмент, которым вы его сможете открывать и читать так, как вы его написали .
    
    Т.е. вообще никогда. О чём же я и пишу :)
    
    UserSergeyB
    17.06.2025 18:49
    #28455608
    Т.е. вообще никогда. О чём же я и пишу :)
    
    Т.е. по вашему кроме текстового формата ничего не придумали. Картинки тоже как текст просматриваете?
    
    Редактируйте машинный код. Он надёжнее. От кодировки текста не зависит :)
    
    JBFW
    17.06.2025 18:49
    #28456600
    машинный код зависит от процессора, как минимум.
    
    Вы этого не знали?
    
    UserSergeyB
    17.06.2025 18:49
    #28456660
    Решили проверить мои знания :)
    
    У текста побольше зависимостей, поверьте.
    
    JBFW
    17.06.2025 18:49
    #28457552
    Например?
    
    PerroSalchicha
    17.06.2025 18:49
    #28457858
    Т.е. по вашему кроме текстового формата ничего не придумали
    
    Сэр, моя нейронка зависла, пытаясь уловить какую-то логическую связь вашего ответа с моим постом. Она хоть была?
    
    От кодировки текста не зависит
    
    Да оно и в текстовых файлах не особо зависит, по крайней мере, если вы не 1Сник
    
    UserSergeyB
    17.06.2025 18:49
    #28457906
    Да оно и в текстовых файлах не особо зависит
    
    Тогда всё ясно. Успехов.
    
    PerroSalchicha
    17.06.2025 18:49
    #28458760
    Вы так написали, как будто бы у вас есть основания считать, что я неправ, а вы типа что-то знаете :)

kenomimi
17.06.2025 18:49
#28448996
А как его обратно декомипилить из разобранного и обработанного графа? Там же все метаданные убираются... Или я что-то не так понимаю?
1. fransua Автор
  17.06.2025 18:49
  #28449084
  Сериализовать в текст? Этим постоянно все IDE занимаются, при форматировании кода, парсят в AST и рендерят в текст согласно выбранному code-style.
  А какие метаданные, комментарии? Они тоже есть в AST
  1. kamaz1
    17.06.2025 18:49
    #28449752
    А если файл в данный момент синтаксически некорректен, исправлять нет времени, надо сохранить и идти по делам?
    
    Nalivai
    17.06.2025 18:49
    #28454296
    Пишите всегда только корректные файлы, чтобы с первого раза работало. Тогда и на тестах можно сэкономить
    
    warkid
    17.06.2025 18:49
    #28454874
    Ага. Надо еще, чтобы компилировался и линтеры проходил без ошибок - иначе отказываться сохранять!
    
    Ndochp
    17.06.2025 18:49
    #28454356
    Нужно использовать ИДЕ которая переводит код из одного допустимого состояния в другое.
    https://scratch.mit.edu/projects/editor/?tutorial=getStarted
  1. Jijiki
    17.06.2025 18:49
    #28449878
    то что вы предлагаете делает визуалка на фоне(это не точно могу ошибаться), кидает внутрянку кв в таблицы по какой-то логике, но суть не меняется от этого, когда это всё вместе запускается, так кошмар начинается, как проверить и о чем я.
    
    предположим мы на среднем ПК, откроем движок UE в визуалке!, и начнем писать в определенный момент проект самого всего двигла поттянется и начнётся веселье если это не пофиксили
    
    тут такая ситуация что эти ситуации надо минимизировать и конкретизировать операции прогонок(тоесть не чтоб оркестр запускался и на сессии ввода всё запускалось и считалось а как-то более тонко и продуманно)
    
    мы пришли к проблеме которая не трвиальная даже на сегодняшний день, у этой проблемы 2 ситуации, цена за удобство в рантайме за оркестр, и цена за конкретную операцию и её ожидание, как найти баланс не знаю
    
    вот на последнем абзаце и стоит проблема того как это достигается, гдето можно всё отключить, но реализация текстового редактора может не позволить всё отключить, хотя нам надо рисовать текст только по факту получается, и если углубляться в нюансы реализации текста она тоже нагрузная, поэтому всё это имеет цену в редакторах это в среднем так не везде, например какой-то блокнот может быть эффективнее визуалки, за счет того что просто рисует текст
    
    тоесть это получается целый комплекс интерфейсов должен быть, чтобы можно было настраивать +-
  1. SergeyProkhorenko
    17.06.2025 18:49
    #28452978
    Было бы ошибкой сериализовать в текст! Если уж Вы решились порвать с текстом, то нужно это делать не только в способе хранения программного кода, но и в способе отображения программного кода человеку. Никому на самом деле не нужен единый текст программы (листинг), если логически он состоит из проектов, слоев, модулей, функций, циклов и т.п. Способ отображения программного кода должен повторять его логическую структуру. Для этого есть самые разнообразные элементы интерфейса: вкладки, карточки, блоки, древовидные списки и т.д.
    
    То, за что Вы взялись, совершенно правильно. Но это не что-то совершенно новое. Советую изучить имеющийся опыт в этой области:
    
    https://zouev.blogspot.com/2008/09/blog-post.html
    
    https://habr.com/ru/companies/infopulse/articles/302146/
    
    https://devby.io/news/programmirovanie-bez-tekstovyh-faylov
    
    https://guilabs.net/
    
    https://sites.google.com/site/purebuilder/
    
    fransua Автор
    17.06.2025 18:49
    #28453950
    Спасибо!
    Да, я согласен, думал и про отображение в виде блоков.
    Честно говоря, судя по реакции здесь, даже хранение не в текстовом виде - все еще революционная идея, хотя и не новая.
    
    tenzink
    17.06.2025 18:49
    #28454116
    Идея хранить в не текстовом виде не новая, не революционная и себя не оправдавшая. Было уже не раз, и либо благополучно скончалось, либо осело в нишевых решениях. R.I.P.
    
    tbl
    17.06.2025 18:49
    #28454732
    среди продуктов ibm visualage была ide для java, проекты хранила в виде бинарных файлов (проект по сути был базой данных для хранения кода), код при работе парсился и хранился в бинарном виде, готовом для запуска на их виртуальной машине, написанной на smalltalk, потом лавку прикрыли, какие-то наработки передали в eclipse foundation, бинарное хранение выпилили к херам, как и эту странную виртуальную машину
    
    Kano
    17.06.2025 18:49
    #28456528
    Вы предлагаете навернуть ещё один слой над уже имеющимся, т.е. добавить ещё одну точку отказа. Именно это мне больше всего не нравится в вашем предложении.
    
    SergeyProkhorenko
    17.06.2025 18:49
    #28458936
    Реакция здесь очень разная. Например, сейчас у Вашей статьи уже 30 плюсов, значит, есть много сторонников. Люди зачастую на любые новшества реагируют негативно (см. синдром утенка), но это не означает что они правы. Прав тот, кто окажется прав в конечном счете, а игра еще только начата.
    
    Есть еще один важный момент: графическое программирование на основе всякого рода блок-схем (программирование роботов, Дракон, Camunda, Anchor Modeler, ETL) дискредитировало идею отказа от текстового представления программного кода. Блок-схемы имеют очень ограниченный успех в узких нишах, потому что блок-схемы неудобны для больших проектов (не умещаются в поле зрения, требуют усилий по поиску блоков и изменению расположения блоков), порождают плохой программный код и имеют ограниченные выразительные возможности (не реализуют многие необходимые возможности языков программирования). Но большинство людей просто не представляют себе других вариантов, кроме бесконечного листинга текстового программного кода (в лучшем случае разделенного на модули) или столь же неоглядной блок-схемы.
    
    Я думаю, что визуальное представление программного кода должно быть блочным - не в смысле блоков блок-схем любого типа, а в смысле структурного программирования. Циклы и ветвления должны отображаться в виде блоков-виджетов в прокручиваемой вкладке или карточке. Последовательно обрабатываемые инструкции должны образовывать вертикальные списки, как строки в программном коде на Python. Вкладки и карточки должны организовываться в базу данных с различными инструментами поиска, а не только с поиском по древовидному списку. Модули должны организовываться в слои и иные группы, соответствующие выбранным архитектурным паттернам.
    
    Вместо клавиатурного ввода должны в основном использоваться разнообразные средства интерфейса, в том числе с использованием автодополнения кода и ИИ. Потребуется внести изменения и в синтаксис языка. Например, точки с запятой для разделения операторов и фигурные скобки для тела функции уже не будут нужны - их заменят виджеты.
    
    Система управления версиями должна быть встроенной (Git, прощай!). Должны быть встроенные средства для удаленной работы. Для предотвращения vendor lock-in должны быть открытые стандарты, форматы и протоколы.
    
    А вообще многие комментарии к этой статье, направленные против отказа от текста, на самом деле полезны для отказа от текста, так как эти комментарии раскрывают реальные проблемы, для которых нужно просто найти решение.
    
    BugM
    17.06.2025 18:49
    #28459134
    А как эту вашу красоту в виме редактировать? А sedом или простым регэкспом как пройтись?
    
    Да, это обязательные фичи. Особенно в больших кодовых базах.
    
    SergeyProkhorenko
    17.06.2025 18:49
    #28459198
    В виме - никак. А также в ноутпаде++, блокноте и т.п. древних редакторах. Нужно новое средство разработки, которого еще нет
    
    JBFW
    17.06.2025 18:49
    #28459232
    Как раз есть - ЧатЖПТ, например.
    
    В нем всё внутри хранится, и можно из него что-то извлекать в том числе в виде текста, экспортировать.
    
    Вот только есть нюанс...
    
    SergeyProkhorenko
    17.06.2025 18:49
    #28459276
    Ну что ж, давайте попросим сообщество провести эксперимент - отредактировать AST с помощью LLM и посмотреть, что из этого получится. Мне кажется, что ничего хорошего, так как LLM часто теряет контекст, галлюцинирует, забывает, своевольничает и т.п.
    
    BugM
    17.06.2025 18:49
    #28459262
    Классный план. А оно точно прорастет на все те многие тысячи серверов? Там что-то около линукс лайк и бсд операционок. Любых версий и сборок выпущенных за последние 20 лет. Интерфейс - ssh, нет картинка не пролезет.
    
    Подозреваю что тем кто железки программирует тоже надо. У них зоопарк еще больше.
    
    SergeyProkhorenko
    17.06.2025 18:49
    #28459302
    Legacy must die. Любая информационная система лет через 10-20 обрушивается под тяжестью накопленных ошибок или новых требований и заменяется новой. Вот для этого и нужно новое средство разработки
    
    BugM
    17.06.2025 18:49
    #28459326
    Sweet summer child
    
    RulenBagdasis
    17.06.2025 18:49
    #28459770
    Кто будет оплачивать этот банкет? (с)
    
    Чтобы системы не обрушивались через 10 лет, проектировать их должны не двадцатидвухлетние как-бы синьоры с 3 годами опыта, а настоящие синьоры, лиды и архитекторы с опытом 10+, а лучше 15+ лет, которые видели некоторое дерьмо и понимают, как решения, принимаемые сейчас, аукнутся в будущем.
    
    vadimr
    17.06.2025 18:49
    #28459298
    Если, например, я ставлю плюс статье, это не значит, что я согласен с её тезисами. Может быть просто интересная полемика.

Buharin
17.06.2025 18:49
#28449028
На хабре школьники пишут эссе на тему ~~"Кем я хочу стать?"~~ "Как я вижу будущее?"
1. Bonus2k
  17.06.2025 18:49
  #28451748
  Сейчас бы писать код в AST дереве согласно лучшим практикам SOSAL, а не это всё
  1. CrazyOpossum
    17.06.2025 18:49
    #28452160
    Не хотите поговорить о Боге нашем - LISP'е?
    
    Turbo_Pascal_55
    17.06.2025 18:49
    #28455400
    Ересь.
  1. Moog_Prodigy
    17.06.2025 18:49
    #28452180
    Ага и работать в "ОБОСРАЛСЯ". Но туда попасть сложно.
    
    venanen
    17.06.2025 18:49
    #28454426
    Да, сложно. Алгособесы + надо чтобы парадигма govno от зубов отскакивало...
  1. warkid
    17.06.2025 18:49
    #28454882
    А АСТ дерево представлено в виде XML - и вот его набирать руками!
    
    BugM
    17.06.2025 18:49
    #28454886
    Может стоит пропустить все эти промежуточные шаги и просто писать на Лиспе?

VladimirFarshatov
17.06.2025 18:49
#28449038
Рекомендую ознакомиться с системами Графит-Флокс и Рапира+Школьница. Ещё можно погуглить Р-Технологии Глушкова. Такое ощущение, что Вы изобрели велосипед, но могу и ошибаться. )
1. fransua Автор
  17.06.2025 18:49
  #28449108
  А с какими аспектами этих систем Вы предлагаете ознакомиться? Краем уха смотрел когда-то давно на дракона, ничего особенного не заметил.
  1. VladimirFarshatov
    17.06.2025 18:49
    #28450966
    Как единое решение по представлению текста кодовой базы, БД хранения как "файловой системы" и формальных описаний входа-выхода, как элемента АСТ дерева. Там ещё, в ДРАКОНе есть версия ИДЕ Тышова (Мурманск), где комментарии к коду "иерархичны": ТЗ, решение, тестировщик, приемка. Несколько типов комментов. В целом ДРАКОН - малая часть Графит-Флокс. Но .. найти его описание не так просто в Сети к сожалению.
    
    fransua Автор
    17.06.2025 18:49
    #28451254
    Да, звучит похоже, надо копать что там напридумали.
    Причины по которым это не прижилась тогда могут сейчас не работать. Может быть даже есть смысл воплотить те идеи сейчас и оно заведётся, а может стоит адаптировать и улучшить
    
    VladimirFarshatov
    17.06.2025 18:49
    #28451574
    Прижилось, но не публично. ) Многое из того, что появилось как откровения "на Западе" вышло отсюда, в частности разные UML диаграммы по мере утечки наших спецов "туда".. Глушков и его Р-Технологии это лохматые 60-70е годы вообще-то. )

JohnSmith_007
17.06.2025 18:49
#28449072
А еще заменить клавиатуру голосовым вводом а мышку глазным трекером !
1. Shura_m
  17.06.2025 18:49
  #28451930
  Устарело.
  
  Электроды сразу в мозг вживлять.
  
  И вместо монитора тоже сигнал подавать на зрительную кору мозга.
  1. Tishka17
    17.06.2025 18:49
    #28451974
    Зачем использовать зрение, если мы хотим абстракции программировать. Давайте в лобные доли сразу
    
    andi123
    17.06.2025 18:49
    #28453270
    "Давайте лобные доли сразу отсечем"
    
    исправил

CloudlyNosound
17.06.2025 18:49
#28449094
Хранить код можно в любом виде. Редактировать будете в текстовом виде, как ни крути.

В итоге, некоторые "слои абстракции" просто меняются местами. Только, вместо моментального открытия текста, придется ждать, пока по диффам соберётся требуемая версия.
1. fransua Автор
  17.06.2025 18:49
  #28449126
  Хранить в CVS дельты или снепшоты - это перпендикулярный вопрос, я его не рассматривал.
  Открытие текста в современных IDE не моментальное - он парсится в AST и потом рендерится на экран. Хотя бы для того чтобы раскрасить ключевые слова. Я предлагаю убрать первый шаг.
  1. CloudlyNosound
    17.06.2025 18:49
    #28449168
    В продуманных IDE парсится фоном, а доступ к редактированию получаешь сразу.
    
    Вам выше правильно написали. Подобные эксперименты уже были.
    
    Если вас увлекает проект, продолжайте. Потом посмотрите на отклик сообщества.
  1. dv0ich
    17.06.2025 18:49
    #28450642
    А я вот если пишу код не в IDE, а в текстовом редакторе (да, мы существуем!) - как ваш подход может меня осчастливить?
    
    Soika1
    17.06.2025 18:49
    #28453134
    Зачем IDE если есть Emacs?
    
    JBFW
    17.06.2025 18:49
    #28456622
    VIM

Mishootk
17.06.2025 18:49
#28449190
То есть по сути разработчик вообще не заметит разницы, кроме случая, когда ему придется заглянуть в исходники не имея под рукой IDE? А не имея под рукой IDE как бы все.

Это типа что-то айфона? Вроде бы на устройстве музыки накачано, фильмов, фотографий, но вот просто так скинуть на произвольное соседнее устройство никак. И забрать тоже.
1. fransua Автор
  17.06.2025 18:49
  #28449224
  Git тоже хранит код не в текстовом виде, если я не ошибаюсь. Но при checkout сериализует все в текст. При желании и тут можно так же. Но при редактирование текстового файла будут такие же плохие диффы, как и сейчас.
  1. hogstaberg
    17.06.2025 18:49
    #28451850
    Таки в текстовом. Максимум "нетекстовости" - там могут быть compressed diffs в packfile. Но даже это и близко не токены с графами, это просто такой метод эффективно использовать место при хранении нескольких версий одного текстового файлика, имеющих незначительные отличия.

k12th
17.06.2025 18:49
#28449208
Я обожаю текстовые файлы. Если есть выбор, я и худлит пишу в маркдауне. SVG я делаю в текстовом редакторе. Если бы я знал плейнтекстовый формат для растровых изображений, я бы его использовал.
1. garwall
  17.06.2025 18:49
  #28449386
  https://en.wikipedia.org/wiki/X_PixMap
1. berez
  17.06.2025 18:49
  #28449676
  Если бы я знал плейнтекстовый формат для растровых изображений, я бы его использовал.
  
  XPM же ж.
  1. mephastopheles
    17.06.2025 18:49
    #28451552
    сто раз ещё напишите, он же не понял с одного
1. apevzner
  17.06.2025 18:49
  #28449876
  Есть еще Netbpm. Его прям даже не только X11 понимают...
  
  https://en.wikipedia.org/wiki/Netpbm
1. ProgerMan
  17.06.2025 18:49
  #28450008
  Аналогично. Если надо написать что-то небольшое, то это летит в Телеграм в сохранённые сообщения. Если надо для чего-то большого, то создаю markdown - и вперёд. Не надо ничего выдумывать, если есть простые варианты. Максимум - потом в fb2 сконвертировать для форматирования.
1. CuriousJustifier
  17.06.2025 18:49
  #28456422
  Сейчас и музыку можно в текстовом виде писать: https://strudel.cc/workshop/getting-started/
  1. DvoiNic
    17.06.2025 18:49
    #28456704
    почему "сейчас"? во-первых, мы подобие этого еще для Корветов делали. а во-вторых, Csound'у уже под 40 лет..
    
    garwall
    17.06.2025 18:49
    #28456814
    а уж нотной записи..
    
    (ладно, тут еще вопрос, символьная запись - это текстовая или нет)

Почему мы все еще храним код в текстовых файлах? +33

Текст

Файловые системы

Парсинг

Диффы

Итого

Система версионирования AST

Мечты о будущем

Преимущества

Комментарии (265)

fransua Автор

fransua Автор

fransua Автор

fransua Автор

fransua Автор

fransua Автор