Comments 336
Очевидно, нет. Это неудобно, ненадежно и может привести к несогласованности.
Но... почему?
Почему именно текстовый файл, я легко отвечу: это естественный для меня формат, он хранит код именно так, как я его буду читать. И я его могу прочитать абсолютно любым инструментом, который у меня есть под рукой, вплоть до голой ОС.
В то же время преимущества каких-то других форматов для меня не очевидны. Удобство? Нет ничего удобнее нативного для меня формата. Надёжность? Текстовый файл надёжен настолько, насколько надёжен носитель, на котором он записан. Лучше этого и не придумаешь. Размер хранилища? Да, в этом плане текстовый файл ни разу не оптимален, но... на моём компьютере весь текстовый контент едва ли займёт несколько процентов от самого маленького накопителя на 256Гб. А остальное занимает отнюдь не код, а всякого рода бинарники и медиаконтент.
Тут наоборот материшься на какого нибудь вендора IDE или тулзов, который хранит файлы не в текстовом формате (или в файлах, которые еще хранят кучу локальной\временной информации).
мне, почему-то, вспомнились какие-то лекции, по программированию, кажется, на perl: весьма юный лектор показывает пример какого-то кода, весьма компактный, внятный и читаемый, а потом, такой - "ну, это муторошно!", после чего выдает такую простыню, которую прочтешь то не с первого раза.
Perl он, как и его регулярки, часто нечитаем) Write Once, Read Never
Язык, как язык...
Если не придерживаться, при разработке, php5-style, всё как-то не так грустно, пока слишком творческие личности не вмешиваются. Да и вообще, perlcritic никто не отменял.
Регулярные выражения, при правильном приготовлении, замечательная вещь. И общие рекомендации, кстати, такие же, как везде - не городить длинных простыней, разбивая на кусочки.
Из нечитаемого там только тот самый запускающий rm -rf однострочник, некогда настолько травмировавший неокрепшую психику джунов-миллениалов, что теперь утверждения о якобы write only природе Perl можно встретить буквально при каждом его упоминании (причем в основном от индивидуумов, более нигде с ним не сталкивавшихся).
Реальный write only из того, что я видел это C++-поделки отдельных template only-мастеров. Но, конечно, меметичность совсем не та.
Я писал на перле последний раз лет 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>>>>>>>>>>
Так может быть писать надо было как-то попроще?
Вообще, хорошее правило: если твой собственный текст без комментариев через месяц становится непонятен - значит, надо что-то думать над своим стилем написания программы
Может быть. Но я писал на десятке разных языков наверное, и такая проблема была только с Перлом :)
Ну не знаю, как по мне так примерно на уровне остальных ЯП с динамической типизацией )
Кстати, чтобы избежать проблем со скоупингом переменных многие крупные кодовые базы на Perl написаны на его strict-подмножестве (use strict). Хотя, вон, в тех же PHP, Lua и до недавнего времени и Python как-то не особо парятся по этому поводу, и ничего.
Люди с опытом начинают писать лучше...
Хотя до сих пор использую некоторые свои блоки многолетней давности - нет никаких проблем с пониманием чего они там делают, все же написано в коде...
Вы его видели? )
Похоже, представление о коде на Perl складывается из творений какеров, которые умеют вместо
print "hello world\n";
написать что-то типа
$<->^$2>>^&3@\#
и потом радуются как круто и непонятно получилось
Я на нём (ну, на mod_perl) писал всякие веб-бекенды несколько лет (давно уже правда). Так что да, видел.
Стиль вероятно.
Можно написать как-то так:
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, всё и так понятно.
Perl нечитаем? Это вы еще C++ >= 11 не видели )))
Потому что вы так привыкли.
На носителе не записан текст. Там двоичные данные, удобные ровно до тех пор, пока есть текстовый редактор.
И если для кода когда-то найдется формат по-лучше, чем обычный текст, то он может когда-то стать нативным. Напишут для всех осей нативный инструмент, которым вы его сможете открывать и читать так, как вы его написали.
Так это и про книги можно так сказать, что там не текст, а это всего лишь испачканные типографской краской стопки бумаги
Верно. Если вы язык, на котором она написана, не знаете, для вас это просто краска на бумаге.
нет... для меня это все так же текст, но только на незнакомом мне языке
Почему вы решили, что там текст? Возможно на другом языке эта краска на бумаге образует картинку.
вы сейчас имеете ввиду какой-то определенный язык или просто фантазируете?
Я про краску на бумаге. Вы сами привели такое сравнение.
Вот например, если в книге на всю страницу напечатать огромный QR-код. Вы тоже подумаете, что это текст?
Ну насколько я знаю, на свете нет людей, которые свободно читают в куар-кодах....
Речь идет о том, что люди пишут тексты буквами уже тысячи лет, а как они записаны, краской на папирусе, на бумаге, в виде ascii или в виде юникода, это не принципиально.... текст в книге и текст на экране монитора выглядят примерно одинаково... ну найдется другой формат, ну и черт с ним, главное, чтобы текст оставался текстом
Я об этом и писал, что мы привыкли выражать свои мысли текстом.
Хотя иногда удобнее для представления алгоритмов рисовать блок-схемы.
Связка:
двоичный формат хранения блок-схем;
нативный редактор блок-схем;
компилятор из блок-схем в машинный код;
позволяет программировать вообще без текста.
Просто исторически мы привязались к тексту. Но это не данность, и повод не искать что-то другое.
тем не менее мы вот сейчас с вами общаемся именно текстом, а не смайликами, не стикерами, и не картинками...
Связка:
двоичный формат хранения блок-схем;
нативный редактор блок-схем;
компилятор из блок-схем в машинный код;
позволяет программировать вообще без текста.
Вы описали пресловутый Дуракон (его инкарнацию от Тышова). Попробуйте на нем что-нибудь более-менее серьезное "напрограммировать", удачи вам
Я описал любой процесс программирования. Есть исходник, редактор и компилятор.
И если вы думаете, что графы (те же блок-схемы) хуже текста, то я вас расстрою.
А программировать что-то серьезное можно на любом полном по Тьюрингу языке. И всё равно как он выглядит. Хоть буковки, хоть стрелочки, хоть картинки.
В далеком 1993 в Москве была одна из первых в пост-СССР "компьютерных выставок". Там была куча стендов модного тренда - визуального программирования. Обещали, что через пару лет не будет никаких "текстов" - все будет в графах/блок-схемах. Так вот, пришла моя очередь расстроить вас...
программировать что-то серьезное можно на любом полном по Тьюрингу языке. И всё равно как он выглядит. Хоть буковки, хоть стрелочки, хоть картинки.
Да и плац можно подметать ломиком. Но если хотим, чтоб было быстро и чисто - берем метлу. а ломик применяется не чтоб было быстро и чисто, а чтоб "задолбать".
Но если хотим, чтоб было быстро и чисто
Вы упёрлись в то, что обычный текст это максимум, чтобы делать быстро. И не можете (или просто не хотите) поверить, что бывает что-то ещё.
Как в далеком прошлом, нужен человек, который придумает калькулятор, в то время, когда все пользуются счетами и говорят, что это удобно.
Графы безусловно хуже текста, потому что их выразительные средства более ограничены (хотя в смысле Тьюринга они могут быть эквивалентны). Представьте хотя бы простую рекурсию блок-схемой. Или макрос. Не говорю про самомодифицирующийся код.
(У меня ожидается публикация статьи примерно на эту тему в журнале "Информационно-измерительные и управляющие системы", после её выхода я, наверное, напишу и на хабре).
Кроме того, многие люди вообще в силу индивидуальных особенностей очень плохо воспринимают схемы. Хотя другие люди их любят.
Кроме того, многие люди вообще в силу индивидуальных особенностей очень плохо воспринимают схемы. Хотя другие люди их любят.
Ну, каждому инструменту своё место. "Схему электрическую принципиальную" можно выразить и в виде netlist'а (т.е. текстом), но в привычном виде с УГО она человеку понятнее. С визуальным программированием - наоборот.
Если речь идёт про какой-нибудь усилитель, то да, но согласитесь, что микропроцессор понятнее на верилоге, чем в виде принципиальной схемы.
Есть подозрение, что просто никто не поставил перед собой и не решил задачу текстового представления аналоговых схем, понятного человеку.
согласитесь, что микропроцессор понятнее на верилоге
микророцессор - абсолютно согласен. а вот "схема, в которой используется микропроцессор" (ну или любая другая безпроцессорная цифрятина - может быть понятнее в виде схемы). Аналог - там схема привычнее, но опять же, симуляторы хранят ее в некоем структурированном тексте.
Есть подозрение, что просто никто не поставил перед собой и не решил задачу текстового представления аналоговых схем, понятного человеку.
В школьные времена (примерно 1980-й) с приятелем схемами по телефону обменивались (если болел кто-то из нас, например). Словами описывали. (т.е. записать на бумагу - и было бы "текстовое представление"). Но это так себе занятие. Примерно как "программировать блок-схемами".
Да есть уже достаточно давно такие языки, например GRAPH из среды SIMATIC STEP-7 для программирования PLC, приходилось писать на нем и я Вам скажу - это просто сущий ад. Основная, но далеко не единственная проблема - это очень низкая плотность информации на экране. Чтобы обозреть хоть сколь-нибудь сложную логическую конструкцию приходится постоянно крутить масштабирование, поскольку или ничего не лезет в экран и не видно логику, или шрифт становится мелким до полной нечитаемости. Хотя на простейших примерах все выглядит очень удобно, но это удобство исчезает напрочь когда начинаешь писать реальный достаточно сложный алгоритм управления.
После этого тот же C с его if и else, пусть даже "многоэтажными", кажется верхом совершенства. И даже всеми проклятый goto уже не выглядит таким уж извращением.
Ну насколько я знаю, на свете нет людей, которые свободно читают в куар-кодах
У вас что, вахтёры в 2020-м не считывали куар-код невооружённым взглядом?
Там двоичные данные, удобные ровно до тех пор, пока есть текстовый редактор.
Т.е. удобные вообще всегда, когда у вас есть компьютер или что-то близкое к нему.
И если для кода когда-то найдется формат по-лучше, чем обычный текст, то он может когда-то стать нативным. Напишут для всех осей нативный инструмент, которым вы его сможете открывать и читать так, как вы его написали .
Т.е. вообще никогда. О чём же я и пишу :)
Т.е. вообще никогда. О чём же я и пишу :)
Т.е. по вашему кроме текстового формата ничего не придумали. Картинки тоже как текст просматриваете?
Редактируйте машинный код. Он надёжнее. От кодировки текста не зависит :)
машинный код зависит от процессора, как минимум.
Вы этого не знали?
Т.е. по вашему кроме текстового формата ничего не придумали
Сэр, моя нейронка зависла, пытаясь уловить какую-то логическую связь вашего ответа с моим постом. Она хоть была?
От кодировки текста не зависит
Да оно и в текстовых файлах не особо зависит, по крайней мере, если вы не 1Сник
А как его обратно декомипилить из разобранного и обработанного графа? Там же все метаданные убираются... Или я что-то не так понимаю?
Сериализовать в текст? Этим постоянно все IDE занимаются, при форматировании кода, парсят в AST и рендерят в текст согласно выбранному code-style.
А какие метаданные, комментарии? Они тоже есть в AST
А если файл в данный момент синтаксически некорректен, исправлять нет времени, надо сохранить и идти по делам?
Пишите всегда только корректные файлы, чтобы с первого раза работало. Тогда и на тестах можно сэкономить
Нужно использовать ИДЕ которая переводит код из одного допустимого состояния в другое.
https://scratch.mit.edu/projects/editor/?tutorial=getStarted
Всегда можно параллельно хранить и текстовый формат для такого случая, остальные плюсы это не умаляет.
то что вы предлагаете делает визуалка на фоне(это не точно могу ошибаться), кидает внутрянку кв в таблицы по какой-то логике, но суть не меняется от этого, когда это всё вместе запускается, так кошмар начинается, как проверить и о чем я.
предположим мы на среднем ПК, откроем движок UE в визуалке!, и начнем писать в определенный момент проект самого всего двигла поттянется и начнётся веселье если это не пофиксили
тут такая ситуация что эти ситуации надо минимизировать и конкретизировать операции прогонок(тоесть не чтоб оркестр запускался и на сессии ввода всё запускалось и считалось а как-то более тонко и продуманно)
мы пришли к проблеме которая не трвиальная даже на сегодняшний день, у этой проблемы 2 ситуации, цена за удобство в рантайме за оркестр, и цена за конкретную операцию и её ожидание, как найти баланс не знаю
вот на последнем абзаце и стоит проблема того как это достигается, гдето можно всё отключить, но реализация текстового редактора может не позволить всё отключить, хотя нам надо рисовать текст только по факту получается, и если углубляться в нюансы реализации текста она тоже нагрузная, поэтому всё это имеет цену в редакторах это в среднем так не везде, например какой-то блокнот может быть эффективнее визуалки, за счет того что просто рисует текст
тоесть это получается целый комплекс интерфейсов должен быть, чтобы можно было настраивать +-
Было бы ошибкой сериализовать в текст! Если уж Вы решились порвать с текстом, то нужно это делать не только в способе хранения программного кода, но и в способе отображения программного кода человеку. Никому на самом деле не нужен единый текст программы (листинг), если логически он состоит из проектов, слоев, модулей, функций, циклов и т.п. Способ отображения программного кода должен повторять его логическую структуру. Для этого есть самые разнообразные элементы интерфейса: вкладки, карточки, блоки, древовидные списки и т.д.
То, за что Вы взялись, совершенно правильно. Но это не что-то совершенно новое. Советую изучить имеющийся опыт в этой области:
Спасибо!
Да, я согласен, думал и про отображение в виде блоков.
Честно говоря, судя по реакции здесь, даже хранение не в текстовом виде - все еще революционная идея, хотя и не новая.
Идея хранить в не текстовом виде не новая, не революционная и себя не оправдавшая. Было уже не раз, и либо благополучно скончалось, либо осело в нишевых решениях. R.I.P.
среди продуктов ibm visualage была ide для java, проекты хранила в виде бинарных файлов (проект по сути был базой данных для хранения кода), код при работе парсился и хранился в бинарном виде, готовом для запуска на их виртуальной машине, написанной на smalltalk, потом лавку прикрыли, какие-то наработки передали в eclipse foundation, бинарное хранение выпилили к хренам, как и эту странную виртуальную машину
Вы предлагаете навернуть ещё один слой над уже имеющимся, т.е. добавить ещё одну точку отказа. Именно это мне больше всего не нравится в вашем предложении.
Реакция здесь очень разная. Например, сейчас у Вашей статьи уже 30 плюсов, значит, есть много сторонников. Люди зачастую на любые новшества реагируют негативно (см. синдром утенка), но это не означает что они правы. Прав тот, кто окажется прав в конечном счете, а игра еще только начата.
Есть еще один важный момент: графическое программирование на основе всякого рода блок-схем (программирование роботов, Дракон, Camunda, Anchor Modeler, ETL) дискредитировало идею отказа от текстового представления программного кода. Блок-схемы имеют очень ограниченный успех в узких нишах, потому что блок-схемы неудобны для больших проектов (не умещаются в поле зрения, требуют усилий по поиску блоков и изменению расположения блоков), порождают плохой программный код и имеют ограниченные выразительные возможности (не реализуют многие необходимые возможности языков программирования). Но большинство людей просто не представляют себе других вариантов, кроме бесконечного листинга текстового программного кода (в лучшем случае разделенного на модули) или столь же неоглядной блок-схемы.
Я думаю, что визуальное представление программного кода должно быть блочным - не в смысле блоков блок-схем любого типа, а в смысле структурного программирования. Циклы и ветвления должны отображаться в виде блоков-виджетов в прокручиваемой вкладке или карточке. Последовательно обрабатываемые инструкции должны образовывать вертикальные списки, как строки в программном коде на Python. Вкладки и карточки должны организовываться в базу данных с различными инструментами поиска, а не только с поиском по древовидному списку. Модули должны организовываться в слои и иные группы, соответствующие выбранным архитектурным паттернам.
Вместо клавиатурного ввода должны в основном использоваться разнообразные средства интерфейса, в том числе с использованием автодополнения кода и ИИ. Потребуется внести изменения и в синтаксис языка. Например, точки с запятой для разделения операторов и фигурные скобки для тела функции уже не будут нужны - их заменят виджеты.
Система управления версиями должна быть встроенной (Git, прощай!). Должны быть встроенные средства для удаленной работы. Для предотвращения vendor lock-in должны быть открытые стандарты, форматы и протоколы.
А вообще многие комментарии к этой статье, направленные против отказа от текста, на самом деле полезны для отказа от текста, так как эти комментарии раскрывают реальные проблемы, для которых нужно просто найти решение.
А как эту вашу красоту в виме редактировать? А sedом или простым регэкспом как пройтись?
Да, это обязательные фичи. Особенно в больших кодовых базах.
В виме - никак. А также в ноутпаде++, блокноте и т.п. древних редакторах. Нужно новое средство разработки, которого еще нет
Как раз есть - ЧатЖПТ, например.
В нем всё внутри хранится, и можно из него что-то извлекать в том числе в виде текста, экспортировать.
Вот только есть нюанс...
Классный план. А оно точно прорастет на все те многие тысячи серверов? Там что-то около линукс лайк и бсд операционок. Любых версий и сборок выпущенных за последние 20 лет. Интерфейс - ssh, нет картинка не пролезет.
Подозреваю что тем кто железки программирует тоже надо. У них зоопарк еще больше.
Legacy must die. Любая информационная система лет через 10-20 обрушивается под тяжестью накопленных ошибок или новых требований и заменяется новой. Вот для этого и нужно новое средство разработки
Sweet summer child
Кто будет оплачивать этот банкет? (с)
Чтобы системы не обрушивались через 10 лет, проектировать их должны не двадцатидвухлетние как-бы синьоры с 3 годами опыта, а настоящие синьоры, лиды и архитекторы с опытом 10+, а лучше 15+ лет, которые видели некоторое дерьмо и понимают, как решения, принимаемые сейчас, аукнутся в будущем.
Если, например, я ставлю плюс статье, это не значит, что я согласен с её тезисами. Может быть просто интересная полемика.
Рекомендую ознакомиться с системами Графит-Флокс и Рапира+Школьница. Ещё можно погуглить Р-Технологии Глушкова. Такое ощущение, что Вы изобрели велосипед, но могу и ошибаться. )
А с какими аспектами этих систем Вы предлагаете ознакомиться? Краем уха смотрел когда-то давно на дракона, ничего особенного не заметил.
Как единое решение по представлению текста кодовой базы, БД хранения как "файловой системы" и формальных описаний входа-выхода, как элемента АСТ дерева. Там ещё, в ДРАКОНе есть версия ИДЕ Тышова (Мурманск), где комментарии к коду "иерархичны": ТЗ, решение, тестировщик, приемка. Несколько типов комментов. В целом ДРАКОН - малая часть Графит-Флокс. Но .. найти его описание не так просто в Сети к сожалению.
А еще заменить клавиатуру голосовым вводом а мышку глазным трекером !
Хранить код можно в любом виде. Редактировать будете в текстовом виде, как ни крути.
В итоге, некоторые "слои абстракции" просто меняются местами. Только, вместо моментального открытия текста, придется ждать, пока по диффам соберётся требуемая версия.
Хранить в CVS дельты или снепшоты - это перпендикулярный вопрос, я его не рассматривал.
Открытие текста в современных IDE не моментальное - он парсится в AST и потом рендерится на экран. Хотя бы для того чтобы раскрасить ключевые слова. Я предлагаю убрать первый шаг.
В продуманных IDE парсится фоном, а доступ к редактированию получаешь сразу.
Вам выше правильно написали. Подобные эксперименты уже были.
Если вас увлекает проект, продолжайте. Потом посмотрите на отклик сообщества.
А я вот если пишу код не в IDE, а в текстовом редакторе (да, мы существуем!) - как ваш подход может меня осчастливить?
То есть по сути разработчик вообще не заметит разницы, кроме случая, когда ему придется заглянуть в исходники не имея под рукой IDE? А не имея под рукой IDE как бы все.
Это типа что-то айфона? Вроде бы на устройстве музыки накачано, фильмов, фотографий, но вот просто так скинуть на произвольное соседнее устройство никак. И забрать тоже.
Я обожаю текстовые файлы. Если есть выбор, я и худлит пишу в маркдауне. SVG я делаю в текстовом редакторе. Если бы я знал плейнтекстовый формат для растровых изображений, я бы его использовал.
Если бы я знал плейнтекстовый формат для растровых изображений, я бы его использовал.
XPM же ж.
Есть еще Netbpm. Его прям даже не только X11 понимают...
Аналогично. Если надо написать что-то небольшое, то это летит в Телеграм в сохранённые сообщения. Если надо для чего-то большого, то создаю markdown - и вперёд. Не надо ничего выдумывать, если есть простые варианты. Максимум - потом в fb2 сконвертировать для форматирования.
Сейчас и музыку можно в текстовом виде писать: https://strudel.cc/workshop/getting-started/
худлит пишу в маркдауне
Для худлита дедушка Дон придумал TeX.
Почему мы все еще храним код в текстовых файлах?
Потому что коду повезло, и он изначально хранился в текстовых файлах, а остальная часть человекочитаемых форматов стремится туда-же, типа конфигов, документов, и прочего. В большинстве своем код нужен как текст - при редактировании, при отображении на страницах, при ревью, текстовый поиск, и даже те же нейросети текст едят. Сейчас можно любой код любым редактором отредактировать, переслать в месседжере, править и писать терминальным редактором, генерить тупо текстом.
А в Вашем формате нужно для каждой версии каждого языка адаптер, который этот формат гоняет туда-сюда постоянно, и интегрировать везде - системы контроля версий, все IDE, все "блокноты", системы поиска и индексации, и тд 🫠
Ну вот адаптеров для каждого языка написано уже предостаточно: https://astexplorer.net
И они интегрированы во все современные IDE, даже в vim.
Вопрос уже неактуален. Сейчас осталось мало программистов, которые сами пишут код. Увы, люди плохо приспособлены для этой работы.
PS: вспоминаю как когда-то по таблицам переводил ассемблерный код в машинный, а после дыроколом переносил его на перфокарты... никто не верил моим словам, что скоро это станет ненужным.
Во. Значит вы застали те времена. Это хорошо.
И вы тогда совершенно правильно подметили, что прогресс должен пойти в сторону упрощения. Сложности вообще слабо выдерживают гонку с более простым решением.
И вот в ИТ, через несколько витков эволюции код дошёл до самой наипростой и эффективной формы - просто текстовый файл.
Почему же теперь, спустя годы вы изменяете себе и решили, что сложное решение по всем пунктам лучше?
Потому что эволюция по своей природе это путь усложнения. Те наипростые и эффективные формы десяткомиллионнострочного текста которые сейчас в проде, т.е. выиграли эвлюционный отбор - не читаемы уже в принципе, это наимертвейшее легаси.
Нет, их можно прочесть, но затратить на это надо будет усилий больше, чем на написание новых.
Мы про исходный код говорим ведь. И тут эволюция была немного обратная:
сначала "код" делался "большими чугунными чушками", т.е. прям меняли конфигурацию железяки под нужный алгоритм
потом появились перфокарты
потом программы задавались построчно. Это уже был почти текст, но только состоящий из одной строки.
потом появился текст, но редактировать можно было только одну строку: задаешь номер строки и пишешь какие инструкции там должны быть
далее программисты начали работать с почти привычных нам текстовых редакторах (аля notepad). И где-то с этого момента формат хранения программы стал текстовым.
На этом эволюция имено формата для описания алгоритмов/программ остановился на текстовом формате. Было несколько попыток сделать по другому (Oberon и другие), но меинстрим за текстом.
Дальшейшую эволюцию уже получили инструменты по работе с текстом: компиляторы, IDE, системы версионированного хранения файлов и прочее прочее.
Как видите в разрезе исходного кода эволюция шла от сложного к простому. Не очень понимаю зачем сейчас нужно повернуть её вспять.
Нет, их можно прочесть, но затратить на это надо будет усилий больше, чем на написание новых.
Вот видите - их можно прочесть! если бы это был какой-то другой формат, AST в бинарном виде то, скорее всего, никто бы не заморачивался их поддержанием и портирования в новые операционки и IDE, ибо нужны полторы "интузиастам".
А вот благодаря текстовому формату мы их можете прочесть. И усилий для этого не нужно больше, чем чтение исходного кода на каком-нибудь другом языке.
Вспомним теперь, что на самом деле большинство ветвей эволюции были тупиковыми, а их представители вымерли, не оставив потомства. И где теперь эти трилобиты, динозавры и саблезубые тигры? Эволюция никогда не кончается. Утверждать, что текст - это венец творения, - это примерно то же самое, что утверждать, что 640 КБ хватит всем
на самом деле большинство ветвей эволюции были тупиковыми
вот эволюция и показала... Пока отмерло всё, кроме текста.
Эволюция никогда не кончается
Эволюция - это 1) случайные мутации, 2) адаптация к изменениям в окружении.
Мутации в плане способов хранения исходных кодов мы уже наблюдаем, пока ни одна из таких мутаций не прижилась. Точнее не так. Unreal Blueprint и им подобные нашли свою нишу, как пример.
С другой стороны сейчас самое большое изменение в окружении которое заставляет адаптироваться это AI. Но, тут опять же, промпты - суть текстовые исходники.
Я не исключаю, что когда-нибудь появится что-но эффективнее текстовых исходников. Но это должно быть реакцией на что-то очень грандиозное. Что это такое может быть - моей бедной фантазии не хватает.
У ИИ очень плохо с логикой, но зато "хорошо" с галлюцинациями. Проблема как раз в текстовой основе, в том, что LLM думает не структурно, а является просто гипертрофированной системой автодополнения кода или T9. Грубо говоря, LLM - это балаболка. Решая техническую проблему человек сначала думает структурно, иногда даже зрительными образами. А потом эту структуру он транслирует в речевой поток, который строится путем "автодополнения", как и в LLM. Но у LLM нет в основе четкого структурного представления действительности, а есть только зыбкие и противоречивые правила, заимствованные из промптов. Поэтому и посредственные результаты. Сейчас все еще господствует ошибочное представление, что LLM решат все наши проблемы, и поэтому нужно просто расслабиться и ничего больше не предпринимать.
Отказ от текстового программного кода - это как раз попытка использовать реальное превосходство человека над LLM в способе мышления. И это может дать гораздо более качественный и экономически эффективный программный код (учитывая цену ошибки и необходимость в код-ревью). При этом LLM вполне может использоваться для поиска, подсказок и т.п.
Нужные мутации уже есть (их при желании можно найти в интернете, и это не блок-схемы). Но они еще неразвитые. А на развитие нужен капитал. А чтобы он появился, действительно нужен какой-то веский стимул (безопасность?). Но пока всех устраивает разработка по принципу тяп-ляп и в продакшн, я такого стимула тоже не вижу. Проблема еще и в том, что разработка инструментов (компиляторы, линтеры, IDE) редко бывает выгодной - компании или пользуются пиратскими инструментами, или дают своим разработчикам что-нибудь оупенсорсное. Видимо, лед тронется, когда когда-нибудь крупная IT компания решит сделать инструмент для себя, и каким-то неожиданным образом ее взгляд упадет на идею хранения программного кода в AST или, может быть, с помощью языка разметки AST.
потом появились перфокарты
потом программы задавались построчно. Это уже был почти текст, но только состоящий из одной строки.
потом появился текст, но редактировать можно было только одну строку: задаешь номер строки и пишешь какие инструкции там должны быть
далее программисты начали работать с почти привычных нам текстовых редакторах (аля notepad). И где-то с этого момента формат хранения программы стал текстовым.
Вот только всё это уже - текстовые исходники, а описываете вы лишь эволюцию носителя и редактора. Они как появились в конце 1940-х, сначала в виде мнемокодов на бумажках, транслируемых в машинный код сначала в уме, потом программой-транслятором, так с нами и остались по сей день. Эволюция, она останавливается, если животинка идеально подходит для своей экологической ниши, см. черепахи, акулы.
Прочитать можно и условные письмена майя, только смысла в этом нет никакого кроме спортивного интереса - информация полученная из них не стоит усилий, на них затраченных. Нет там ничего про тайны вселенной и холодный термояд. Разве что прокачать скиллы расшифровки - полезная побочка, не более.
И в этом плане - донести до потомков как это работает - программный код проигрывает банальному хорошо написанному ТЗ искомой программы, где вместо скрижалей COBOL-а и сотен часов умственного реверс-инженеринга разработчик получает инструкцию как оно должно работать и создает реализацию на любом стильном модном молодежном инструменте, покрывает тестами и в прод.
Поэтому нет, для задачи самодокументирования текстовый именно программный код не лучшее решение. Если это активный стек разработки и активно развивающаяся программа то да, код текста не так уж и плох, но только в связке со сколь-нибудь вменяемым ТЗ, а если мы про некро-программы, похороненными миллионами строк кода и сотнями умерших зависимостей, то ТЗ в первую очередь.
Потому что все реализации будут опираться на какой-нибудь фреймворк и что бы понимать достоверно как оно вообще работало этот некро-фреймворк надо будет изучать, знать и экспериментировать. А фреймворк к тому моменту со своей средой исполнения уже будет безвозвратно мертв со всеми явными и неявными зависимостями и их характерными нигде не документированными очень важными багами, простите особенностями.
Текстовые файлы идеальны.
Они простые. Они человекочитаемые. Они абсолютно надежные. В них точно нет и не будет уязвимостей или скрытых данных. Они хранятся именно так как редактируются. Они не зависят от языка на котором вы пишите и поддерживают все языки, в том числе еще не изобретенные. Их можно поправить прямо в vi при необходимости. Они не зависят от платформы и правильно открываются и редактируются на всех платформах, в том числе еще не изобретенных.
А с размером можно как-нибудь смириться. Я думаю что человечество готово заплатить за этот оверхед в обмен на все плюсы текстовых файлов.
Индексы придуманы давно и индексация перестала быть проблемой.
Единственный комментарий, который отвечает на вопросы из статьи полностью и парирует каким-то неуместным аргументам в пользу усложнения инструментария. Текстовые файлы идеальны, созданы людьми для людей. Машины - это инструмент в руках человека.
Это как... Почему Мы до сих пор используем молоток для забивания гвоздей? Или... Почему Мы до сих пор используем лопату для выкапывания ям (грунта, чего угодно)? Или... Почему Мы до сих пор используем колёса для перемещения чего-либо?))) Есть же законы гидродинамики, сверхпроводимость и др. Можем в аэротрубе на работу перемещаться, как в футураме, на воздушной подушке грузы перемещать, к дорогам будем почти не привязаны... Крч... Пошёл писать статью на Хабре)))
Сомнительные аргументы. Помимо молотка, лопаты и колеса уже давно существуют шуруповерт, экскаватор и лодка/самолет/поезд на магнитной подушке. А кроме привычного нам текста есть схемы, таблицы и графический интерфейс. Тоже, кстати, созданные людьми для людей. И наскальная живопись появилась задолго до глиняных табличек с текстом. Удивитиельно, что многие разработчики настолько консервативны, что сходу и не задумываясь отторгают всё, что не связано с текстовым редактором, к которому когда-то были приучены.
Забивать гвозди шуруповёртом — интересная идея. Мне это в голову не приходило, но, наверно, принципиально возможно. Хотя молотком, скорее всего, удобнее.
Ну смотря что вам нужно. Если зажать гвоздь 120 в патрон шурика, то он входит в доску не раскалывая её, и плотнее чем при предварительном засверливании сверлом.
И тем не менее, есть мнение, что шуруп, забитый молотком, держится крепче, чем гвоздь, закрученный отвёрткой шуруповёртом. :-)
Я уязвлён отсутствием в сравнительном анализе таких столярных инструментов, как утюг и микроскоп.
В том то и суть, что при обилии различного транспорта и инструмента, который развивается, совершенствуетсяи становится всё более доступным и используемым, всё же глупо задаваться вопросом: почему Мы используем "примитивные" казалось бы нструменты. Мы их и используем в виду их простоты и функциональности. У схем, графиков, таблиц очень широкая область применения, и появились они как раз по причине большей уместности применения для выполнения определенных задач. Мой аргумент говорит о том, что даже при наличии у Меня (абстрактно) экскаватора на заднем дворе, в инструментах всё равно будет лежать лопата. И у соседа скорее всего она будет и у многих других. До лопаты, скорее всего, существовали и другие инструменты для выкапывания ям, как и в случае с наскальной живописью. Но текст, в отличии от картинки, менее вариативен, тк в картинке присутствует доля творчества и глядя на изображение не всегда поймешь, что там изображено или что хотел сказать автор)))
По поводу большого количества разработчиков, которые всё отторгают, Я категорически не согласен! Тк именно разработчики задаются подобными вопросами, по изменению иструментария. Тут больше подходит аналогия с учеными. Почему Мы до сих пор изучаем ньютовскую физику, если можем оперировать состояниями квантовой запутанности. И наверняка есть ученые, которые для вычислений используют сложные модели, но! Для большинства достаточно какого-то примитивного представления.
Тескс существует 5,5 тысяч лет +- (Шумеры), программисты 50 лет (ну, сотку от Меня лично еще сверху). Всё! До каких пор Мы будем использовать текст для хранения информации?!? А код это точно информация.
Я не против новых паттернов хранения информации. У еня претензия к заголовку. Лучше было назвать статью наподобие: А только ли в тексте Мы можем хранить код. Вот тут то и есть поле для дискусий, в комментах можно было бы обсудить как раз новые варианты представления кода и подобного. А Мы обсужтаем уместность текстового хранения, что однозначно удобно и допустимо, но не является (подчеркну!) единственно возможным и верным
А с размером можно как-нибудь смириться
Вот это самый странный аргумент у автора. AST весит на пару порядков больше. Для проверки достаточно сдампить AST и глянуть.
Сдампить в текстовой формат что ли? AST не весит больше (разве что для специфичных участков), все ключевые слова заменяются на однобайтовое число, все идентификаторы на 4/8-байтовое (указатель на таблицу). Выигрыш будет в основном за счёт этого + отсутствие разделителей (пустое пространство и знаки вроде `,;{[`).
Правда это экономия на спичках.
Это вы говорите по теории. Я писал несколько своих языков. И делал несколько разных AST и дамп тоже.
При любом раскладе текстовое представление будет существенно меньше весить.
А если сюда добавить компрессию (на уровне файловой системы, например), то у ast вообще никаких шансов.
Я имею ввиду, что дампить нужно не в текстовой формат. Конечно, если в текстовой, то будет сравнимо даже с учётом оптимизаций, но если в бинарный, то почти точно будет меньше весить для реальных проектов.
Ну и на всякий случай, я тоже реализовал некоторое количество ручных парсеров, поэтому вполне понимаю как AST устроено для реальных языков.
А вот по поводу компрессии - будет сравнимо, так как в обоих случаях исходная энтропия не сильно поменяется (КМК), но за счёт дополнительных оптимизаций будет меньше объём занимать.
Попробую вечером посчитать на паре примеров и отпишу результат.
При любом раскладе текстовое представление будет существенно меньше весить.
ЛИСП — это любой расклад?
Про независят от платформы помарочка - перевод строки....
а между тем это две разные переменные: Variable и Vаriable
Итак, давайте представим, что мы разрабатываем систему для разработчиков, где они могут писать код, читать его и обмениваться изменениями. Должны ли мы использовать текстовые файлы в качестве основного источника истины? Очевидно, нет. Это неудобно, ненадежно и может привести к несогласованности.
Нифига не очевидно. Пока мы работаем с текстовыми файлами, у нас полная свобода в выборе инструментов. Кому-то нравится vim, а кому-то вендовый блокнот. Кто-то использует для поиска хитрую цепочку из find, grep и xargs, а кому-то нравится кнопка F7 в Far-е. Кто-то использует ctags, а кто-то - сложный IDE с анализом кода и навигацией. И каждый волен выбирать инструменты на свой вкус, текстовый формат в этом плане очень гибок и ничего не навязывает.
Как только на месте текстовых файлов окажется какая-то хитроумная база данных, все окажутся привязаны к её инструментам. А если производитель решит закрыть этот проект, то и все данные, представленные в этом формате, превратятся в тыкву.
Git хранит файлы в какой-то своей внутренней структуре, и ничего, все привыкли и не боятся. Здесь точно так же, можно скачать из репозитория, сохранить в текст и редактировать. Но диффы будут кривыми.
А по моему опыту (C#, Typescript) почти все импользуют IDE в 99% случаев.
Git хранит файлы в какой-то своей внутренней структуре, и ничего, все привыкли и не боятся
Git - это всего лишь хранилище текстовых файлов с аннотированной историей. Он не навязывает никому свой богатый внутренний мир. Из git-а можно совершенно спокойно перенести проейкт в какую-нибудь другую систему контроля версий и даже историю не потерять.
Но диффы будут кривыми.
Во-во.
А по моему опыту (C#, Typescript) почти все импользуют IDE в 99% случаев.
А по моему - нет.
А по моему опыту (C#, Typescript) почти все импользуют IDE в 99% случаев.
Даже гипотетический 1% (хотя наверняка намного больше) - это достаточно, чтобы не разменивать простоту и универсальность на такое сугубо второстепенное преимущество, как компактность хранения.
Возьмите исходник любого языка, на котором можно написать хеллоу ворлд, "привет, как тебя зовут", "вася", "привет, вася". Ну или самоме сгенерячить йакком-бизоном, неважно. Мини-паскаль какой. И попробуйте поверх реализовать задумку.
Ага, только сейчас, чтобы что-то исправить в проекте, я могу открыть один файл и там исправить любым редактором (все нормальные редакторы, включая Блокнот, уже давно прекрасно умеют работать с любыми кодировками). А если мне что-то понадобится исправлять в этой новомодной БД, то мне нужен будет специальный инструмент, который к тому же обязан будет потянуть чуть не всю БД, поскольку ему придется декомпилировать один класс, но класс-то зависит от нескольких других классов, а те еще от кучи классов, а те от фреймворка, который тоже как-то придется тащить целиком в каждый проект, по крайней мере на уровне контрактов.
А что делать, если я хочу сохранить некомпилируемый в данный момент код? Это, конечно, плохо так делать, но так бывает. И никакое AST по нему не построить.
Ну и, конечно, осталось уговорить всех-всех программистов на свете использовать эту замечательную во всех смыслах штуку, ага.
Некомпилируемый код как-то парсится в AST - IDE его может отформатировать (иногда очень плохо) и подсветить синтаксис. А значит что-то да понимает.
и подсветить синтаксис
Подсветка синтаксиса же обычно не использует AST, это простой токенизатор
Чтобы необъявленную переменную подсветить красным нужно дерево
treesitter использует - крутая штука, легко прикручивается куда угодно.
Есть два варианта подсветки, второй "семантическая", которая как раз и требует полноценный анализатор кода. Второй вариант даже глазами увидеть можно, при открытии проекта, когда цвета через секунду другую перекрашиваются.
Даже не варианта а этапа. Обычно этапы такие:
Редактор загружает текст и показывает его в голом виде
Отрабатывает лексическаий анализатор и текст подсвечивается нужными цветами
Отрабатывает семантический анализатор и подстветка корректируется с учетом этого
А текст можно редактировать уже на первом этапе.
Как вам там в 2000 году живётся?
Неплохо, кстати. Программировать в 2000-м году было как минимум, продуктивнее. MVP клепались на коленках за несколько дней, разнообразия платформ не было, интерфейсы рисовались мышкой, миллиона зависимостей не требовалось.
разнообразия платформ не было
Эм… В конце девяностых я работал со связкой КОБОЛ–C–VB3–Oracle. В начале двухтысячных — Java–Haskell–LISP. Ну и еще всякие PHP/Delphi/JS, разумеется.
Сейчас кроме двух с половиной «любимых» языков — постоянно ничего и не использую.
Эм… В конце девяностых я работал со связкой КОБОЛ–C–VB3–Oracle
Ну это такая экзотика, где вы могли на такой связке работать? В крупном банке, где AS/400 пыхтела? Таких на всю страну несколько десятков было. А так, 99% писали под винду. Мобильная разработка была в зародыше, веб тоже, знаешь HTML4 + PHP, и умеешь верстать табличками, уже веб-разработчик.
Некомпилируемый код как-то парсится в AST
Не всякий. Есть вариант, когда ast отстроить можно, а скомпилировать - нет.
В Visual Age for Smalltalk с его ENVY сохранение кода происходит на уровне метода - не компилируемый не сохраняется. Работать совсем не мешало.
не компилируемый не сохраняется. Работать совсем не мешало.
Вы серьезно считаете что так можно работать?
Я не только так считаю, я так работал. Но дело в том, что по своей природе методы в smalltalk преимущественно маленькие, а сохранение происходило именно на уровне метода. Неудобств не вызывало. Спросите у любого smalltalk`ера. Применительно к другим языкам - уверен, такое не прокатит
Есть у вас метод с суровыми конструкциями и сложной бизнес логикой. Что там именно не знаю, но не важно. Вы его писали полдня. Он не компилируется по объективным причинам. Надо куда-то отойти. Поесть, например. Надо верить что электричество не отключится? Так себе план. Я бы в блокнотик скопировал для надежности.
И зачем так системы делать? Компьютеры для человека, автосохранение вообще всего текста введенного человеком раз в минуту не стоит ничего. Значит оно должно быть.
Я никого и ни за что не агитирую. Просто рассказываю, как обстоят дела в ENVY.
Ксло, на smalltalk написать не компилируемый код весьма не тривиальная задача, учитывая его синтаксис и динамическую типизацию.
Но если удастся таки за полдня написать метод, который не компилируется - можно его просто закомментировать и блокнотик не понадобится
Написать код который не компилируется гораздо проще чем написать код который компилируется. Про работающий правильно код и речи нет.
Но если удастся таки за полдня написать метод, который не компилируется - можно его просто закомментировать и блокнотик не понадобится
Видите, вы уже про костыли начали говорить. Костыли которые надо постоянно микроменеджить человеку. Зачем? Пусть компьютер просто сохранит этот кусок текста. Человек должен решать более сложные задачи, а не комментировать кусок кода чтобы сохранить его.
Я рассказываю, как работал ENVY и что это не вызывало проблем, а Вы меня за советскую власть агитируете.
Написать код который не компилируется гораздо проще чем написать код который компилируется
Всё что я говорил относилось к конкретной среде разработки и конкретному языку. На smalltalk невозможно написать синтаксически правильный не компилируемый код. Вы боретесь с несуществующими проблемами.
Берем стратч, синклер бейсик, кумир древних времен - и вот у вас ИДЕ которая не позволяет собрать не компилируемую сущность.
Просто берем синтаксические диаграммы и каждое нажатие клавиши должно работать на их уровне. И только имена переменных и значения констант можно править текстом.
Закомментируйте.
У меня более 30 лет стажа, и ни разу в своей жизни я не сталкивался с ситуацией, в которой мне доводилось полдня писать один метод.
Даже на КОБОЛе процедуры было принято как-то ну аккуратнее, что ли, архитектурировать.
У меня более 30 лет стажа, и ни разу в своей жизни я не сталкивался с ситуацией, в которой мне доводилось полдня писать один метод.
Мне приходилось как-то неделю писать один метод. При этом он был не особо-то и большой, полсотни строк. Смотря какие задачи решать. Но да, это сильно частный случай, у меня такой был один за всю практику
не ну как ребята, смотря что за метод и что подразумеваем под "писать".
Иногда ж больше нескольких суток уходит на исправление одной-двух строчек и это не какой-нибудь там плавающий баг, а вполне себе бизнесс-логика, только заказанные ее изменения рушат архитектурную концепцию или размазаны по объектам тонким слоем. Иногда железячные и временные ограничения диктуют архитектурирование что в страшном сне потом снится и там тоже на скуле специфичную бизнес-логику вырисовывать это прям серьезно поболее чем пол-дня и даже дни.
Не нужно ничего парсить. AST должно строиться непосредственно средствами инструмента со встроенным линтером, а не парситься из текста программного кода. Тогда будет невозможно сделать что-нибудь некомпилируемое.
А как тогда, например, написать вызов несуществующей еще пока функции? Или Вы предлагаете вести разработку не сверху вниз, как это принято, а снизу вверх?
Ну, значит, AST должно допускать заглушки, которые должны по-разному обрабатываться в разных режимах компиляции
Замечу, что нет принятого направления в разработке. Есть модные течения: сегодня модно сверху вниз (ибо ТЗ какое попало, там разберемся), завтра снизу вверх (ибо ТЗ позволяет начать с тестов нижнего уровня, а даже не с кода) и т.д. Можно и совмещать "приятное с полезным" в разных пропорциях: тут ясен пень, будет БД, пишем к ней драйвер, а вот тут, надо бы детализировать решение, пишем сверху вниз .. и? В какой-то момент у вас "поставщик данных" и может даже уже покрытый тестами и к нему .. верхний слой входящего интерфейса, ибо описано сваггером и плюс малюсенький кусок бизнес-логики от всего ТЗ.. так не можно? Да ещё как! Легко.. )
Есть модные течения: сегодня модно сверху вниз (ибо ТЗ какое попало, там разберемся), завтра снизу вверх
Разработка ПО, в «нормальном» случае, приводит к тому, что делаются абсолютно новые программы. То есть, в нормальном случае, есть элемент поиска. Для этого хороша разработка «снизу вверх».
Когда всё понятно заранее, какая архитектура системы, то разумно разрабатывать «сверху вниз», чтобы уже написанная часть программы структурировала процесс разработки.
Поэтому эти два стиля — это не дань моде, а два дополняющих друг друга инструмента. Обоими надо владеть, и надо понимать, когда применять какой.
Разработка ПО, в «нормальном» случае, приводит к тому, что делаются абсолютно новые программы. То есть, в нормальном случае, есть элемент поиска. Для этого хороша разработка «снизу вверх».
Разве не наоборот? Я знаю что на входе, догадываюсь, что на выходе, понятия не имею как.
Значит пишу функция, типа такого, параметры такие, скобочка открывается, скобочка закрывается.
Потом внутри скобочек пишу десяток строк комментариев с описанием алгоритма, потом каждая строчка превращается в процедуру/функцию.
А как можно снизу вверх? я же еще даже не знаю, что эта нижняя функция вообще должна существовать?
Разве не наоборот? Я знаю что на входе, догадываюсь, что на выходе, понятия не имею как.
Это если вы догадываетесь, что вам нужно на выходе. А когда и этого вы не знаете, тогда «снизу вверх» рулит.
А такое бывает — у нас же есть NP полные задачи, или вообще невычислимые. То есть, надо брать какое-то приближение, а какое из возможных вариантов лучше подходит к задаче? Бывают ситуации, когда не попробовав не узнаешь.
Чаще это выражается ещё проще: ТЗ знает откуда берутся данные (из старой доброй БД предприятия, которой лет 30) а вот что надо получить на выходе, сформулировано в "отжал-стиле": "ну там это, ты же умный, выдай как-нибудь, а мы посмотрим".. пока пилится низ (выборки, формирование чего-либо, предобработка), ТЗ уточняется совещаниями в срам-стиле.. )
Да. Ну это же часть работы программиста — уточнение требований, рисование цели как «меткий Джо» — её ведь нужно рисовать там, куда можно попасть. А тут сверху-вниз не очень работает.
Вот и получается разработка в виде зёбры: где сверху-вниз, а где и снизу-вверх.
У меня чаще все-таки запросы "нам надо это, наверное оно хранится в БД, но где точно мы не знаем. А нужно - именно это". А потом аналитики тюнят с точностью до инфосистемы в которой это хранится для тех полей, которых все-таки нет в нашей БД. В крайнем случае делаем табличку и отдаем пользователям со словами "надо рисовать процесс, кто будет теперь за ее наполнение отвечать, как заполните - заработает".
Визуальное представление больше на мой вкус конечно в том самом стиле "выдай, а мы посмотрим", но наполнение довольно четкое.
Я лично веду разработку (своих библиотек, например) — как строили тоннель под Ламаншем. Я пишу сразу и API, и самый нижний уровень.
Правда, иногда погрешность оказывается не полметра, как там, а метров сто. Ну да, тогда приходится вносить коррективы.
Зачем нужен вызов несуществующей функции?
Не любой: пока код не компилируется, используется последняя скомпилировавшаяся версия. Если таковой с момента открытия редактора не было — выбрасывается незакрытый узел дерева, потом его родитель, и так далее, пока не скомпилируется.
Да, еще как-то надо будет переделать сообщения об ошибках, которые сейчас содержат номер строки кода, а в этой системе они куда будут посылать программиста? В некие координаты листочка AST? Как будут выглядеть вещи типа PDB файлов?
О, это хорошие вопросы, спасибо.
Координаты листочка AST может быть даже полезнее будут - в одной строке могут быть всякие лямбды и не всегда удобно брикпоинт ставить.
Про PDB файлы надо будет почитать, что там как.
Надо не забывать, что номер строки отдает компилятор, а не среда.
Кстати, помимо хранения всего этого, как быть с компиляторами? Они-то текст пока на входе принимают. По всему глобальному AST выстраивать исходные коды и потом отдавать компилятору? Ну, помимо того, что это все выглядит несколько шизофреничным, это еще и дикое количество времени занимать будет.
Примерно так оно работает в TypeScript - во время компиляции парсятся в AST все файлы проекта и сериализуются в JavaScript. А потом движок JS заново строит AST и выполняет его. Выглядит весьма шизофренично.
Сериализовать в текст можно при загрузке проекта / смене ветки.
А потом движок JS заново строит AST и выполняет его. Выглядит весьма шизофренично.
Поэтому для веба придумали wasm. В который вы можете транслировать код практически из любого языка без необходимости строить промежуточный Javascript.
TypeScript - отдельная песня, там не компилятор, а конвертор по сути. В любом случае ему на входе исходники текстовые приходят и ошибки он выдает с указанием на строки этих исходников. И если вы не восстановили код из AST, а попытаетесь скомпилировать его из того, что только что ввели на экране, то очень часто компилятор будет "мазать". Т.е. при каждой компиляции надо будет преобразовывать код в AST, потом из него получать код для компилятора и тут же его назад среде подпихивать, чтобы было 100% совпадение. Уверен, разработчик будет счастлив, когда у него постоянно код будет переформатироваться.
Короче, я на 100% уверен, что эта затея дурацкая и в целом мертворожденная.
В AST никто не мешает положить координаты «текстового представления». Так делают языки, в которых AST не игрушечный, прикрученный сбоку, артефакт (как в тайпскрипте и расте, например), а полноценный гражданин первого сорта.
В тайпскрипте в ast есть координаты в тексте
Координаты какого текстового представления туда можно положить, если текстового представления нигде не хранится?
Того текстового представления, которое показывают на экране разработчику. Где оно там хранится, или не хранится — вопрос сто тридцать пятый.
А что показывается на экране разработчику во время компиляции? Я могу компиляцию вообще из командной строки запустить. И по задумке автора в этот момент исходного кода у компилятора не будет, только AST в бинарном формате.
Давайте вы перечитаете свой первый комментарий, на который я отвечал, и перестанете переобувать начальные условия в прыжке.
И логично что в АСТ будет содержаться адресация на место в визуальном представлении, которое надо показать разработчику чтобы он его поправил.
Будет это текст, узел в диаграмме визуального программирования, или прямое преобразование бинарника в человекочитаемый вид - достаточно не важно.
По всему глобальному AST выстраивать исходные коды
А как работают LLVM или GCC ? они же ТАК не делают, у них уровень после фронтэнда вовсе не занимается "восстановлением до текстового Си"
Вы действительно не видите разницы между предложенной идеей хранить код в бинарниках (с восстановлением исходного кода из AST) и двухэтапной just-in-time компиляцией, применяемой в LLVM/JVM/CLR?
Я не вижу необходимости восстановления исходного кода для компиляции, если современные компиляторы УЖЕ компилируют AST (и другие промежуточные форматы), а не текст. Остаётся просто передать им этот AST сразу на вход, пропустив ненужные больше конвертеры.
Более того, это уже делали, например https://iq.opengenus.org/code-generation-from-ast-to-llvm-ir/
Про JIT в LLVM сейчас смешно было, да. В виде экспериментов и нишевых решений генерация кода была всегда, в том же видеоредакторе VirtualDub, который написан на кондовом Си. Это не делает HotSpot-VM-подобный режим, с многократной перекомпиляцией одного и того же кода, основным режимом LLVM.
Остаётся просто передать им этот AST сразу на вход, пропустив ненужные больше конвертеры.
Так и осталось всего-ничего переучить все компиляторы готовое AST на вход получать! Ну и как-то пробрасывать сообщения об ошибках, которые так или иначе в AST пролезут назад разработчику, ему-то номера узелков/листьев как-то ни к чему.
Про JIT в LLVM сейчас смешно было, да.
А я что-то писал про основной режим? JVM тоже в подавляющем большинстве случаев как интерпретатор работает. В данном случае это роли не играет. Все бинарники для байт-код виртуалок так или иначе строятся из исходников и есть механизмы, которые этот байт-код к исходникам привязывают для отладки. И компиляция в этот байт-код выполняется тоже плюс/минус единообразно. Но ни одна из этих инфраструктур из байт-кода не восстанавливает "живые" исходники, с которыми работает разработчик, хотя в принципе это возможно. Мало того, я прямо профессионально с этим сталкивался, когда надо было восстановить и исправить C# приложения, исходники которых не сохранились или не были доступны по той или иной причине. Но это совсем-совсем другая история.
Мне всегда казалось, что оно так и происходит: ошибка отдается в координатах AST, а уже потом превращается в строку кода, возможно ещё на стадии компиляци "с отладкой".. не? )
текст удобнее, с текстом тоже работать удобнее, а вот как это реализовано в иде не хочу знать ), там еще как я понял от языка зависит, на С++ например можно подумать, а вот с java так не выйдет вроде
текст хрупкий, текст без подсведки не читаемый и текст без IDE непонятен.
Например ответьте что делает этот кусок кода
var result = await _service.CreteNewVersion(identity, type);
Какой тип у result? Какой тип у identity или type? Они вообще в правильной последовательности передаются? Может правильный порядок должен быть type, identity??
И на последок - а вы заметили вообще опечатку у CraeteNewVersion? А во второй раз?
Вот не надо им подсказывать, а то начнутся патентованые форматы, это открывается в этой IDE, а то - только вон в той, платной и т.п. У вас тут аннотации? О, это открывается только в версии Pro Platinum Ultimate Exclusive, добро пожаловать в кассу. Уже всё, что можно, огородили и монетизировали до полусмерти, теперь вот подобрались к исходникам. А ещё лет через двадцать начнётся: этот исходник отрывается только в какой-то заброшенной IDE, которая работала на Windows XP, а на более свежих операционках у неё какая-то dll-ка отваливается, а починить не кому. А ещё исходники начнут в разных версиях IDE открываться немного по разному, пРивеТ tебе, чёртов WOrd!
И можно будет бесконечно играться во всякие переполенения буфера и выпускать обновления безопасности, но только для последней версии IDE, остальные сами себе буратины, что не обновились. А ещё можно будет насовать в исходники макросы, а то что ж такое, единственный безопасный формат остался, и макровирусов нет, непорядок. Макросы будут при открытии исходника что-то там менять в его отображении, чтобы вообще было потом не разобраться, что откуда берётся. И на собеседованиях будет о чём спросить.
Очень оторванный от реальности подход. Проблем у него миллион, навскидку хотя бы такие:
– Чтобы этот подход работал, нужен coding standard, регламентирующий АБСОЛЮТНО ВСЁ. Межблочные интервалы. Выравнивание знаков равенства в блоке похожих выражений var1 = value1. Шаг в сторону и летит любое кастомное форматирование кода. Вот например несколько способов записать массив чисел, пользуясь одним и тем же кодстайлом:
( 1 2 3
4 5 6 )
( 1 2
3 4
5 6 )
( 1 2 3 4 5 6 )
После roundtrip в AST и обратно будем выводить всё в 1 строку, да? Не всё кастомное форматирование является, как вы выражаетесь, "самовыражением". В некоторых случаях человек записал числа прямоугольником 2x3 потому что это способ наглядно представить данные, например там числа логически идут парами. В другом случае он вылез за разрешённую кодстайлом ширину текста 100 символов потому что иначе не влезает длинное объявление объекта. В третьем случае поставил 3 пустых строки, а не как по стандарту 1, вокруг какого-то блока, потому что там кластеры блоков кода. Исключения, исключения... Никогда и нигде в реальном проекте вы не встретите большого куска кода, способного без изменений пережить десериализацию в AST и сериализацию обратно.
– Чтобы этот подход работал, надо к каждому репозиторию с кодом иметь корректно парсящую его систему, которая может весить в разы больше скромного набора plaintext строк.
– Первый же реальный проект, в который вы притащите ваш редактор, начнётся с того, что там будет сторонний код, использующий собственный кодстайл (или не использующий вовсе), править который под "ваш" кодстайл и подключать ваш парсер никто не будет. Как взаимодействовать с таким кодом?
приходим к статике тоесть, я вот пользуюсь блокнотом, но запускаю иногда ИДЕ
(кароче то о чем вы пишите это около простейшего блокнота) не исключая крутейшие возможности, я попробовал пришел к такому
можно еще улучшить наверно, ну и я даже изза того что знаю что могу открывать большие файлы из-за того что у меня полностью статичный блокнот, тоесть я ничего не считаю, я даже при открытии файла отрубил подсветку ), статичный аспект типо только ввод (и парочка команд по работе с текстом) ближайший аналог печатная машинка
так а парсинг это либо парсинг+конфигуратор либо просто не нажимаем формат текста, ну зависит от крутизны исполнения парсинга
но вообще я вот погрузился в него ради С++ фич кланга, типо анализатор это просто опции по запуску прогонке от кланг-тулс) во втором тайлинговом окне которую если открыть скрывается мини кли основного, для консистенции и погружения в стенд, тоесть до конца от крутых ИДЕ врятли откажешься сегодня, наверно мне почему-то кажется
Имел дело с подобной системой. Боль и страдание.
Всё форматирование идёт лесом. Когда у тебя функция на экран... в общем не тот язык назвали perl. Позже прикрутили автоформат, но он тоже форматирует в один конкретный стиль, что не всегда удобно (но бесконечно удобнее, чем было).
Не заметил упоминаний про комментарии. Что там с ними в AST? В той системе их не было. Точнее потом их добавли. Но, поскольку его надо было впихнуть в код, получилось это своеобразно. Как-то так
Скрытый текст
Что касается комментариев, то просто добавляется к токену необязательное поле с комментарием и тот всегда будет на месте. Ну или отдельный пассивный токен, если комментарий размещен вне классов/методов. Короче, тут можно выкрутиться. Но форматирование, форматирование точно полетит к чертям.
Короче, автор пытается решить решить одну проблему (которая не факт, что вообще решаема таким образом, мерджить деревья задача еще более сложная, чем мердж текста), а создает с пару десятков других.
В JS повсеместно используются линтеры-форматтеры, иногда с очень строгими правилами форматирования, которые в хуке перед коммитом форматируют код. И там просто нельзя запушить код с тремя пустыми строками между блоками. Я не говорю что это хорошо, но так живут, и у этого подхода есть свои плюсы.
Значения в ast сохранены в виде строки, так что можно будет массив в столбик записать. Хотя опять же я думаю есть более удобный способ для этого.
– Чтобы этот подход работал, нужен coding standard, регламентирующий АБСОЛЮТНО ВСЁ.
а популярный сегодня Go не такой?
О, я однажды работал с похожим окружением, где код существовал в конечном виде в специфичном представлении в базе данных. Это был сущий кошмар, потому что база была в интранете компании, а он иногда лагал - и в итоге даже просто напечатать что-то в редакторе было челленджем, потому что подсветка синтаксиса оформлялась где-то на другом сервере.
Преимущества
Чистые диффы
Производительность и сокращение выбросов CO2
Согласованность между вашими инструментами
Спорно. Не вижу ничего грязного в текстовых диффах. С легким трепетом представляю себе разруливание конфликтов в графе...
Не понял, особенно вторую часть... Стильно, модно, МОЛОДЕЖНО, старперы отсеются и перестанут попукивать?
Текст прекрасно согласуется между огромным количеством IDE и текстовых редакторов, включая мультиплатформенность и доску с маркером. Предлагаемая система достигнет такой согласованности когда?
И я так и не понял, код-то как писать? Рисовать граф мышью? Собирать из кубиков и соединять их палочками? Или по-прежнему набивать кнопками? Если код остается текстом, то какой вообще смысл в этом всем - от преобразований туда-сюда это не спасает, просто меняет часть преобразований местами. Если код - не текст, спасибо, не надо. Мне LabView хватило надолго, как вспомнишь - так вздрогнешь...
Ну конечно, "простой двоичный формат" рано или поздно должен (нет, обязан) был докатиться и до сюда. Впрочем, тут он уже был - PDF, DOC и прочий легион форматов. Правда использовался в основном не для исходного текста, но по сути это был лишь вопрос времени.
Будет ли это удобнее и быстрее? Очень спорный вопрос. Для компилятора может быть. Для человека... Возможно это будет незаметно, но удобнее наверняка нет. Все же исходный текст это текст, на языке близком к естественному (в отличии от машинных кодов, в которые он переводится компилятором). Тут, правда, начнет сказываться зоопарк языков. Оформление текста на Python'е и C весьма значительно отличается. Плюс проблема комментариев. Им тоже надо найти место и непротиворечивый вывод.
Можно экспериментировать. Кто знает - может за этой, сегодня очередной игрушкой, действительно будущее. А может просто тихо умрет, как многое другое.
Чего далеко ходить, вон разработчики хабраредактора отказались от простого текста в пользу не пойми чего с внутренней структурой. Казалось бы, что может пойти не так?
Лучше делать софт или веб фреймворк который сам пишет классы и функции - то есть не форум или блог а фабрику сайтов которая пишет сам код форума в базу данных и хранит его в себе - 1 форум = 1 php class или что-то подобное и коментарии к посту хранят функции и свойства а выполнение происходит в виджете на сайте...
Мне кажется это на много интереснее чем VS-Cide
Надеюсь что в xenforo будет такая возможность и тогда вся команда сядет за одним форумом (как ide)...
Очень интересно будет посмотреть на диффы в таком проекте. Автор, успехов вам
Программирование состоит из абстракций: выражения, условия, классы и т.д. Поэтому вопрос поднятый автором выглядит логичным, зачем программировать буквами, если можно сразу использовать более высокоуровневые абстракции?
Так в том то и дело, что автор предлагает использовать не высокоуровневую абстракцию, а более низко уровневую.
Текст - максимально высокоуровневая обстракция. Текстом вы можете описать исходный код на любом языке программирования, описать данные, схемы и документацию.
AST и то, что предлагает автор - более низкоуровневое, специализированное, заточенное под конкретный язык или стек языков.
Под уровнем абстракции имел ввиду: из текст программы получается AST. То есть, из букв получаются узлы и ребра.
Буквы - низкая абстракция, максимальная универсальность, можно сложить что угодно (даже поэму).
Граф - более высокая абстракция, узкая специализация, только программирование (или даже на конкретном языке программирования).
Ну очень спорный вопрос насчет того, что большие проекты тормозят... Да, до недавнего времени я страдал от тормозящего редактора. Но точно так же с ростом проекта я страдал и при запуске приложения, и при отладке, и при компиляции. Настало время проапгрейдиться, все летает. То есть скорость работы IDE кореллирует со скоростью компиляции и отладки. Если комфортно отлаживаться и компилировать, то комфортно обычно и редактировать.
И моя разработка иногда подразумевает доступ к коду через слабый канал через терминалку. Причем иногда с совершенно произвольной операционки. Тут текст вне конкуренции.
Было уже. На большинство 8-битных машин при вводе кода, строка компилировалась до байт код для интерпретатора Basic-а. Соответственно, байт код и сохранялся на дискетах. Потом попробуй пренести на другую машину, хоть и с минимальным отличиям диалекта. Но там понятно, память - несколько десятков килобайт. Сейчас не вижу смысла, у текстового формата больше преимуществ.
А IDE стали медленные с тех пор как их начали писать на джаве. Раньше все работало быстро.
То что вы описываете называется визуальные программированием или no code. Как по мне эту штука громоздкая и создает излишнюю избыточность. Для новичков она удобна а для профи избыточна. Но я могу подсказать идею как это этого избавиться сделайте просто редактор котррый представить естественный язык яп например python или .net в двух видах: no code и code. Если хотите пишите мне и подключайтесь к моему проекту где я тоже использую графы но он более глобальный.
Да всё просто. Текстовый формат - это компромисс с очень хорошим балансом. Текстовый формат относительно удобен и точен как для человека, так и для машины.
Хороший вопрос. Есть над чем подумать.
Спасибо.
"сокращение выбросов CO2" - до этого момента думал что вы это всë всерьëз.
уже обсуждали эту тему. https://habr.com/ru/companies/karuna/articles/823710/
и https://habr.com/ru/articles/118525/ https://habr.com/ru/articles/96358/
Тенденция вроде в обратную сторону, от бинарных к открытым текстовым, чтоб проще и легче было людям а не компилятору и меньше завязываться на конкретные IDE. Basic уже вспоминали)
Согласен с комментаторами, что само представление кода как текстовых файлов имеет множество преимуществ. Однако, как я считаю, автор прав в том, что текстовые диффы совершенно неудобно, и для хорошего их отображения требуется хранить какую-то метаинформацию. Подобную функцию несомненно могла бы выполнять VCS, которая, конечно, не будет поддерживать все возможные языки на свете, но для не поддерживаемых все ещё можно показывать текстовый дифф.
так прыжок в другую репрезентацию стоит время в большом проекте, за проект по масштабу и сложности берем такую сложность(движок анриала не как проект, а сам движок, вот его надо открыть и продебажить например в дебагере и моч добавлять текст кода, чтобы в последствии его скомпилировать, не проект на анриале, а сам движок анриала), получается диф на какой-то репрезентации будет стоить - он не будет бесплатный со всеми вытекающими, и вот так получается что мы вернёмся к тексту, но вот задайтесь вопросом как поддерживать и дебажить такой масштаб кода и всё встанет на свои места с репрезентациями, это нужен сервер мощный, просто так уже не открыть на супер крутом редакторе что-то мне подсказывает
тоесть совсем другой подход нужен около того от чего всё начиналось с пересмотром лучших практик иначе можно потерять просто управление мегабольшого проекта и пользоваться текстовым редактором(блокнотом по-сути) что тоже возвращает к истокам это прямо следствие из сложности отрисовки и всех операций с мегапроектами-мегакодовыми базами
у меня так получилось, но я пока не понял почему нужен именно в редакторе AST
Скрытый текст
тут просто в файле пробелы поставлены сохранён специально под ошибку(отьедает чуть меньше, у меня подтюнена работа с памятью)
если для навигации то можно создать таблицу, да и под навигацию кв парсится из текста почти идеально
вот например сессия дебагинга тут да придётся разбираться, а с текстом (подсветка/навигация/несколькофайлов тут можно придумать более удобные вещи вроде как мне кажется). дебаг сессия это уже dap(debug adapter protocol) в теории его можно переписать на текстовый человеческий и снять с Node.js тем самым снять часть нагрузки при отрисовке этого режима, но тут уже надо быть професионалом кмк) режим со всеми вытекающими на сколько я углублялся
Да всё банально совершенно. Хранение кода в виде текста - самый простой способ хранения и работы с кодом в виде текста. Далеко не весь код сейчас хранится в текстовом виде - всякие ресурсы (а это, между прочим, тоже часть кода) хранятся в различных binary-форматах, удобных для представления конкретных ресурсов. А, скажем, Oracle Form Builder хранит текстовый код в своем формате (.fmb) и, хотя остается возможность сохранить его в текстовых файлах, это сильно затрудняет использование ПО контроля версий - нет возможности сравнения файлов и манипуляций при слиянии нового кода из разных версий в случае возникновения коллизий. В случае частичного нарушения структуры, текстовый файл можно с той или иной степенью сложности восстановить вручную. Ну и, наконец, с текстом мы работаем на уровне файловой системы ОС и можем загрузить код в любую среду (максимум, сделав какой-нибудь encoding) а для работы с другими форматами необходимо будет специализированное ПО. А в конечном итоге мы всё равно должны увидеть текст.
Есть вещи, применение которых основано не на логическом размышлении, а на практическом опыте. И применение текстового представления кода - одна из таких вещей...
Использование расширения имени файла с тремя буквами (а не двумя) это тяжёлое наследие <s>царизма</s>DOS. Чувствительностьк регистру имен файлов - тоже. Ни в одной нормальной OS такого нет и быть не может.
Идея использовать какой-нибудь специальный формат для исходников вместо просто текста не нова. В эпоху античности так работал, например, Delphi. Но широкого распространения такой подход не получил, потому что с бинарным файлом в спецформате Вы отказываетесь намертво привязаны к аппликации, которая этот формат понимает. А если завтра лицензия закончится, например? Или придётся перейти на какой-то дистрибутив Linux, на котором эта аппликация не ставится? Мало ли что может быть в жизни!
Перенос класса или функции в другое место с автоматическим изменением всех упоминаний отлично работает и с текстами. Например, Eclipse для Java.
Права доступа и другие аттрибуты Вам понадобятся и с бинарным файлом.щ
С бинарными файлами знаете как - один бит испортился, и каюк. Можно, впрочем, использовать и просто текстовый файл со специальной разметкой, но практика показывает, что рано или поздно у Вам будет соблазн поменять его вручную, и целостность файла может нарушиться.
Смысл моего комментария был в том, что победить логикой практику очень сложно. Как правило, всякие хитроумные решения (и это речь не только о способах хранения кода) иногда находят свою теплую/удобную/коммерческую нишу и живут там, в специализированных условиях. А в широкой практике используются самые простые, доступные, желательно бесплатные инструменты. Благодаря текстовому представлению кода мы можем писать его хоть в простейшем (а может, даже, и самодельном) редакторе, а генерацию (трансляцию, компиляцию, линковку, что там ещё?) бинарки запускать из командной строки, из batch-файла, из другой программы...
Практика - критерий истины.
Перенос класса или функции в другое место А история в гите сохраняется?
Права доступа и другие аттрибуты В БД они мне не нужны. Точнее нужны, но другого уровня.
Один бит испортился В TCP поправили лет 50 назад
3 Не все пользуются гитом а на историю многим просто начхать. Если кому-то нужна история, контроль версий, бранчи и прочие чудеса, он использует соответствующие инструменты с текстовыми файлами и не парится
4 Кому нужны какие-то права доступа - пользуется соответствующим инструментарием
5 То есть, туда ещё и из криптографии чего-то засунуть? Поверх уже существующей при записи на диск... И опять понеслось - программы восстановления, мониторинга и прочее... Бэкапы надо делать вовремя...
Кстати, когда в один файл два человека вносят изменения в код, это не проблема хранения кода, а это проблема двух людей. Никакое специальное хранение файлов не сможет разрешить коллизию "чей код главнее".
Когда среда разработки падает при загрузке больших проектов, это, как правило проблема багов в IDE - процесс загрузки проекта не должен зависеть от его объема (разве что с ростом времени), если среда падает - это баг. А от багов не защищает никакой формат хранения кода - только усугубляет...
он использует соответствующие инструменты с текстовыми файлами и не парится
Ну я бы не сказал не парятся. В том же гите нет переименований, перемещений. Ну и про функции тоже правильно сказано. Вот я последний месяц засучив рукава перетаскивают код из фронта и бэка АРМа в библиотеку, чтобы действия, которые сейчас прибиты гвоздями к АРМу могли выполняться из отдельно по событию или таймеру. Код во многом не меняется, а место его хранения - довольно сильно. И никакой истории мне гит не дает. Не "вы перенесли 2000 строк кода и поправили 10", а "удалено 2000 строк добавлено 2000 строк". Мне ужасно жаль ревьювера.
Так это претензии к Гиту, а не к способу хранения кода. Я Гитом не пользуюсь просто по причине его сложности во всём. Казалось бы, простая идея - контроль кода и организация доступа, а наворочено столько, что за деревьями леса не видно...
То есть "не парятся" имелось в виду не простота использования, а м-м... наличие какого-то решения. Может быть для вашего случая подошёл бы какой-то другой способ.
Посоветуете другую VCS, которая следит за тем как ездят функции по проекту?
Да я не собирался ничего никому советовать - должность у меня не та...
Так раз вы так уверенно утверждаете, что
Так это претензии к Гиту, а не к способу хранения кода
я думал у вас есть богатый опыт жизни с инструментами к которым нет таких претензий.
По факту моя претензия именно к способу хранения кода. Код состоит из классов, процедур, функций, циклов, переменных. А для анализа изменений в нем рассматривается как текст. От этого и возникают описанные мной проблемы.
Другое дело что я не верю в способность автора (и кого угодно) сделать наглядный дифф на графе, но это уже совсем другая история. Надеюсь что я ошибаюсь.
Да разве ж это я утверждал? Это вы об этом рассказали в комментарии - "...и никакой истории мне гит не даёт"... )
Ответ мой был в контексте статьи, а не обсуждения систем контроля версий. В том смысле, что какой формат хранения кода ни выбирай, набор функций той или иной VCS от этого не зависит...
Ну и, наконец, может я и не понял, но я думаю, что задача распознать действие "вы перенесли 2000 строк кода и поправили 10" весьма нетривиальна и потребует специализированного редактора - и опять-таки неважно будет код в текстовом виде или в каком другом. Возможно в каком либо структурном виде это будет проще реализовать, скажем, не нужен будет парсинг. Но тут вступает другое правило - нежелательно вносить в задачи общего характера узкоспециализированные инструменты...
Я, чисто по приколу, ) спросил Copilot на предмет существования таких VCS. Он мне назвал несколько инструментов, но оценить их я, естественно, не могу...
Потому что код пишется для человека, а не для компьютера.
Сколько бы у вас не было ядер и планок памяти - они закончатся, когда вы откроете достаточно большой проект.
Ни разу такой проблемы не возникало, работаю с достаточно большими проектами.
Все становится намного хуже, когда вы работаете в команде. Мы используем специальное программное обеспечение для слияния изменений, но оно работает ужасно
Вы точно не пытаетесь решать несуществуюшую проблему? Современные системы контроля версий работают приемлимо.
А скажите, пожалуйста, на каком Вы языке пишете и сколько сейчас оперативной памяти?
Свежий пример решаемой проблемы: сегодня разбирался в чужом коде, и нужно было понять, зачем добавили кусок кода. Залез в историю - 3 годаназад перенесли из другого файла. Приходится загружать тот коммит и снова искать по истории. А на днях ревьювил небольшой рефакторинг. Класс разбили на два и немного переименовали переменные. Нормально разобраться, что произошло - 2 часа.
Typescript, Python, Go. Прямо сейчас проект, в котором около 15к файлов открыт в IDE, локально поднят тестовый кубернетес кластер и открыто неcколько браузеров по 50-100 вкладок в каждом. Потребление памяти меньше 32ГБ, половина которой это буферы и кеш. На борту 64ГБ, хотел изначально брать 128ГБ, но решил, что нафиг пока не надо.
Память сегодня копейки стоит, чего из-за нее переживать?
Есть проекты где файлов на порядок больше, есть где на два. 128gb ram 400$ стоят, не прям уж копейки. Найти ноут, куда это добро засунуть, весьма сложно.
Ноут, это недокомпьютер, зачем его в пример приводить? Работать с проектом на 1500к файлов локально на ноуте? Не смешите меня. Даже если человек вынужден работать на ноуте, такой проект будет развёрнут на мощном сервере.
128gb ram 400$ стоят
Это много? К тому же, как я сказал, у меня всё ПО в 16 умещантся, плюс 16 под буферы и кэш. Покажите мне проект, где у вас IDE 128 гигов сожрёт и компания, которая такими проектами ворочает не может заплатить за озу стоимость нескольких часов работы квалифицированного разраба.
Я бы рад не использовать ноуты, но если посмотреть на любую крупную компанию - то почти все сотрудники используются ноутбуки. Потому что безопасность, комплаенс, политика, SOC2, ISO, командировки.
Это все очень тупо, но таков мир.
400 баксов не много, но и не копейки.
У меня IDE съедает 64Гб. Но это открыто несколько солюшенов, две ветки. Файлов больше миллиона, но это включая всякие node_modules.
Файлов больше миллиона, но это включая всякие node_modules.
Ненене, Девид Блейн, я считал только файлы "моих" исходников, node_modules и прочие кеши отфильтровал )))
Я бы рад не использовать ноуты, но если посмотреть на любую крупную компанию - то почти все сотрудники используются ноутбуки. Потому что безопасность, комплаенс, политика, SOC2, ISO, командировки.
Да, я понимаю, что многим приходится страдать. Когда я использовал ноут по необходимости, мне выделяли норм машину в офисе/датацентре, где и был развёрнут проект, IDE работала удалённо с ним.
del
ошибся на порядок
Есть визуальное программирование, но что-то те, кто пытались на нём создавать большие проекты без единой строчки кода в текстовых файлах, не особо довольны таким экспириенсом)
хранит AST кода TypeScript
То есть теперь надо AST преобразовать в Typescript, а потом в javascript, потом отдать его интерпретатору для получения машинного кода. В каком из этих мест вы видите снижение выбросов CO2?
Но что если мы распарсим код в AST, присвоим уникальные идентификаторы блокам кода,
Каким блокам кода?.. Каждому? То есть, допустим, функция получает свой идентификатор, каждый условный оператор получает свой идентификатор, каждый цикл, в том числе на всю глубину вложенности? Теперь, допустим, поменяли символ в какой-то строчке в коде, где, допустим, есть десять уровней вложенности, получается, что все уровни получат новые идентификаторы? При этом идентификаторы будут скорее всего длиннее, чем сами операторы — нам же нужна уникальность при децентрализованной работе, нельзя же регистрировать каждый блок когда в каком-то центральном репозитории кода? То есть, меняем строчку, и, кроме прежнего кода с его идентификаторами, сохраняем новый код с его идентификаторами, получится, что каждое изменение кода потребует отдельной копии кода функции или даже файла с ней.
Далее, код, который в работе, не обязательно будет синтаксически верный, там может быть набросок с ошибками, но, если хранить код нужно в виде абстрактного синтаксического дерева, то сохранить код не получится до того, как он не станет синтаксически корректным, так получается?
Далее, код, который в работе, не обязательно будет синтаксически верный, там может быть набросок с ошибками, но, если хранить код нужно в виде абстрактного синтаксического дерева, то сохранить код не получится до того, как он не станет синтаксически корректным, так получается?
Вообще говоря хорошие парсеры парсят любую последовательность символов, включая совсем ошибочный код (будет просто много узлов с пометкой error). Так что теоретически проблема решаема, но зачем?
Ага. Напоминает проблему топологической сортировки в параметрических CAD. Грубо говоря, если добавить/удалить грань где-то в середине истории, CAD потом не всегда может понять к каким элементам применялись последующие операции, потому что множество вершин изменилось.
Тут будет что-то похожее. Цикл, в который добавили новое условие - это новый блок кода? Должен ли у него быть новый идентификатор? А если потом убрать из него кусок кода? Рано или поздно возникнет своеобразный корабль Тесея: в блоке ничего не осталось от оригинала, но идентификатор все тот же. А если назначить новые идентификатор - то как делать дифф между двумя деревьями где все идентификаторы разные?
Кажется, что люди не договорились о формате текстовых файлов (BOM, конца строк, кодировки и т.п.). Но на мой взгляд это только кажется. Сложно придумать пример, где люди договорились бы лучше. В мире создано порядка 10^15-10^20 текстовых файлов. И несчастный vim/Notepad++/sublime и сотня других редакторов позволят корректно работать с подавляющим большинством из них.
Уже не один раз предлагались подобные подходы, но никогда не взлетало.
Существует много вариантов: UTF-8 или UTF-16; с BOM или без него; CR, LF или CRLF; little-endian или big-endian — это лишь самые популярные варианты. К сожалению, мир не смог договориться об одном стандарте, поэтому то и дело приходится сталкиваться с проблемами: испорченные диффы, ошибки в тулзах, проблемы с копированием, нечитаемый текст на фронте.
Настолько давно не видел проблем именно из-за кодировки файла, что даже не помню точное название используемой сейчас. Всё работает по всех текстовых редакторах.
Но если мы говорим о форматировании, для меня это выглядит странно: почему мы должны заботиться о пустых строках, табуляции или пробелах, ограничениях по длине строк и других несущественных деталях?
Существенные - мы код пишем, чтобы его можно было позже комфортно читать людям, а не только машинам.
Еще один уровень абстракции между кодом и хранилищем. Зачем нам имена файлов и ограничения с ними связанные?
Нет никаких ограничений, имена файлов подчеркивают их контент.
А еще мы работаем на разных файловых системах, и они предоставляют нам разные функции. Чувствительность к регистру или нет? Жесткие и символические ссылки. Права доступа. Атрибуты. Все эти особенности не имеют отношения к нашему коду, по крайней мере, вы обычно не можете прочитать о них в спецификации вашего языка.
Такие проблемы возникают иногда, но не настолько часто, чтобы ради них менять всё.
Я упомянул проблемы, с которыми сталкивался лично. Каждый раз мне приходилось тратить время на погружение в особенности файловых систем и поиск обходного пути. И далеко не всегда результат удовлетворял меня, чаще решение представляло собой костыль.
Поэтому собрались разработать свой стандарт, который конечно же будет поддерживаться везде.
Однако это еще не все, парсинг происходит много раз и после загрузки: при изменении кода, при переключении веток, при компиляции.
Теперь самое главное - почему вы решили что парсинг занимает основное время компиляции? Есть еще семантический анализ, генерация кода, оптимизация, которые работают намного медленней парсинга. Как правило, хороший парсер работает молниеносно и совсем не является бутылочным горлышком. Логичней тогда уж оптимизировать инкрементальную компиляцию или систему отображения кода, с которым в данный момент разработчик работает непосредственно.
Каким бы эффективным не был парсер, но он загружает ваш процессор и память. Сколько бы у вас не было ядер и планок памяти - они закончатся, когда вы откроете достаточно большой проект.
То же самое может случиться с вашим AST представлением. И только одному парсеру на самом деле тяжело будет заполнить всю память.
Все становится намного хуже, когда вы работаете в команде. Мы используем специальное программное обеспечение для слияния изменений, но оно работает ужасно:
Когда вы перемещаете класс в другой файл — это новый класс.
Когда вы перемещаете функцию на несколько строк вверх или вниз — это новая функция.
Когда вы меняете имя любого идентификатора — у вас появляются изменения во всех файлах, которые его используют.
Это не проблема систем контроля версий, которые работают с текстами. Теоретически можно придумать умный дифф, только почему-то мало кому это нужно. В AST-подходе не будет никаких сущностей, которые можно именовать?
Когда два человека вносят изменения в один файл — возникают конфликты.
А это относится к представлению кода? В AST-подходе конфликты будут сами решаться чудесным образом?
Очевидно, нет. Это неудобно, ненадежно и может привести к несогласованности.
Совсем не очевидно как и то, какой подход может быть лучше.
Мы сможем сэкономить на размере данных если использовать enum для ключевых слов.
А какая экономия получится? Вот код в очень больших проектах занимает до нескольких сотен мегабайт, в малых проектах это мегабайты. Реально имеет смысл экономить, особенно учитывая что всякие ресурсы могут весить на порядки больше?
Чтение из локальной БД будет сравнимо по скорости с чтением с диска.
У хороших парсеров для языков без сложных конструкций (таких как C++) скорость парсинга не сильно медленней чтения файлов с диска.
Форматирование AST должно быть быстрее парсинга.
Должно быть? Настолько быстрей, вы делали замеры? Стоит ли овчинка выделки?
Я представляю это как нечто вроде режима исправлений в Google Docs: некоторые части заменяются, другие перемещаются куда-то или удаляются.
А можно будет откатиться на одну из предыдущих версий при необходимости? Посмотреть изменения с нескольких "коммитов"? И другие вопросы актуальные для версионирования.
Производительность и сокращение выбросов CO2
Пока не верится.
Согласованность между вашими инструментами
И рассогласованность со всем остальным.
Я думаю что все упрется в редактор. Надо придумать редактор для этой БД с AST. Что само по себе - уже проблема на миллион, а еще же переучить всех надо будет. Без редактора придется вынимать все в текстовые файлы и редактировать там, а от этого потеряется, например, понимание что перименовали а что перенесли.
Но плюсов - даже больше чем ты пишешь:
если код уже в ast - сильно упрощается метапрограммирование (см лиспы)
Редактирование контента в Cms, конфиги, перевод строк в ресурсах, всякие bpmn-движки - уезжают просто в код. Кстати, с этой ниши можно и начать - сделав некий универсальный редактор ast простого языка
Код и данные можно хранить вместе. Релизить контент в cms вместе с кодом, который его рисует, например
Код можно сериализовывать передавать по сети, например как запросы в БД
Сильно упрощается инкрементальная компиляция - видно вплоть до функции что менялось, не надо сравнивать мегабайты
Короче ниша под это точно есть, и смысл есть. Просто больно радикально, и слишком много чего надо пересоздать и перепридумать.
Помню в начале нулевых был такой инструмент Rational rose кажется, где вообще код писать не нужно было(по крайней мере большую его часть), проект рисовался в UML диаграммах, потом это все одним кликом переводилось в кучу Java файлов с заглушками, но "архитектор " в теории не имел с ним дело. Оставалось только заполнять реализацию методов. В теории опять же можно было бы развивать идею и далее рисовать алгоритмы и тд. Но не взлетело, оказалось проще открыть редактор и накидать код.
Ох, что вспомнили... Он был даже не просто ужасен, а чудовищен.
Я имею в виду для программистов, которым потом приходилось поддерживать это нагенерированное из UML «решение». Как вспомню, так аж глаз дёргаться начинает, а ведь мне всего однажды довелось.
Я думаю, что сегодня ИИ легко справится с UML. Мне даже кажется это для них предпочтительнее текста.
По крайней мере, мне они вполне приемлемый код генерят из диаграм стэйт машин - прямо с пиксельной картинки. Кайф!
UML весьма хорош для анализа проблемы и построения общих семантических моделей, которые не всегда можно эффективно переводить в код, поскольку для этого потребуется отказаться от упрощения нотации.
Генеративные модели действительно отлично генерируют что бы то ни было. А я вообще-то о поддержке говорю. Одноразовый код, который только пишется, и потом никем никогда не читается и не изменяется, очень мало кому в реальной жизни нужен.
И уж поверьте, поддержка нагенерированного роботами — это куда большая боль, чем написанного любыми кожаными мешками, если у них есть хоть какой-то опыт и чувство стиля.
Хочется эффективного хранения - нужно писать на Forth.
В 1С реализовано. Без конфигуратора хрен исходники посмотришь. Возможно у саперов, дайнемиксов аналогично, но не точно
А, вот, в версии 7.7 можно было модули иметь в виде внешних текстовых файлов ))
Да ладно, пакуют в известный формат, работаешь потом все равно с теми же исходниками. Хотя сравнение на уровне функций реализовано, но внутри модуля. Перенеси функцию из формы в общий модуль и вот уже новое обновление поставщика несмотря на живую трехсторонку будет показывать появление функции в ОМ и исчезновение в форме, а не перенос.
Мы пишем программы текстом, потому что это наш исходный код - это не код, а литературный текст, произведение искусства.
Мы же создаём в своем коде смыслы, а не бесмысленные АСТ.
Да и вообще, с точки зрения эволюции, для гетерогенных коммуникаций наиболее живучи самые простые и самые общие способы передачи информации.
Не случайно же, после долгого пути развития программных языков - от мышинного кода, ассемблера, через си си, джавы и шарпы, мы в итоге пришли к естественным языкам управления ИИ.
странно что ещё не упомянули https://www.jetbrains.com/mps/
Редактируй себе прямо в AST сколько хочешь. Пока до серьёзных рефакторингов не дойдёт.
В будущем мы будем хранить только промт. Например:
Создай простой калькулятор на Python с графическим интерфейсом.
*Поддержка операций: +, –, , /.
Интерфейс на tkinter, кнопки, поле ввода и вывод результата.
И да, в текстовом формате. И никакого кода. Только декларация того что нам нужно.
Предлагаю в качестве мысленного эксперимента представить статьи на хабре и комментарии к ним в виде голосовых сообщений. Представить как будет реализован поиск, цитирование, ссылки, вложения и т.д.
Вот примерно так же вижу идею с хранением исходного кода в чем-то отличном от текстового файла.
Боюсь, что прикручивать crdt и кроиптографию постфактум будет сложно - об этом надо думать сразу. У меня в планах сделать такую систему контроля версий на базе своей децентрализованной субд CRUS-DB. Вот вам пара тизеров:
В этих примерах, правда, используется хранение плоского текста в виде графа. Переход на AST конкретных языков ещё в планах.
CRDT для дерева и CRDT для текста сильно разные вещи, там разные операции. Многие CRDT для текста используют внутри дерево, но это немного другое.
В вашем примере мне кажется используется CRDT для текста, например, я вижу там слово class, но в моем понимании, такого слова не должно быть в коде, должен быть объект вроде { type: NodeType.class, visibility: VisibilityType.public, name: 'App', members: [...]}. Тогда изменение visibility не влияет на изменение name и их можно мержить по Last Write Wins. Хранить name CRDT text на мой взгляд избыточно, потому что если один разраб изменил название на UserProvider, а другой на UserFactory, то нет смысла это мержить в UserProviderFactory, нужно подсветить конфликт и пусть договариваются сами.
Автоматический мердж - это круто, но иногда он может спрятать лишнее.
Про криптографию не понял, зачем она тут?
Как уже верно отметили выше, вы придумали IBM VisualAge.
У меня есть, например, репозиторий VisualAge с разработками того времени (20 лет назад) в виде одного файла .dat размером сколько-то мегабайт. Сами можете оценить полезность этого наследия в современных условиях.
Хотя в моменте это было довольно удобно.
Старожжилы припоминают концепцию Фантом ОС. Это было про другое, но по факту там код жил, распространялся и сапортился в формате байткода.
Не знаю, я застал времена токенизированных исходников (бейсик, ассемблер), и вот совершенно не стремлюсь к этому возвращаться. В данный момент такие исходники тех лет превратились в полутыкву, современными программами их так просто не открыть.
Так код в виде текста редактировать проще. Когда пишется код, он не воспринимается как синтаксическое дерево. Тут ведь первичен способ ввода, а не хранения, и пока что такой подход создания кода для человека является оптимальным. Другое дело - код действительно можно хранить в виде дерева, но зачем? Тем более с новой версией языка нужно расширять поддержку новых узлов. Такими штучками страдали в 90 и 2000е, когда каждый считал своим долгом написать свой протокол в виде ASN.1 в BER кодировке. В итоге решили что всё таки xml а теперь json гораздо приятнее для обмена и дебага
На самом деле в этой идее есть смысл, но не там: сейчас мы пишем код текстом, потому что сейчас так удобнее всего, а вот в будующем может быть будем писать образами и аналогиями, рассказывая о них какому-нибудь ЧатуЖПТ, и уже он будет выделять из себя текст программы, скармливать его компилятору и показывать программисту готовый вариант.
Или сразу выдавать результат бинарником под конкретный процессор, без промежуточного текста.
Но тогда и деревья с графами никакие никому нужны не будут.
Прикольная статья и идея) Мне кажется, уже сейчас чисто технически на базе гита можно что то такое замутить без принципиальных трудностей если в промежутке останется тот же текст, как после старого препроцессора с++
Но давайте мыслить шире - человек и язык, программист и язык программирования. Человек и текст - общение, литература, документация, "сралки на форумах" и тепе. Программист и яп - модули, стандарты, компиляторы, программы, чистый код и паттерны. Далее - человек и поэзия) Что этому может соответствовать в программировании? Ну разве что творения индусских мастеров программного слова, где в каждой строчке они пытаются отложить хоть песчинку кирпичика, из которого потом сказочно возникнет домик, в котором будут жить их шивы)
Я к чему. Программирование, несмотря на то, что потенциально способно воплощать в реальность физически нереализуемые сущности, навроде многозадачности и различных виртуальностей, до сих пор выдаёт за прорывы открытия и воплощения прошлого. Ну, к примеру, кластер, шина сообщений и энтерпрайз шина и всё такое, интегрированная архитектура.. Поэтому если и рассуждать о будущем способе хранения программ, то следующая станция должна зеркалить поэзию, сочетающую текст и образы, им навеиваемые, что кардинально повышает количество бит на символ. И тут не обойтись без ИИ в роли библиотекаря, переводчика и сантехника) Представляете - it парубок, выпив утром кофе без кофеину на ячменном солоде, выходит на терасску домика с видом на пересохший Дон и декламирует - налево иди и смерть там познаешь, прямо пойдёшь деву найдёшь, направо ходить не нада нам ни за что. Ну а уж ИИ соотнесёт образы с эксепшенами, удовлетворением спроса и аспектами безопасности. И никаких модулей текста, заметьте)
сокращение выбросов CO2
"Не верю!" (с) Не верю, что эта повесточка здесь реально кого-то колышет. Выглядит абсолютно неискренне.
Сейчас эта штука может разбирать простой код в граф, сохранять его в базу данных, а затем загружать и форматировать как исходный текст.
Т.е. для редактирования всё равно в текст обратно переводить надо? Получается чисто технический формат хранения? Другие приимущества, например сравнение диффов, тоже кажутся сомнительными.
Посмотреть код в виде графа может быть и полезно. Но такие вещи уже есть, особенно полезно графы зависимостей. А вот зачем имеено хранение в виде графа, если редактирование всё равно в тексте - непонятно
Я работал с ЯП, который хранит сорцы в бинарниках - CAVO. И это крайне не удобно, что ты завязан на свою IDE и её ограничения.
Элементарный кейс - когда нужно перенести код между проектами. Там это называется модуль. В одном модуле расположено множество типов. Единственный способ это сделать - сделать импорт/экспорт модуля.
И таких кейсов было много.
То есть если уж так делать, то нужно как минимум все их делательно продумать, чтобы этим не больно было пользоваться.
Стремный символ в начале файла
Гуглил и не нашёл. Видимо, имелся в виду "cтрёмный символ"?
Почему мы все еще храним код в текстовых файлах?
Неправильный вопрос. Правильный - почему мы всё ещё программируем в текстовом виде?
Нейросети уже потихоньку дают это делать по другому (но всё ещё отдавая текстовый код), были попытки в low code и no code, но всё это пока не то.
Раз уж затрагиваете большие проблемы, то копайте до сама начала, не останавливайтесь на полпути.
Это не риторический вопрос. Я знаю, так исторически сложилось, но... почему мы продолжаем использовать текстовые файлы?
Да! Это очень интересный вопрос. Всегда им задавался. Крайне неудобно. Да. Можно посмотреть, прочитать, исправить, дописать и "скормить" компилятору.
Вы можете сказать, что это очень простое решение: что видишь, то оно и есть. Но мы имеем дело с несколькими слоями абстракции, а все абстракции текут. Это приводит к ошибкам, запутанным диффам и проблемам с производительностью.
Тут такое дело. Всегда есть выбор: либо явное описание работы программы в текстовой форме, либо некое промежуточное хранение. Выбор, собственно, в чём? В надёжности! Если промежуточное представление "потечёт", то с программой придётся попрощаться. Если это, например, база данных, то у СУБД может быть механизм восстановления.
Безусловно, БД программного кода очень нужна. Была бы такая БД, не над было бы специально (!!) создавать всевозможные системы управления версиями (включая и Git), БД сама следила бы за всеми версиями.
Давайте углубимся в искусство хранения кода в виде текстовых файлов.
Давайте. Но... позже. Надо ещё статью прочитать и комментарии к ней. А ещё и подумать...
Для начала, надо понять, что существенная часть проблемы — это проблема кодировка. Точнее, отсутствие системного решения этой проблемы. Во времена MS DOS текстовыми файлами считались файлы, не содержащие символов из самого начала таблицы ASCII. Дело в том, что там располагаются всякого рода управляющие символы. Если их нет, то текстовый файл правильно открывается в "хорошем" текстовом редакторе. А "плохие" редакторы норовят вставлять эти управляющие символы в текст, что этот самый текст ломает. При системном решении проблемы кодировок, у нас было бы чёткое разделение на классы символов. И, вообще, была бы весьма обширная классификация символов, в особенности, управляющих.
Ещё. Нам в языках программирования приходится мириться с тем, что некоторые операции требуют нескольких символов. Например "<=", ">=", "===". В нормальной ситуации (при системном решении проблемы кодировок) для каждой такой операции существовал бы отдельный символ. Это, кстати, упростило бы лексический анализ и сделало бы АСД очень хорошим способом промежуточного хранения.
Следует, также, заметить, что нас имеется проблема с понятием текстового файла. Если мы возьмём, скажем, файлHTML или файл JSON. Это, ведь, тоже будет текстовый файл. Но его надо ещё интерпретировать. Никто не мешает сделать так, чтобы был какой-то способ промежуточного хранения, а текст был бы одним из возможных представлений. Но это поднимает вопрос о том, а как следует, вообще, создавать программы. Я могу себе представить реализацию программы на некотором высокоуровневом языке программирования в виде некой мета-программы, выполнение которой приводит к формированию кода уже на низкоуровневом языке программирования. (Что-то вроде рендеринга. Программного кода. По идее LLM со своими кодерами и декодерами как-то воспроизводят эту конструкцию.) При этом, эти два языка могут существенно отличаться по своей концепции. Кроме того, здесь фигурирует ещё и третий язык программирования — язык самой системы, которая производит описываемую здесь трансляцию.
К сожалению, мир не смог договориться об одном стандарте, поэтому то и дело приходится сталкиваться с проблемами: испорченные диффы, ошибки в тулзах, проблемы с копированием, нечитаемый текст на фронте.
А в чём проблема? Почему нельзя сделать нечто очень важное и полезное?
Действительное решение задачи заключается в том, чтобы определённым образом упорядочить символы. Например, должен быть единый для всех символ конца строки. Но, тогда, очевидно, возникнет потребность в наличии не только символа начала строки, но и всех других начал и концов. Например, символ, отмечающий начало идентификатора, и символ, отмечающий его конец. Точно такая же разметка (!!) касается и знаков операций, и разного рода литералов. Привычное нам текстовое представление — это результат вот такой невидимой глазу разметки, и мы в редакторе должны иметь дело уже с результатом этой разметки, но сам исходный текст должен содержать и все промежуточные символы.
С точки зрения хранения программного кода, целесообразно хранить тройки: собственно, отдельную инструкцию, комментарий к ней и элемент, описывающий связь данной инструкции с другими. Впрочем, здесь напрашиваются и RDF-тройки, которые описывают предикаты: объект, субъект и функцию.
Но если мы говорим о форматировании, для меня это выглядит странно: почему мы должны заботиться о пустых строках, табуляции или пробелах, ограничениях по длине строк и других несущественных деталях?
Вообще говоря, это пользователь должен определять, как ему удобнее. Внутреннее представление программного кода не должно зависеть от того, как этот код отображается.
Слава всем богам, мы не добавляем информацию о предпочитаемом шрифте и цвете в нашу кодовую базу, я точно не хочу читать код в Comic Sans.
Главное, чтобы шрифт позволял хорошо различать "1". "l" (L) и "I" (i). Например.
Еще один уровень абстракции между кодом и хранилищем. Зачем нам имена файлов и ограничения с ними связанные? Разве это удобно использовать двухбуквенные расширения для указания используемого языка?
Проблема ещё и в том, что расширения файлов, с одной стороны, могут нам говорить и о том, что файл текстовый (TXT), и том, что файл содержит программу на выбранном языке программирования (C, CPP, PAS, PY, JS, PHP). Да, мы знаем, что это всё — текстовые файлы, но для имён файлов нужно строгое единообразие, а не смешение формата представления и соотнесения с обрабатывающей программой. Здесь напрашивается иерархия: на верхнем уровне у нас имеются каталоги C, CPP, PAS, PY, JS, PHP, а на нижнем — TXT, BIN. А ещё нужен промежуточный уровень, который осуществляет отображение верхнего уровня на нижний.
А еще мы работаем на разных файловых системах, и они предоставляют нам разные функции. Чувствительность к регистру или нет? Жесткие и символические ссылки. Права доступа. Атрибуты. Все эти особенности не имеют отношения к нашему коду, по крайней мере, вы обычно не можете прочитать о них в спецификации вашего языка.
Да. Давно надо было разобраться. Можно было бы предложить специальную файловую систему для хранения кода. Специальный раздел на диске. Для каждой задачи — своя файловая система.
Вот почему возникает потребность в БД: СУБД покрывает все эти проблемы, предлагая хранить все данные, например, в таблицах. (Можно было бы сделать простой SELECT и получить полный код. Например.)
Я упомянул проблемы, с которыми сталкивался лично. Каждый раз мне приходилось тратить время на погружение в особенности файловых систем и поиск обходного пути. И далеко не всегда результат удовлетворял меня, чаще решение представляло собой костыль.
Тут ещё можно было бы "подумать и в сторону" самих сред разработки. Если, Вы, уж, знаете особенности различных файловых систем, то можно же предложить какой-то способ разложения программного кода на составляющие, чтобы обойти известные узкие места.
В спецификациях нашего языка задействовано много элементов форматирования: ключевые слова, скобки, разбиение строк, отступы. Возможно с ними проще читать код, но я уверен, что есть другой способ сделать код читабельным. Гораздо важнее эти элементы при парсинге кода компилятором и другими тулзами.
На сомом деле, это — прямое указание на то, что нужно (с)делать.
Мы хотим иметь дело не только и не столько с исходным кодом, сколько с его представлением, полученным на одном из промежуточных этапов трансляции. Чтобы с ним можно было работать как с визуальными компонентами: "двигать" по "форме". Чтобы их можно было его частично выполнять. Но это значит и то, что язык представления должен быть другой, не исходный. Вот, что важно понять. Мы должны перейти на уровень выше и использовать совершенно другой язык программирования, "исходники" которого уже "заточены" под задачи управления кодом — кодом на этом высокоуровневым языком программирования. А тот язык, который был вначале — это всего лишь одно из возможных конечных представлений/реализаций проектируемой программы. Задача — получить код на оконечном языке. (Таких оконечных языков может быть несколько.) Но сама разработка должна вестись на языке разработки, то есть — на языке модулей, компонентов и зависимостей.
Каким бы эффективным не был парсер, но он загружает ваш процессор и память. Сколько бы у вас не было ядер и планок памяти - они закончатся, когда вы откроете достаточно большой проект.
Это и обуславливает необходимость перехода к другому языку и, вообще, к поиску другого представления программы (проектируемой системы). И это же вскрывает застойное состояние индустрии разработки ПО: вместо того, чтобы создавать специализированные языки программирования (под конкретные задачи), берутся существующие языки и делаются монструозными. Когда всё-равно, на чём писать. Отсюда и проблемы с производительностью.
Почему мы все еще храним код в текстовых файлах?