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

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

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

Текст

Компьютеры оперируют бинарными данными, поэтому для представления текста им приходится использовать кодировки. Существует много вариантов: 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)


  1. PerroSalchicha
    17.06.2025 18:49

    Очевидно, нет. Это неудобно, ненадежно и может привести к несогласованности.

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

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

    В то же время преимущества каких-то других форматов для меня не очевидны. Удобство? Нет ничего удобнее нативного для меня формата. Надёжность? Текстовый файл надёжен настолько, насколько надёжен носитель, на котором он записан. Лучше этого и не придумаешь. Размер хранилища? Да, в этом плане текстовый файл ни разу не оптимален, но... на моём компьютере весь текстовый контент едва ли займёт несколько процентов от самого маленького накопителя на 256Гб. А остальное занимает отнюдь не код, а всякого рода бинарники и медиаконтент.


    1. BobovorTheCommentBeast
      17.06.2025 18:49

      Тут наоборот материшься на какого нибудь вендора IDE или тулзов, который хранит файлы не в текстовом формате (или в файлах, которые еще хранят кучу локальной\временной информации).


    1. pnmv
      17.06.2025 18:49

      мне, почему-то, вспомнились какие-то лекции, по программированию, кажется, на perl: весьма юный лектор показывает пример какого-то кода, весьма компактный, внятный и читаемый, а потом, такой - "ну, это муторошно!", после чего выдает такую простыню, которую прочтешь то не с первого раза.


      1. blind_oracle
        17.06.2025 18:49

        Perl он, как и его регулярки, часто нечитаем) Write Once, Read Never


        1. pnmv
          17.06.2025 18:49

          Язык, как язык...

          Если не придерживаться, при разработке, php5-style, всё как-то не так грустно, пока слишком творческие личности не вмешиваются. Да и вообще, perlcritic никто не отменял.

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


        1. vdudouyt
          17.06.2025 18:49

          Из нечитаемого там только тот самый запускающий rm -rf однострочник, некогда настолько травмировавший неокрепшую психику джунов-миллениалов, что теперь утверждения о якобы write only природе Perl можно встретить буквально при каждом его упоминании (причем в основном от индивидуумов, более нигде с ним не сталкивавшихся).

          Реальный write only из того, что я видел это C++-поделки отдельных template only-мастеров. Но, конечно, меметичность совсем не та.


          1. blind_oracle
            17.06.2025 18:49

            Я писал на перле последний раз лет 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>>>>>>>>>>


            1. JBFW
              17.06.2025 18:49

              Так может быть писать надо было как-то попроще?

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


              1. blind_oracle
                17.06.2025 18:49

                Может быть. Но я писал на десятке разных языков наверное, и такая проблема была только с Перлом :)


                1. vdudouyt
                  17.06.2025 18:49

                  Ну не знаю, как по мне так примерно на уровне остальных ЯП с динамической типизацией )

                  Кстати, чтобы избежать проблем со скоупингом переменных многие крупные кодовые базы на Perl написаны на его strict-подмножестве (use strict). Хотя, вон, в тех же PHP, Lua и до недавнего времени и Python как-то не особо парятся по этому поводу, и ничего.


                1. JBFW
                  17.06.2025 18:49

                  Люди с опытом начинают писать лучше...
                  Хотя до сих пор использую некоторые свои блоки многолетней давности - нет никаких проблем с пониманием чего они там делают, все же написано в коде...


        1. JBFW
          17.06.2025 18:49

          Вы его видели? )

          Похоже, представление о коде на Perl складывается из творений какеров, которые умеют вместо

          print "hello world\n";

          написать что-то типа

          $<->^$2>>^&3@\#

          и потом радуются как круто и непонятно получилось


          1. blind_oracle
            17.06.2025 18:49

            Я на нём (ну, на mod_perl) писал всякие веб-бекенды несколько лет (давно уже правда). Так что да, видел.


            1. JBFW
              17.06.2025 18:49

              Стиль вероятно.

              Можно написать как-то так:

              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, всё и так понятно.


        1. UplandDivan
          17.06.2025 18:49

          Perl нечитаем? Это вы еще C++ >= 11 не видели )))


          1. UFO_01
            17.06.2025 18:49

            Сейчас пойдёт потеха. Имхо, у раста синтаксис куда более нечитаемый.


    1. UserSergeyB
      17.06.2025 18:49

      Потому что вы так привыкли.

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

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


      1. omaxx
        17.06.2025 18:49

        Так это и про книги можно так сказать, что там не текст, а это всего лишь испачканные типографской краской стопки бумаги


        1. UserSergeyB
          17.06.2025 18:49

          Верно. Если вы язык, на котором она написана, не знаете, для вас это просто краска на бумаге.


          1. omaxx
            17.06.2025 18:49

            нет... для меня это все так же текст, но только на незнакомом мне языке


            1. UserSergeyB
              17.06.2025 18:49

              Почему вы решили, что там текст? Возможно на другом языке эта краска на бумаге образует картинку.


              1. omaxx
                17.06.2025 18:49

                вы сейчас имеете ввиду какой-то определенный язык или просто фантазируете?


                1. UserSergeyB
                  17.06.2025 18:49

                  Я про краску на бумаге. Вы сами привели такое сравнение.

                  Вот например, если в книге на всю страницу напечатать огромный QR-код. Вы тоже подумаете, что это текст?


                  1. omaxx
                    17.06.2025 18:49

                    Ну насколько я знаю, на свете нет людей, которые свободно читают в куар-кодах....

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


                    1. UserSergeyB
                      17.06.2025 18:49

                      Я об этом и писал, что мы привыкли выражать свои мысли текстом.

                      Хотя иногда удобнее для представления алгоритмов рисовать блок-схемы.

                      Связка:

                      • двоичный формат хранения блок-схем;

                      • нативный редактор блок-схем;

                      • компилятор из блок-схем в машинный код;

                      позволяет программировать вообще без текста.

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


                      1. omaxx
                        17.06.2025 18:49

                        тем не менее мы вот сейчас с вами общаемся именно текстом, а не смайликами, не стикерами, и не картинками...


                      1. UserSergeyB
                        17.06.2025 18:49

                        Так надо было сказать, я бы прислал стикер :)


                      1. omaxx
                        17.06.2025 18:49

                        а вы уверены, что он отобразится в моем браузере?


                      1. UserSergeyB
                        17.06.2025 18:49

                        В крайнем случае посмотрите как на пятнышки на мониторе на неизвестном языке.


                      1. Orisava
                        17.06.2025 18:49

                        Вы имеете отношение к 1С?


                      1. UserSergeyB
                        17.06.2025 18:49

                        Нет.


                      1. DvoiNic
                        17.06.2025 18:49

                        Связка:

                        • двоичный формат хранения блок-схем;

                        • нативный редактор блок-схем;

                        • компилятор из блок-схем в машинный код;

                        позволяет программировать вообще без текста.

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


                      1. UserSergeyB
                        17.06.2025 18:49

                        Я описал любой процесс программирования. Есть исходник, редактор и компилятор.

                        И если вы думаете, что графы (те же блок-схемы) хуже текста, то я вас расстрою.

                        А программировать что-то серьезное можно на любом полном по Тьюрингу языке. И всё равно как он выглядит. Хоть буковки, хоть стрелочки, хоть картинки.


                      1. DvoiNic
                        17.06.2025 18:49

                        В далеком 1993 в Москве была одна из первых в пост-СССР "компьютерных выставок". Там была куча стендов модного тренда - визуального программирования. Обещали, что через пару лет не будет никаких "текстов" - все будет в графах/блок-схемах. Так вот, пришла моя очередь расстроить вас...

                        программировать что-то серьезное можно на любом полном по Тьюрингу языке. И всё равно как он выглядит. Хоть буковки, хоть стрелочки, хоть картинки.

                        Да и плац можно подметать ломиком. Но если хотим, чтоб было быстро и чисто - берем метлу. а ломик применяется не чтоб было быстро и чисто, а чтоб "задолбать".


                      1. UserSergeyB
                        17.06.2025 18:49

                        Но если хотим, чтоб было быстро и чисто

                        Вы упёрлись в то, что обычный текст это максимум, чтобы делать быстро. И не можете (или просто не хотите) поверить, что бывает что-то ещё.

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


                      1. DvoiNic
                        17.06.2025 18:49

                        пока текст - самое удобное. Емкое. И общепонятное.

                        А визуальщина - не взлетела.


                      1. UserSergeyB
                        17.06.2025 18:49

                        Пока ещё не дожили. И компьютеров когда-то не было.


                      1. vadimr
                        17.06.2025 18:49

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

                        (У меня ожидается публикация статьи примерно на эту тему в журнале "Информационно-измерительные и управляющие системы", после её выхода я, наверное, напишу и на хабре).

                        Кроме того, многие люди вообще в силу индивидуальных особенностей очень плохо воспринимают схемы. Хотя другие люди их любят.


                      1. DvoiNic
                        17.06.2025 18:49

                        Кроме того, многие люди вообще в силу индивидуальных особенностей очень плохо воспринимают схемы. Хотя другие люди их любят.

                        Ну, каждому инструменту своё место. "Схему электрическую принципиальную" можно выразить и в виде netlist'а (т.е. текстом), но в привычном виде с УГО она человеку понятнее. С визуальным программированием - наоборот.


                      1. vadimr
                        17.06.2025 18:49

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

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


                      1. DvoiNic
                        17.06.2025 18:49

                        согласитесь, что микропроцессор понятнее на верилоге

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

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

                        В школьные времена (примерно 1980-й) с приятелем схемами по телефону обменивались (если болел кто-то из нас, например). Словами описывали. (т.е. записать на бумагу - и было бы "текстовое представление"). Но это так себе занятие. Примерно как "программировать блок-схемами".


                      1. Serge78rus
                        17.06.2025 18:49

                        Да есть уже достаточно давно такие языки, например GRAPH из среды SIMATIC STEP-7 для программирования PLC, приходилось писать на нем и я Вам скажу - это просто сущий ад. Основная, но далеко не единственная проблема - это очень низкая плотность информации на экране. Чтобы обозреть хоть сколь-нибудь сложную логическую конструкцию приходится постоянно крутить масштабирование, поскольку или ничего не лезет в экран и не видно логику, или шрифт становится мелким до полной нечитаемости. Хотя на простейших примерах все выглядит очень удобно, но это удобство исчезает напрочь когда начинаешь писать реальный достаточно сложный алгоритм управления.

                        После этого тот же C с его if и else, пусть даже "многоэтажными", кажется верхом совершенства. И даже всеми проклятый goto уже не выглядит таким уж извращением.


      1. PerroSalchicha
        17.06.2025 18:49

        Там двоичные данные, удобные ровно до тех пор, пока есть текстовый редактор.

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

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

        Т.е. вообще никогда. О чём же я и пишу :)


        1. UserSergeyB
          17.06.2025 18:49

          Т.е. вообще никогда. О чём же я и пишу :)

          Т.е. по вашему кроме текстового формата ничего не придумали. Картинки тоже как текст просматриваете?

          Редактируйте машинный код. Он надёжнее. От кодировки текста не зависит :)


          1. JBFW
            17.06.2025 18:49

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

            Вы этого не знали?


            1. UserSergeyB
              17.06.2025 18:49

              Решили проверить мои знания :)

              У текста побольше зависимостей, поверьте.


              1. JBFW
                17.06.2025 18:49

                Например?


          1. PerroSalchicha
            17.06.2025 18:49

            Т.е. по вашему кроме текстового формата ничего не придумали

            Сэр, моя нейронка зависла, пытаясь уловить какую-то логическую связь вашего ответа с моим постом. Она хоть была?

            От кодировки текста не зависит

            Да оно и в текстовых файлах не особо зависит, по крайней мере, если вы не 1Сник


            1. UserSergeyB
              17.06.2025 18:49

              Да оно и в текстовых файлах не особо зависит

              Тогда всё ясно. Успехов.


              1. PerroSalchicha
                17.06.2025 18:49

                Вы так написали, как будто бы у вас есть основания считать, что я неправ, а вы типа что-то знаете :)


  1. kenomimi
    17.06.2025 18:49

    А как его обратно декомипилить из разобранного и обработанного графа? Там же все метаданные убираются... Или я что-то не так понимаю?


    1. fransua Автор
      17.06.2025 18:49

      Сериализовать в текст? Этим постоянно все IDE занимаются, при форматировании кода, парсят в AST и рендерят в текст согласно выбранному code-style.
      А какие метаданные, комментарии? Они тоже есть в AST


      1. kamaz1
        17.06.2025 18:49

        А если файл в данный момент синтаксически некорректен, исправлять нет времени, надо сохранить и идти по делам?


        1. Nalivai
          17.06.2025 18:49

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


          1. warkid
            17.06.2025 18:49

            Ага. Надо еще, чтобы компилировался и линтеры проходил без ошибок - иначе отказываться сохранять!


        1. Ndochp
          17.06.2025 18:49

          Нужно использовать ИДЕ которая переводит код из одного допустимого состояния в другое.
          https://scratch.mit.edu/projects/editor/?tutorial=getStarted


      1. Jijiki
        17.06.2025 18:49

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

        предположим мы на среднем ПК, откроем движок UE в визуалке!, и начнем писать в определенный момент проект самого всего двигла поттянется и начнётся веселье если это не пофиксили

        тут такая ситуация что эти ситуации надо минимизировать и конкретизировать операции прогонок(тоесть не чтоб оркестр запускался и на сессии ввода всё запускалось и считалось а как-то более тонко и продуманно)

        мы пришли к проблеме которая не трвиальная даже на сегодняшний день, у этой проблемы 2 ситуации, цена за удобство в рантайме за оркестр, и цена за конкретную операцию и её ожидание, как найти баланс не знаю

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

        тоесть это получается целый комплекс интерфейсов должен быть, чтобы можно было настраивать +-


      1. SergeyProkhorenko
        17.06.2025 18:49

        Было бы ошибкой сериализовать в текст! Если уж Вы решились порвать с текстом, то нужно это делать не только в способе хранения программного кода, но и в способе отображения программного кода человеку. Никому на самом деле не нужен единый текст программы (листинг), если логически он состоит из проектов, слоев, модулей, функций, циклов и т.п. Способ отображения программного кода должен повторять его логическую структуру. Для этого есть самые разнообразные элементы интерфейса: вкладки, карточки, блоки, древовидные списки и т.д.

        То, за что Вы взялись, совершенно правильно. Но это не что-то совершенно новое. Советую изучить имеющийся опыт в этой области:


        1. fransua Автор
          17.06.2025 18:49

          Спасибо!
          Да, я согласен, думал и про отображение в виде блоков.
          Честно говоря, судя по реакции здесь, даже хранение не в текстовом виде - все еще революционная идея, хотя и не новая.


          1. tenzink
            17.06.2025 18:49

            Идея хранить в не текстовом виде не новая, не революционная и себя не оправдавшая. Было уже не раз, и либо благополучно скончалось, либо осело в нишевых решениях. R.I.P.


          1. tbl
            17.06.2025 18:49

            среди продуктов ibm visualage была ide для java, проекты хранила в виде бинарных файлов (проект по сути был базой данных для хранения кода), код при работе парсился и хранился в бинарном виде, готовом для запуска на их виртуальной машине, написанной на smalltalk, потом лавку прикрыли, какие-то наработки передали в eclipse foundation, бинарное хранение выпилили к херам, как и эту странную виртуальную машину


          1. Kano
            17.06.2025 18:49

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


          1. SergeyProkhorenko
            17.06.2025 18:49

            Реакция здесь очень разная. Например, сейчас у Вашей статьи уже 30 плюсов, значит, есть много сторонников. Люди зачастую на любые новшества реагируют негативно (см. синдром утенка), но это не означает что они правы. Прав тот, кто окажется прав в конечном счете, а игра еще только начата.

            Есть еще один важный момент: графическое программирование на основе всякого рода блок-схем (программирование роботов, Дракон, Camunda, Anchor Modeler, ETL) дискредитировало идею отказа от текстового представления программного кода. Блок-схемы имеют очень ограниченный успех в узких нишах, потому что блок-схемы неудобны для больших проектов (не умещаются в поле зрения, требуют усилий по поиску блоков и изменению расположения блоков), порождают плохой программный код и имеют ограниченные выразительные возможности (не реализуют многие необходимые возможности языков программирования). Но большинство людей просто не представляют себе других вариантов, кроме бесконечного листинга текстового программного кода (в лучшем случае разделенного на модули) или столь же неоглядной блок-схемы.

            Я думаю, что визуальное представление программного кода должно быть блочным - не в смысле блоков блок-схем любого типа, а в смысле структурного программирования. Циклы и ветвления должны отображаться в виде блоков-виджетов в прокручиваемой вкладке или карточке. Последовательно обрабатываемые инструкции должны образовывать вертикальные списки, как строки в программном коде на Python. Вкладки и карточки должны организовываться в базу данных с различными инструментами поиска, а не только с поиском по древовидному списку. Модули должны организовываться в слои и иные группы, соответствующие выбранным архитектурным паттернам.

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

            Система управления версиями должна быть встроенной (Git, прощай!). Должны быть встроенные средства для удаленной работы. Для предотвращения vendor lock-in должны быть открытые стандарты, форматы и протоколы.

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


            1. BugM
              17.06.2025 18:49

              А как эту вашу красоту в виме редактировать? А sedом или простым регэкспом как пройтись?

              Да, это обязательные фичи. Особенно в больших кодовых базах.


              1. SergeyProkhorenko
                17.06.2025 18:49

                В виме - никак. А также в ноутпаде++, блокноте и т.п. древних редакторах. Нужно новое средство разработки, которого еще нет


                1. JBFW
                  17.06.2025 18:49

                  Как раз есть - ЧатЖПТ, например.

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

                  Вот только есть нюанс...


                  1. SergeyProkhorenko
                    17.06.2025 18:49

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


                1. BugM
                  17.06.2025 18:49

                  Классный план. А оно точно прорастет на все те многие тысячи серверов? Там что-то около линукс лайк и бсд операционок. Любых версий и сборок выпущенных за последние 20 лет. Интерфейс - ssh, нет картинка не пролезет.

                  Подозреваю что тем кто железки программирует тоже надо. У них зоопарк еще больше.


                  1. SergeyProkhorenko
                    17.06.2025 18:49

                    Legacy must die. Любая информационная система лет через 10-20 обрушивается под тяжестью накопленных ошибок или новых требований и заменяется новой. Вот для этого и нужно новое средство разработки


                    1. BugM
                      17.06.2025 18:49

                      Sweet summer child


                    1. RulenBagdasis
                      17.06.2025 18:49

                      Кто будет оплачивать этот банкет? (с)

                      Чтобы системы не обрушивались через 10 лет, проектировать их должны не двадцатидвухлетние как-бы синьоры с 3 годами опыта, а настоящие синьоры, лиды и архитекторы с опытом 10+, а лучше 15+ лет, которые видели некоторое дерьмо и понимают, как решения, принимаемые сейчас, аукнутся в будущем.


            1. vadimr
              17.06.2025 18:49

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


  1. Buharin
    17.06.2025 18:49

    На хабре школьники пишут эссе на тему "Кем я хочу стать?" "Как я вижу будущее?"


    1. Bonus2k
      17.06.2025 18:49

      Сейчас бы писать код в AST дереве согласно лучшим практикам SOSAL, а не это всё


      1. CrazyOpossum
        17.06.2025 18:49

        Не хотите поговорить о Боге нашем - LISP'е?


        1. Turbo_Pascal_55
          17.06.2025 18:49

          Ересь.


      1. Moog_Prodigy
        17.06.2025 18:49

        Ага и работать в "ОБОСРАЛСЯ". Но туда попасть сложно.


        1. venanen
          17.06.2025 18:49

          Да, сложно. Алгособесы + надо чтобы парадигма govno от зубов отскакивало...


      1. warkid
        17.06.2025 18:49

        А АСТ дерево представлено в виде XML - и вот его набирать руками!


        1. BugM
          17.06.2025 18:49

          Может стоит пропустить все эти промежуточные шаги и просто писать на Лиспе?


  1. VladimirFarshatov
    17.06.2025 18:49

    Рекомендую ознакомиться с системами Графит-Флокс и Рапира+Школьница. Ещё можно погуглить Р-Технологии Глушкова. Такое ощущение, что Вы изобрели велосипед, но могу и ошибаться. )


    1. fransua Автор
      17.06.2025 18:49

      А с какими аспектами этих систем Вы предлагаете ознакомиться? Краем уха смотрел когда-то давно на дракона, ничего особенного не заметил.


      1. VladimirFarshatov
        17.06.2025 18:49

        Как единое решение по представлению текста кодовой базы, БД хранения как "файловой системы" и формальных описаний входа-выхода, как элемента АСТ дерева. Там ещё, в ДРАКОНе есть версия ИДЕ Тышова (Мурманск), где комментарии к коду "иерархичны": ТЗ, решение, тестировщик, приемка. Несколько типов комментов. В целом ДРАКОН - малая часть Графит-Флокс. Но .. найти его описание не так просто в Сети к сожалению.


        1. fransua Автор
          17.06.2025 18:49

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


          1. VladimirFarshatov
            17.06.2025 18:49

            Прижилось, но не публично. ) Многое из того, что появилось как откровения "на Западе" вышло отсюда, в частности разные UML диаграммы по мере утечки наших спецов "туда".. Глушков и его Р-Технологии это лохматые 60-70е годы вообще-то. )


  1. JohnSmith_007
    17.06.2025 18:49

    А еще заменить клавиатуру голосовым вводом а мышку глазным трекером !


    1. Shura_m
      17.06.2025 18:49

      Устарело.

      Электроды сразу в мозг вживлять.

      И вместо монитора тоже сигнал подавать на зрительную кору мозга.


      1. Tishka17
        17.06.2025 18:49

        Зачем использовать зрение, если мы хотим абстракции программировать. Давайте в лобные доли сразу


        1. andi123
          17.06.2025 18:49

          "Давайте лобные доли сразу отсечем"

          исправил


  1. CloudlyNosound
    17.06.2025 18:49

    Хранить код можно в любом виде. Редактировать будете в текстовом виде, как ни крути.

    В итоге, некоторые "слои абстракции" просто меняются местами. Только, вместо моментального открытия текста, придется ждать, пока по диффам соберётся требуемая версия.


    1. fransua Автор
      17.06.2025 18:49

      Хранить в CVS дельты или снепшоты - это перпендикулярный вопрос, я его не рассматривал.
      Открытие текста в современных IDE не моментальное - он парсится в AST и потом рендерится на экран. Хотя бы для того чтобы раскрасить ключевые слова. Я предлагаю убрать первый шаг.


      1. CloudlyNosound
        17.06.2025 18:49

        В продуманных IDE парсится фоном, а доступ к редактированию получаешь сразу.

        Вам выше правильно написали. Подобные эксперименты уже были.

        Если вас увлекает проект, продолжайте. Потом посмотрите на отклик сообщества.


      1. dv0ich
        17.06.2025 18:49

        А я вот если пишу код не в IDE, а в текстовом редакторе (да, мы существуем!) - как ваш подход может меня осчастливить?


        1. Soika1
          17.06.2025 18:49

          Зачем IDE если есть Emacs?


          1. JBFW
            17.06.2025 18:49

            VIM


  1. Mishootk
    17.06.2025 18:49

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

    Это типа что-то айфона? Вроде бы на устройстве музыки накачано, фильмов, фотографий, но вот просто так скинуть на произвольное соседнее устройство никак. И забрать тоже.


    1. fransua Автор
      17.06.2025 18:49

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


      1. hogstaberg
        17.06.2025 18:49

        Таки в текстовом. Максимум "нетекстовости" - там могут быть compressed diffs в packfile. Но даже это и близко не токены с графами, это просто такой метод эффективно использовать место при хранении нескольких версий одного текстового файлика, имеющих незначительные отличия.


  1. k12th
    17.06.2025 18:49

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



    1. berez
      17.06.2025 18:49

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

      XPM же ж.


      1. mephastopheles
        17.06.2025 18:49

        сто раз ещё напишите, он же не понял с одного


    1. apevzner
      17.06.2025 18:49

      Есть еще Netbpm. Его прям даже не только X11 понимают...

      https://en.wikipedia.org/wiki/Netpbm


    1. ProgerMan
      17.06.2025 18:49

      Аналогично. Если надо написать что-то небольшое, то это летит в Телеграм в сохранённые сообщения. Если надо для чего-то большого, то создаю markdown - и вперёд. Не надо ничего выдумывать, если есть простые варианты. Максимум - потом в fb2 сконвертировать для форматирования.


    1. CuriousJustifier
      17.06.2025 18:49

      Сейчас и музыку можно в текстовом виде писать: https://strudel.cc/workshop/getting-started/


      1. DvoiNic
        17.06.2025 18:49

        почему "сейчас"? во-первых, мы подобие этого еще для Корветов делали. а во-вторых, Csound'у уже под 40 лет..


        1. garwall
          17.06.2025 18:49

          а уж нотной записи..

          (ладно, тут еще вопрос, символьная запись - это текстовая или нет)