Это не риторический вопрос. Я знаю, так исторически сложилось, но... почему мы продолжаем использовать текстовые файлы?
Вы можете сказать, что это очень простое решение: что видишь, то оно и есть. Но мы имеем дело с несколькими слоями абстракции, а все абстракции текут. Это приводит к ошибкам, запутанным диффам и проблемам с производительностью.
Давайте углубимся в искусство хранения кода в виде текстовых файлов.
Текст
Компьютеры оперируют бинарными данными, поэтому для представления текста им приходится использовать кодировки. Существует много вариантов: 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)
kenomimi
17.06.2025 18:49А как его обратно декомипилить из разобранного и обработанного графа? Там же все метаданные убираются... Или я что-то не так понимаю?
fransua Автор
17.06.2025 18:49Сериализовать в текст? Этим постоянно все IDE занимаются, при форматировании кода, парсят в AST и рендерят в текст согласно выбранному code-style.
А какие метаданные, комментарии? Они тоже есть в ASTkamaz1
17.06.2025 18:49А если файл в данный момент синтаксически некорректен, исправлять нет времени, надо сохранить и идти по делам?
Ndochp
17.06.2025 18:49Нужно использовать ИДЕ которая переводит код из одного допустимого состояния в другое.
https://scratch.mit.edu/projects/editor/?tutorial=getStarted
Jijiki
17.06.2025 18:49то что вы предлагаете делает визуалка на фоне(это не точно могу ошибаться), кидает внутрянку кв в таблицы по какой-то логике, но суть не меняется от этого, когда это всё вместе запускается, так кошмар начинается, как проверить и о чем я.
предположим мы на среднем ПК, откроем движок UE в визуалке!, и начнем писать в определенный момент проект самого всего двигла поттянется и начнётся веселье если это не пофиксилитут такая ситуация что эти ситуации надо минимизировать и конкретизировать операции прогонок(тоесть не чтоб оркестр запускался и на сессии ввода всё запускалось и считалось а как-то более тонко и продуманно)
мы пришли к проблеме которая не трвиальная даже на сегодняшний день, у этой проблемы 2 ситуации, цена за удобство в рантайме за оркестр, и цена за конкретную операцию и её ожидание, как найти баланс не знаю
вот на последнем абзаце и стоит проблема того как это достигается, гдето можно всё отключить, но реализация текстового редактора может не позволить всё отключить, хотя нам надо рисовать текст только по факту получается, и если углубляться в нюансы реализации текста она тоже нагрузная, поэтому всё это имеет цену в редакторах это в среднем так не везде, например какой-то блокнот может быть эффективнее визуалки, за счет того что просто рисует текст
тоесть это получается целый комплекс интерфейсов должен быть, чтобы можно было настраивать +-
SergeyProkhorenko
17.06.2025 18:49Было бы ошибкой сериализовать в текст! Если уж Вы решились порвать с текстом, то нужно это делать не только в способе хранения программного кода, но и в способе отображения программного кода человеку. Никому на самом деле не нужен единый текст программы (листинг), если логически он состоит из проектов, слоев, модулей, функций, циклов и т.п. Способ отображения программного кода должен повторять его логическую структуру. Для этого есть самые разнообразные элементы интерфейса: вкладки, карточки, блоки, древовидные списки и т.д.
То, за что Вы взялись, совершенно правильно. Но это не что-то совершенно новое. Советую изучить имеющийся опыт в этой области:fransua Автор
17.06.2025 18:49Спасибо!
Да, я согласен, думал и про отображение в виде блоков.
Честно говоря, судя по реакции здесь, даже хранение не в текстовом виде - все еще революционная идея, хотя и не новая.tenzink
17.06.2025 18:49Идея хранить в не текстовом виде не новая, не революционная и себя не оправдавшая. Было уже не раз, и либо благополучно скончалось, либо осело в нишевых решениях. R.I.P.
tbl
17.06.2025 18:49среди продуктов ibm visualage была ide для java, проекты хранила в виде бинарных файлов (проект по сути был базой данных для хранения кода), код при работе парсился и хранился в бинарном виде, готовом для запуска на их виртуальной машине, написанной на smalltalk, потом лавку прикрыли, какие-то наработки передали в eclipse foundation, бинарное хранение выпилили к херам, как и эту странную виртуальную машину
Kano
17.06.2025 18:49Вы предлагаете навернуть ещё один слой над уже имеющимся, т.е. добавить ещё одну точку отказа. Именно это мне больше всего не нравится в вашем предложении.
SergeyProkhorenko
17.06.2025 18:49Реакция здесь очень разная. Например, сейчас у Вашей статьи уже 30 плюсов, значит, есть много сторонников. Люди зачастую на любые новшества реагируют негативно (см. синдром утенка), но это не означает что они правы. Прав тот, кто окажется прав в конечном счете, а игра еще только начата.
Есть еще один важный момент: графическое программирование на основе всякого рода блок-схем (программирование роботов, Дракон, Camunda, Anchor Modeler, ETL) дискредитировало идею отказа от текстового представления программного кода. Блок-схемы имеют очень ограниченный успех в узких нишах, потому что блок-схемы неудобны для больших проектов (не умещаются в поле зрения, требуют усилий по поиску блоков и изменению расположения блоков), порождают плохой программный код и имеют ограниченные выразительные возможности (не реализуют многие необходимые возможности языков программирования). Но большинство людей просто не представляют себе других вариантов, кроме бесконечного листинга текстового программного кода (в лучшем случае разделенного на модули) или столь же неоглядной блок-схемы.
Я думаю, что визуальное представление программного кода должно быть блочным - не в смысле блоков блок-схем любого типа, а в смысле структурного программирования. Циклы и ветвления должны отображаться в виде блоков-виджетов в прокручиваемой вкладке или карточке. Последовательно обрабатываемые инструкции должны образовывать вертикальные списки, как строки в программном коде на Python. Вкладки и карточки должны организовываться в базу данных с различными инструментами поиска, а не только с поиском по древовидному списку. Модули должны организовываться в слои и иные группы, соответствующие выбранным архитектурным паттернам.
Вместо клавиатурного ввода должны в основном использоваться разнообразные средства интерфейса, в том числе с использованием автодополнения кода и ИИ. Потребуется внести изменения и в синтаксис языка. Например, точки с запятой для разделения операторов и фигурные скобки для тела функции уже не будут нужны - их заменят виджеты.
Система управления версиями должна быть встроенной (Git, прощай!). Должны быть встроенные средства для удаленной работы. Для предотвращения vendor lock-in должны быть открытые стандарты, форматы и протоколы.
А вообще многие комментарии к этой статье, направленные против отказа от текста, на самом деле полезны для отказа от текста, так как эти комментарии раскрывают реальные проблемы, для которых нужно просто найти решение.BugM
17.06.2025 18:49А как эту вашу красоту в виме редактировать? А sedом или простым регэкспом как пройтись?
Да, это обязательные фичи. Особенно в больших кодовых базах.
SergeyProkhorenko
17.06.2025 18:49В виме - никак. А также в ноутпаде++, блокноте и т.п. древних редакторах. Нужно новое средство разработки, которого еще нет
JBFW
17.06.2025 18:49Как раз есть - ЧатЖПТ, например.
В нем всё внутри хранится, и можно из него что-то извлекать в том числе в виде текста, экспортировать.
Вот только есть нюанс...
SergeyProkhorenko
17.06.2025 18:49Ну что ж, давайте попросим сообщество провести эксперимент - отредактировать AST с помощью LLM и посмотреть, что из этого получится. Мне кажется, что ничего хорошего, так как LLM часто теряет контекст, галлюцинирует, забывает, своевольничает и т.п.
BugM
17.06.2025 18:49Классный план. А оно точно прорастет на все те многие тысячи серверов? Там что-то около линукс лайк и бсд операционок. Любых версий и сборок выпущенных за последние 20 лет. Интерфейс - ssh, нет картинка не пролезет.
Подозреваю что тем кто железки программирует тоже надо. У них зоопарк еще больше.
SergeyProkhorenko
17.06.2025 18:49Legacy must die. Любая информационная система лет через 10-20 обрушивается под тяжестью накопленных ошибок или новых требований и заменяется новой. Вот для этого и нужно новое средство разработки
RulenBagdasis
17.06.2025 18:49Кто будет оплачивать этот банкет? (с)
Чтобы системы не обрушивались через 10 лет, проектировать их должны не двадцатидвухлетние как-бы синьоры с 3 годами опыта, а настоящие синьоры, лиды и архитекторы с опытом 10+, а лучше 15+ лет, которые видели некоторое дерьмо и понимают, как решения, принимаемые сейчас, аукнутся в будущем.
vadimr
17.06.2025 18:49Если, например, я ставлю плюс статье, это не значит, что я согласен с её тезисами. Может быть просто интересная полемика.
Buharin
17.06.2025 18:49На хабре школьники пишут эссе на тему
"Кем я хочу стать?""Как я вижу будущее?"Bonus2k
17.06.2025 18:49Сейчас бы писать код в AST дереве согласно лучшим практикам SOSAL, а не это всё
VladimirFarshatov
17.06.2025 18:49Рекомендую ознакомиться с системами Графит-Флокс и Рапира+Школьница. Ещё можно погуглить Р-Технологии Глушкова. Такое ощущение, что Вы изобрели велосипед, но могу и ошибаться. )
fransua Автор
17.06.2025 18:49А с какими аспектами этих систем Вы предлагаете ознакомиться? Краем уха смотрел когда-то давно на дракона, ничего особенного не заметил.
VladimirFarshatov
17.06.2025 18:49Как единое решение по представлению текста кодовой базы, БД хранения как "файловой системы" и формальных описаний входа-выхода, как элемента АСТ дерева. Там ещё, в ДРАКОНе есть версия ИДЕ Тышова (Мурманск), где комментарии к коду "иерархичны": ТЗ, решение, тестировщик, приемка. Несколько типов комментов. В целом ДРАКОН - малая часть Графит-Флокс. Но .. найти его описание не так просто в Сети к сожалению.
fransua Автор
17.06.2025 18:49Да, звучит похоже, надо копать что там напридумали.
Причины по которым это не прижилась тогда могут сейчас не работать. Может быть даже есть смысл воплотить те идеи сейчас и оно заведётся, а может стоит адаптировать и улучшитьVladimirFarshatov
17.06.2025 18:49Прижилось, но не публично. ) Многое из того, что появилось как откровения "на Западе" вышло отсюда, в частности разные UML диаграммы по мере утечки наших спецов "туда".. Глушков и его Р-Технологии это лохматые 60-70е годы вообще-то. )
JohnSmith_007
17.06.2025 18:49А еще заменить клавиатуру голосовым вводом а мышку глазным трекером !
Shura_m
17.06.2025 18:49Устарело.
Электроды сразу в мозг вживлять.
И вместо монитора тоже сигнал подавать на зрительную кору мозга.
CloudlyNosound
17.06.2025 18:49Хранить код можно в любом виде. Редактировать будете в текстовом виде, как ни крути.
В итоге, некоторые "слои абстракции" просто меняются местами. Только, вместо моментального открытия текста, придется ждать, пока по диффам соберётся требуемая версия.
fransua Автор
17.06.2025 18:49Хранить в CVS дельты или снепшоты - это перпендикулярный вопрос, я его не рассматривал.
Открытие текста в современных IDE не моментальное - он парсится в AST и потом рендерится на экран. Хотя бы для того чтобы раскрасить ключевые слова. Я предлагаю убрать первый шаг.CloudlyNosound
17.06.2025 18:49В продуманных IDE парсится фоном, а доступ к редактированию получаешь сразу.
Вам выше правильно написали. Подобные эксперименты уже были.
Если вас увлекает проект, продолжайте. Потом посмотрите на отклик сообщества.
Mishootk
17.06.2025 18:49То есть по сути разработчик вообще не заметит разницы, кроме случая, когда ему придется заглянуть в исходники не имея под рукой IDE? А не имея под рукой IDE как бы все.
Это типа что-то айфона? Вроде бы на устройстве музыки накачано, фильмов, фотографий, но вот просто так скинуть на произвольное соседнее устройство никак. И забрать тоже.
fransua Автор
17.06.2025 18:49Git тоже хранит код не в текстовом виде, если я не ошибаюсь. Но при checkout сериализует все в текст. При желании и тут можно так же. Но при редактирование текстового файла будут такие же плохие диффы, как и сейчас.
hogstaberg
17.06.2025 18:49Таки в текстовом. Максимум "нетекстовости" - там могут быть compressed diffs в packfile. Но даже это и близко не токены с графами, это просто такой метод эффективно использовать место при хранении нескольких версий одного текстового файлика, имеющих незначительные отличия.
k12th
17.06.2025 18:49Я обожаю текстовые файлы. Если есть выбор, я и худлит пишу в маркдауне. SVG я делаю в текстовом редакторе. Если бы я знал плейнтекстовый формат для растровых изображений, я бы его использовал.
ProgerMan
17.06.2025 18:49Аналогично. Если надо написать что-то небольшое, то это летит в Телеграм в сохранённые сообщения. Если надо для чего-то большого, то создаю markdown - и вперёд. Не надо ничего выдумывать, если есть простые варианты. Максимум - потом в fb2 сконвертировать для форматирования.
CuriousJustifier
17.06.2025 18:49Сейчас и музыку можно в текстовом виде писать: https://strudel.cc/workshop/getting-started/
PerroSalchicha
Но... почему?
Почему именно текстовый файл, я легко отвечу: это естественный для меня формат, он хранит код именно так, как я его буду читать. И я его могу прочитать абсолютно любым инструментом, который у меня есть под рукой, вплоть до голой ОС.
В то же время преимущества каких-то других форматов для меня не очевидны. Удобство? Нет ничего удобнее нативного для меня формата. Надёжность? Текстовый файл надёжен настолько, насколько надёжен носитель, на котором он записан. Лучше этого и не придумаешь. Размер хранилища? Да, в этом плане текстовый файл ни разу не оптимален, но... на моём компьютере весь текстовый контент едва ли займёт несколько процентов от самого маленького накопителя на 256Гб. А остальное занимает отнюдь не код, а всякого рода бинарники и медиаконтент.
BobovorTheCommentBeast
Тут наоборот материшься на какого нибудь вендора IDE или тулзов, который хранит файлы не в текстовом формате (или в файлах, которые еще хранят кучу локальной\временной информации).
pnmv
мне, почему-то, вспомнились какие-то лекции, по программированию, кажется, на perl: весьма юный лектор показывает пример какого-то кода, весьма компактный, внятный и читаемый, а потом, такой - "ну, это муторошно!", после чего выдает такую простыню, которую прочтешь то не с первого раза.
blind_oracle
Perl он, как и его регулярки, часто нечитаем) Write Once, Read Never
pnmv
Язык, как язык...
Если не придерживаться, при разработке, php5-style, всё как-то не так грустно, пока слишком творческие личности не вмешиваются. Да и вообще, perlcritic никто не отменял.
Регулярные выражения, при правильном приготовлении, замечательная вещь. И общие рекомендации, кстати, такие же, как везде - не городить длинных простыней, разбивая на кусочки.
vdudouyt
Из нечитаемого там только тот самый запускающий rm -rf однострочник, некогда настолько травмировавший неокрепшую психику джунов-миллениалов, что теперь утверждения о якобы write only природе Perl можно встретить буквально при каждом его упоминании (причем в основном от индивидуумов, более нигде с ним не сталкивавшихся).
Реальный write only из того, что я видел это C++-поделки отдельных template only-мастеров. Но, конечно, меметичность совсем не та.
blind_oracle
Я писал на перле последний раз лет 15 назад всякое достаточно активно по работе, и если там налягать на контекстные переменные и всё такое - становится читать потом свой же код даже сильно сложно.
Так что это чисто моё впечатление.
Шаблоны в плюсах это страшно тоже, да.
В Расте дженерики аналогично регулярно приводят к типам, которые мне в экран не влазят.
JBFW
Так может быть писать надо было как-то попроще?
Вообще, хорошее правило: если твой собственный текст без комментариев через месяц становится непонятен - значит, надо что-то думать над своим стилем написания программы
blind_oracle
Может быть. Но я писал на десятке разных языков наверное, и такая проблема была только с Перлом :)
vdudouyt
Ну не знаю, как по мне так примерно на уровне остальных ЯП с динамической типизацией )
Кстати, чтобы избежать проблем со скоупингом переменных многие крупные кодовые базы на Perl написаны на его strict-подмножестве (use strict). Хотя, вон, в тех же PHP, Lua и до недавнего времени и Python как-то не особо парятся по этому поводу, и ничего.
JBFW
Люди с опытом начинают писать лучше...
Хотя до сих пор использую некоторые свои блоки многолетней давности - нет никаких проблем с пониманием чего они там делают, все же написано в коде...
JBFW
Вы его видели? )
Похоже, представление о коде на Perl складывается из творений какеров, которые умеют вместо
print "hello world\n";
написать что-то типа
$<->^$2>>^&3@\#
и потом радуются как круто и непонятно получилось
blind_oracle
Я на нём (ну, на
mod_perl
) писал всякие веб-бекенды несколько лет (давно уже правда). Так что да, видел.JBFW
Стиль вероятно.
Можно написать как-то так:
А можно написать
Чуть больше букв, зато для понимания смысла даже незачем знать Perl, всё и так понятно.
UplandDivan
Perl нечитаем? Это вы еще C++ >= 11 не видели )))
UFO_01
Сейчас пойдёт потеха. Имхо, у раста синтаксис куда более нечитаемый.
UserSergeyB
Потому что вы так привыкли.
На носителе не записан текст. Там двоичные данные, удобные ровно до тех пор, пока есть текстовый редактор.
И если для кода когда-то найдется формат по-лучше, чем обычный текст, то он может когда-то стать нативным. Напишут для всех осей нативный инструмент, которым вы его сможете открывать и читать так, как вы его написали.
omaxx
Так это и про книги можно так сказать, что там не текст, а это всего лишь испачканные типографской краской стопки бумаги
UserSergeyB
Верно. Если вы язык, на котором она написана, не знаете, для вас это просто краска на бумаге.
omaxx
нет... для меня это все так же текст, но только на незнакомом мне языке
UserSergeyB
Почему вы решили, что там текст? Возможно на другом языке эта краска на бумаге образует картинку.
omaxx
вы сейчас имеете ввиду какой-то определенный язык или просто фантазируете?
UserSergeyB
Я про краску на бумаге. Вы сами привели такое сравнение.
Вот например, если в книге на всю страницу напечатать огромный QR-код. Вы тоже подумаете, что это текст?
omaxx
Ну насколько я знаю, на свете нет людей, которые свободно читают в куар-кодах....
Речь идет о том, что люди пишут тексты буквами уже тысячи лет, а как они записаны, краской на папирусе, на бумаге, в виде ascii или в виде юникода, это не принципиально.... текст в книге и текст на экране монитора выглядят примерно одинаково... ну найдется другой формат, ну и черт с ним, главное, чтобы текст оставался текстом
UserSergeyB
Я об этом и писал, что мы привыкли выражать свои мысли текстом.
Хотя иногда удобнее для представления алгоритмов рисовать блок-схемы.
Связка:
двоичный формат хранения блок-схем;
нативный редактор блок-схем;
компилятор из блок-схем в машинный код;
позволяет программировать вообще без текста.
Просто исторически мы привязались к тексту. Но это не данность, и повод не искать что-то другое.
omaxx
тем не менее мы вот сейчас с вами общаемся именно текстом, а не смайликами, не стикерами, и не картинками...
UserSergeyB
Так надо было сказать, я бы прислал стикер :)
omaxx
а вы уверены, что он отобразится в моем браузере?
UserSergeyB
В крайнем случае посмотрите как на пятнышки на мониторе на неизвестном языке.
Orisava
Вы имеете отношение к 1С?
UserSergeyB
Нет.
DvoiNic
Вы описали пресловутый Д
уракон (его инкарнацию от Тышова). Попробуйте на нем что-нибудь более-менее серьезное "напрограммировать", удачи вамUserSergeyB
Я описал любой процесс программирования. Есть исходник, редактор и компилятор.
И если вы думаете, что графы (те же блок-схемы) хуже текста, то я вас расстрою.
А программировать что-то серьезное можно на любом полном по Тьюрингу языке. И всё равно как он выглядит. Хоть буковки, хоть стрелочки, хоть картинки.
DvoiNic
В далеком 1993 в Москве была одна из первых в пост-СССР "компьютерных выставок". Там была куча стендов модного тренда - визуального программирования. Обещали, что через пару лет не будет никаких "текстов" - все будет в графах/блок-схемах. Так вот, пришла моя очередь расстроить вас...
Да и плац можно подметать ломиком. Но если хотим, чтоб было быстро и чисто - берем метлу. а ломик применяется не чтоб было быстро и чисто, а чтоб "задолбать".
UserSergeyB
Вы упёрлись в то, что обычный текст это максимум, чтобы делать быстро. И не можете (или просто не хотите) поверить, что бывает что-то ещё.
Как в далеком прошлом, нужен человек, который придумает калькулятор, в то время, когда все пользуются счетами и говорят, что это удобно.
DvoiNic
пока текст - самое удобное. Емкое. И общепонятное.
А визуальщина - не взлетела.
UserSergeyB
Пока ещё не дожили. И компьютеров когда-то не было.
vadimr
Графы безусловно хуже текста, потому что их выразительные средства более ограничены (хотя в смысле Тьюринга они могут быть эквивалентны). Представьте хотя бы простую рекурсию блок-схемой. Или макрос. Не говорю про самомодифицирующийся код.
(У меня ожидается публикация статьи примерно на эту тему в журнале "Информационно-измерительные и управляющие системы", после её выхода я, наверное, напишу и на хабре).
Кроме того, многие люди вообще в силу индивидуальных особенностей очень плохо воспринимают схемы. Хотя другие люди их любят.
DvoiNic
Ну, каждому инструменту своё место. "Схему электрическую принципиальную" можно выразить и в виде netlist'а (т.е. текстом), но в привычном виде с УГО она человеку понятнее. С визуальным программированием - наоборот.
vadimr
Если речь идёт про какой-нибудь усилитель, то да, но согласитесь, что микропроцессор понятнее на верилоге, чем в виде принципиальной схемы.
Есть подозрение, что просто никто не поставил перед собой и не решил задачу текстового представления аналоговых схем, понятного человеку.
DvoiNic
микророцессор - абсолютно согласен. а вот "схема, в которой используется микропроцессор" (ну или любая другая безпроцессорная цифрятина - может быть понятнее в виде схемы). Аналог - там схема привычнее, но опять же, симуляторы хранят ее в некоем структурированном тексте.
В школьные времена (примерно 1980-й) с приятелем схемами по телефону обменивались (если болел кто-то из нас, например). Словами описывали. (т.е. записать на бумагу - и было бы "текстовое представление"). Но это так себе занятие. Примерно как "программировать блок-схемами".
Serge78rus
Да есть уже достаточно давно такие языки, например GRAPH из среды SIMATIC STEP-7 для программирования PLC, приходилось писать на нем и я Вам скажу - это просто сущий ад. Основная, но далеко не единственная проблема - это очень низкая плотность информации на экране. Чтобы обозреть хоть сколь-нибудь сложную логическую конструкцию приходится постоянно крутить масштабирование, поскольку или ничего не лезет в экран и не видно логику, или шрифт становится мелким до полной нечитаемости. Хотя на простейших примерах все выглядит очень удобно, но это удобство исчезает напрочь когда начинаешь писать реальный достаточно сложный алгоритм управления.
После этого тот же C с его if и else, пусть даже "многоэтажными", кажется верхом совершенства. И даже всеми проклятый goto уже не выглядит таким уж извращением.
PerroSalchicha
Т.е. удобные вообще всегда, когда у вас есть компьютер или что-то близкое к нему.
Т.е. вообще никогда. О чём же я и пишу :)
UserSergeyB
Т.е. по вашему кроме текстового формата ничего не придумали. Картинки тоже как текст просматриваете?
Редактируйте машинный код. Он надёжнее. От кодировки текста не зависит :)
JBFW
машинный код зависит от процессора, как минимум.
Вы этого не знали?
UserSergeyB
Решили проверить мои знания :)
У текста побольше зависимостей, поверьте.
JBFW
Например?
PerroSalchicha
Сэр, моя нейронка зависла, пытаясь уловить какую-то логическую связь вашего ответа с моим постом. Она хоть была?
Да оно и в текстовых файлах не особо зависит, по крайней мере, если вы не 1Сник
UserSergeyB
Тогда всё ясно. Успехов.
PerroSalchicha
Вы так написали, как будто бы у вас есть основания считать, что я неправ, а вы типа что-то знаете :)