Comments 213
Очевидно, нет. Это неудобно, ненадежно и может привести к несогласованности.
Но... почему?
Почему именно текстовый файл, я легко отвечу: это естественный для меня формат, он хранит код именно так, как я его буду читать. И я его могу прочитать абсолютно любым инструментом, который у меня есть под рукой, вплоть до голой ОС.
В то же время преимущества каких-то других форматов для меня не очевидны. Удобство? Нет ничего удобнее нативного для меня формата. Надёжность? Текстовый файл надёжен настолько, насколько надёжен носитель, на котором он записан. Лучше этого и не придумаешь. Размер хранилища? Да, в этом плане текстовый файл ни разу не оптимален, но... на моём компьютере весь текстовый контент едва ли займёт несколько процентов от самого маленького накопителя на 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 складывается из творений какеров, которые умеют вместо
print "hello world\n";
написать что-то типа
$<->^$2>>^&3@\#
и потом радуются как круто и непонятно получилось
Perl нечитаем? Это вы еще C++ >= 11 не видели )))
Потому что вы так привыкли.
На носителе не записан текст. Там двоичные данные, удобные ровно до тех пор, пока есть текстовый редактор.
И если для кода когда-то найдется формат по-лучше, чем обычный текст, то он может когда-то стать нативным. Напишут для всех осей нативный инструмент, которым вы его сможете открывать и читать так, как вы его написали.
Так это и про книги можно так сказать, что там не текст, а это всего лишь испачканные типографской краской стопки бумаги
Верно. Если вы язык, на котором она написана, не знаете, для вас это просто краска на бумаге.
нет... для меня это все так же текст, но только на незнакомом мне языке
Почему вы решили, что там текст? Возможно на другом языке эта краска на бумаге образует картинку.
вы сейчас имеете ввиду какой-то определенный язык или просто фантазируете?
Я про краску на бумаге. Вы сами привели такое сравнение.
Вот например, если в книге на всю страницу напечатать огромный QR-код. Вы тоже подумаете, что это текст?
Ну насколько я знаю, на свете нет людей, которые свободно читают в куар-кодах....
Речь идет о том, что люди пишут тексты буквами уже тысячи лет, а как они записаны, краской на папирусе, на бумаге, в виде ascii или в виде юникода, это не принципиально.... текст в книге и текст на экране монитора выглядят примерно одинаково... ну найдется другой формат, ну и черт с ним, главное, чтобы текст оставался текстом
Я об этом и писал, что мы привыкли выражать свои мысли текстом.
Хотя иногда удобнее для представления алгоритмов рисовать блок-схемы.
Связка:
двоичный формат хранения блок-схем;
нативный редактор блок-схем;
компилятор из блок-схем в машинный код;
позволяет программировать вообще без текста.
Просто исторически мы привязались к тексту. Но это не данность, и повод не искать что-то другое.
тем не менее мы вот сейчас с вами общаемся именно текстом, а не смайликами, не стикерами, и не картинками...
Связка:
двоичный формат хранения блок-схем;
нативный редактор блок-схем;
компилятор из блок-схем в машинный код;
позволяет программировать вообще без текста.
Вы описали пресловутый Дуракон (его инкарнацию от Тышова). Попробуйте на нем что-нибудь более-менее серьезное "напрограммировать", удачи вам
Я описал любой процесс программирования. Есть исходник, редактор и компилятор.
И если вы думаете, что графы (те же блок-схемы) хуже текста, то я вас расстрою.
А программировать что-то серьезное можно на любом полном по Тьюрингу языке. И всё равно как он выглядит. Хоть буковки, хоть стрелочки, хоть картинки.
В далеком 1993 в Москве была одна из первых в пост-СССР "компьютерных выставок". Там была куча стендов модного тренда - визуального программирования. Обещали, что через пару лет не будет никаких "текстов" - все будет в графах/блок-схемах. Так вот, пришла моя очередь расстроить вас...
программировать что-то серьезное можно на любом полном по Тьюрингу языке. И всё равно как он выглядит. Хоть буковки, хоть стрелочки, хоть картинки.
Да и плац можно подметать ломиком. Но если хотим, чтоб было быстро и чисто - берем метлу. а ломик применяется не чтоб было быстро и чисто, а чтоб "задолбать".
Но если хотим, чтоб было быстро и чисто
Вы упёрлись в то, что обычный текст это максимум, чтобы делать быстро. И не можете (или просто не хотите) поверить, что бывает что-то ещё.
Как в далеком прошлом, нужен человек, который придумает калькулятор, в то время, когда все пользуются счетами и говорят, что это удобно.
Графы безусловно хуже текста, потому что их выразительные средства более ограничены (хотя в смысле Тьюринга они могут быть эквивалентны). Представьте хотя бы простую рекурсию блок-схемой. Или макрос. Не говорю про самомодифицирующийся код.
(У меня ожидается публикация статьи примерно на эту тему в журнале "Информационно-измерительные и управляющие системы", после её выхода я, наверное, напишу и на хабре).
Кроме того, многие люди вообще в силу индивидуальных особенностей очень плохо воспринимают схемы. Хотя другие люди их любят.
Кроме того, многие люди вообще в силу индивидуальных особенностей очень плохо воспринимают схемы. Хотя другие люди их любят.
Ну, каждому инструменту своё место. "Схему электрическую принципиальную" можно выразить и в виде netlist'а (т.е. текстом), но в привычном виде с УГО она человеку понятнее. С визуальным программированием - наоборот.
Да есть уже достаточно давно такие языки, например GRAPH из среды SIMATIC STEP-7 для программирования PLC, приходилось писать на нем и я Вам скажу - это просто сущий ад. Основная, но далеко не единственная проблема - это очень низкая плотность информации на экране. Чтобы обозреть хоть сколь-нибудь сложную логическую конструкцию приходится постоянно крутить масштабирование, поскольку или ничего не лезет в экран и не видно логику, или шрифт становится мелким до полной нечитаемости. Хотя на простейших примерах все выглядит очень удобно, но это удобство исчезает напрочь когда начинаешь писать реальный достаточно сложный алгоритм управления.
После этого тот же C с его if и else, пусть даже "многоэтажными", кажется верхом совершенства. И даже всеми проклятый goto уже не выглядит таким уж извращением.
Там двоичные данные, удобные ровно до тех пор, пока есть текстовый редактор.
Т.е. удобные вообще всегда, когда у вас есть компьютер или что-то близкое к нему.
И если для кода когда-то найдется формат по-лучше, чем обычный текст, то он может когда-то стать нативным. Напишут для всех осей нативный инструмент, которым вы его сможете открывать и читать так, как вы его написали .
Т.е. вообще никогда. О чём же я и пишу :)
А как его обратно декомипилить из разобранного и обработанного графа? Там же все метаданные убираются... Или я что-то не так понимаю?
Сериализовать в текст? Этим постоянно все 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, бинарное хранение выпилили к херам, как и эту странную виртуальную машину
Вы предлагаете навернуть ещё один слой над уже имеющимся, т.е. добавить ещё одну точку отказа. Именно это мне больше всего не нравится в вашем предложении.
На хабре школьники пишут эссе на тему "Кем я хочу стать?" "Как я вижу будущее?"
Рекомендую ознакомиться с системами Графит-Флокс и Рапира+Школьница. Ещё можно погуглить Р-Технологии Глушкова. Такое ощущение, что Вы изобрели велосипед, но могу и ошибаться. )
А с какими аспектами этих систем Вы предлагаете ознакомиться? Краем уха смотрел когда-то давно на дракона, ничего особенного не заметил.
Как единое решение по представлению текста кодовой базы, БД хранения как "файловой системы" и формальных описаний входа-выхода, как элемента АСТ дерева. Там ещё, в ДРАКОНе есть версия ИДЕ Тышова (Мурманск), где комментарии к коду "иерархичны": ТЗ, решение, тестировщик, приемка. Несколько типов комментов. В целом ДРАКОН - малая часть Графит-Флокс. Но .. найти его описание не так просто в Сети к сожалению.
А еще заменить клавиатуру голосовым вводом а мышку глазным трекером !
Хранить код можно в любом виде. Редактировать будете в текстовом виде, как ни крути.
В итоге, некоторые "слои абстракции" просто меняются местами. Только, вместо моментального открытия текста, придется ждать, пока по диффам соберётся требуемая версия.
Хранить в CVS дельты или снепшоты - это перпендикулярный вопрос, я его не рассматривал.
Открытие текста в современных IDE не моментальное - он парсится в AST и потом рендерится на экран. Хотя бы для того чтобы раскрасить ключевые слова. Я предлагаю убрать первый шаг.
В продуманных IDE парсится фоном, а доступ к редактированию получаешь сразу.
Вам выше правильно написали. Подобные эксперименты уже были.
Если вас увлекает проект, продолжайте. Потом посмотрите на отклик сообщества.
А я вот если пишу код не в IDE, а в текстовом редакторе (да, мы существуем!) - как ваш подход может меня осчастливить?
То есть по сути разработчик вообще не заметит разницы, кроме случая, когда ему придется заглянуть в исходники не имея под рукой IDE? А не имея под рукой IDE как бы все.
Это типа что-то айфона? Вроде бы на устройстве музыки накачано, фильмов, фотографий, но вот просто так скинуть на произвольное соседнее устройство никак. И забрать тоже.
Я обожаю текстовые файлы. Если есть выбор, я и худлит пишу в маркдауне. SVG я делаю в текстовом редакторе. Если бы я знал плейнтекстовый формат для растровых изображений, я бы его использовал.
Если бы я знал плейнтекстовый формат для растровых изображений, я бы его использовал.
XPM же ж.
Есть еще Netbpm. Его прям даже не только X11 понимают...
Аналогично. Если надо написать что-то небольшое, то это летит в Телеграм в сохранённые сообщения. Если надо для чего-то большого, то создаю markdown - и вперёд. Не надо ничего выдумывать, если есть простые варианты. Максимум - потом в fb2 сконвертировать для форматирования.
Сейчас и музыку можно в текстовом виде писать: https://strudel.cc/workshop/getting-started/
Почему мы все еще храним код в текстовых файлах?
Потому что коду повезло, и он изначально хранился в текстовых файлах, а остальная часть человекочитаемых форматов стремится туда-же, типа конфигов, документов, и прочего. В большинстве своем код нужен как текст - при редактировании, при отображении на страницах, при ревью, текстовый поиск, и даже те же нейросети текст едят. Сейчас можно любой код любым редактором отредактировать, переслать в месседжере, править и писать терминальным редактором, генерить тупо текстом.
А в Вашем формате нужно для каждой версии каждого языка адаптер, который этот формат гоняет туда-сюда постоянно, и интегрировать везде - системы контроля версий, все IDE, все "блокноты", системы поиска и индексации, и тд 🫠
Ну вот адаптеров для каждого языка написано уже предостаточно: https://astexplorer.net
И они интегрированы во все современные IDE, даже в vim.
Вопрос уже неактуален. Сейчас осталось мало программистов, которые сами пишут код. Увы, люди плохо приспособлены для этой работы.
PS: вспоминаю как когда-то по таблицам переводил ассемблерный код в машинный, а после дыроколом переносил его на перфокарты... никто не верил моим словам, что скоро это станет ненужным.
Во. Значит вы застали те времена. Это хорошо.
И вы тогда совершенно правильно подметили, что прогресс должен пойти в сторону упрощения. Сложности вообще слабо выдерживают гонку с более простым решением.
И вот в ИТ, через несколько витков эволюции код дошёл до самой наипростой и эффективной формы - просто текстовый файл.
Почему же теперь, спустя годы вы изменяете себе и решили, что сложное решение по всем пунктам лучше?
Потому что эволюция по своей природе это путь усложнения. Те наипростые и эффективные формы десяткомиллионнострочного текста которые сейчас в проде, т.е. выиграли эвлюционный отбор - не читаемы уже в принципе, это наимертвейшее легаси.
Нет, их можно прочесть, но затратить на это надо будет усилий больше, чем на написание новых.
Текстовые файлы идеальны.
Они простые. Они человекочитаемые. Они абсолютно надежные. В них точно нет и не будет уязвимостей или скрытых данных. Они хранятся именно так как редактируются. Они не зависят от языка на котором вы пишите и поддерживают все языки, в том числе еще не изобретенные. Их можно поправить прямо в vi при необходимости. Они не зависят от платформы и правильно открываются и редактируются на всех платформах, в том числе еще не изобретенных.
А с размером можно как-нибудь смириться. Я думаю что человечество готово заплатить за этот оверхед в обмен на все плюсы текстовых файлов.
Индексы придуманы давно и индексация перестала быть проблемой.
Единственный комментарий, который отвечает на вопросы из статьи полностью и парирует каким-то неуместным аргументам в пользу усложнения инструментария. Текстовые файлы идеальны, созданы людьми для людей. Машины - это инструмент в руках человека.
Это как... Почему Мы до сих пор используем молоток для забивания гвоздей? Или... Почему Мы до сих пор используем лопату для выкапывания ям (грунта, чего угодно)? Или... Почему Мы до сих пор используем колёса для перемещения чего-либо?))) Есть же законы гидродинамики, сверхпроводимость и др. Можем в аэротрубе на работу перемещаться, как в футураме, на воздушной подушке грузы перемещать, к дорогам будем почти не привязаны... Крч... Пошёл писать статью на Хабре)))
Сомнительные аргументы. Помимо молотка, лопаты и колеса уже давно существуют шуруповерт, экскаватор и лодка/самолет/поезд на магнитной подушке. А кроме привычного нам текста есть схемы, таблицы и графический интерфейс. Тоже, кстати, созданные людьми для людей. И наскальная живопись появилась задолго до глиняных табличек с текстом. Удивитиельно, что многие разработчики настолько консервативны, что сходу и не задумываясь отторгают всё, что не связано с текстовым редактором, к которому когда-то были приучены.
А с размером можно как-нибудь смириться
Вот это самый странный аргумент у автора. 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 использует - крутая штука, легко прикручивается куда угодно.
Есть два варианта подсветки, второй "семантическая", которая как раз и требует полноценный анализатор кода. Второй вариант даже глазами увидеть можно, при открытии проекта, когда цвета через секунду другую перекрашиваются.
Даже не варианта а этапа. Обычно этапы такие:
Редактор загружает текст и показывает его в голом виде
Отрабатывает лексическаий анализатор и текст подсвечивается нужными цветами
Отрабатывает семантический анализатор и подстветка корректируется с учетом этого
А текст можно редактировать уже на первом этапе.
Некомпилируемый код как-то парсится в AST
Не всякий. Есть вариант, когда ast отстроить можно, а скомпилировать - нет.
В Visual Age for Smalltalk с его ENVY сохранение кода происходит на уровне метода - не компилируемый не сохраняется. Работать совсем не мешало.
не компилируемый не сохраняется. Работать совсем не мешало.
Вы серьезно считаете что так можно работать?
Я не только так считаю, я так работал. Но дело в том, что по своей природе методы в smalltalk преимущественно маленькие, а сохранение происходило именно на уровне метода. Неудобств не вызывало. Спросите у любого smalltalk`ера. Применительно к другим языкам - уверен, такое не прокатит
Есть у вас метод с суровыми конструкциями и сложной бизнес логикой. Что там именно не знаю, но не важно. Вы его писали полдня. Он не компилируется по объективным причинам. Надо куда-то отойти. Поесть, например. Надо верить что электричество не отключится? Так себе план. Я бы в блокнотик скопировал для надежности.
И зачем так системы делать? Компьютеры для человека, автосохранение вообще всего текста введенного человеком раз в минуту не стоит ничего. Значит оно должно быть.
Я никого и ни за что не агитирую. Просто рассказываю, как обстоят дела в ENVY.
Ксло, на smalltalk написать не компилируемый код весьма не тривиальная задача, учитывая его синтаксис и динамическую типизацию.
Но если удастся таки за полдня написать метод, который не компилируется - можно его просто закомментировать и блокнотик не понадобится
Написать код который не компилируется гораздо проще чем написать код который компилируется. Про работающий правильно код и речи нет.
Но если удастся таки за полдня написать метод, который не компилируется - можно его просто закомментировать и блокнотик не понадобится
Видите, вы уже про костыли начали говорить. Костыли которые надо постоянно микроменеджить человеку. Зачем? Пусть компьютер просто сохранит этот кусок текста. Человек должен решать более сложные задачи, а не комментировать кусок кода чтобы сохранить его.
Я рассказываю, как работал ENVY и что это не вызывало проблем, а Вы меня за советскую власть агитируете.
Написать код который не компилируется гораздо проще чем написать код который компилируется
Всё что я говорил относилось к конкретной среде разработки и конкретному языку. На smalltalk невозможно написать синтаксически правильный не компилируемый код. Вы боретесь с несуществующими проблемами.
Берем стратч, синклер бейсик, кумир древних времен - и вот у вас ИДЕ которая не позволяет собрать не компилируемую сущность.
Просто берем синтаксические диаграммы и каждое нажатие клавиши должно работать на их уровне. И только имена переменных и значения констант можно править текстом.
Закомментируйте.
Не нужно ничего парсить. AST должно строиться непосредственно средствами инструмента со встроенным линтером, а не парситься из текста программного кода. Тогда будет невозможно сделать что-нибудь некомпилируемое.
Да, еще как-то надо будет переделать сообщения об ошибках, которые сейчас содержат номер строки кода, а в этой системе они куда будут посылать программиста? В некие координаты листочка AST? Как будут выглядеть вещи типа PDB файлов?
О, это хорошие вопросы, спасибо.
Координаты листочка AST может быть даже полезнее будут - в одной строке могут быть всякие лямбды и не всегда удобно брикпоинт ставить.
Про PDB файлы надо будет почитать, что там как.
Надо не забывать, что номер строки отдает компилятор, а не среда.
Кстати, помимо хранения всего этого, как быть с компиляторами? Они-то текст пока на входе принимают. По всему глобальному AST выстраивать исходные коды и потом отдавать компилятору? Ну, помимо того, что это все выглядит несколько шизофреничным, это еще и дикое количество времени занимать будет.
Примерно так оно работает в TypeScript - во время компиляции парсятся в AST все файлы проекта и сериализуются в JavaScript. А потом движок JS заново строит AST и выполняет его. Выглядит весьма шизофренично.
Сериализовать в текст можно при загрузке проекта / смене ветки.
А потом движок JS заново строит AST и выполняет его. Выглядит весьма шизофренично.
Поэтому для веба придумали wasm. В который вы можете транслировать код практически из любого языка без необходимости строить промежуточный Javascript.
TypeScript - отдельная песня, там не компилятор, а конвертор по сути. В любом случае ему на входе исходники текстовые приходят и ошибки он выдает с указанием на строки этих исходников. И если вы не восстановили код из AST, а попытаетесь скомпилировать его из того, что только что ввели на экране, то очень часто компилятор будет "мазать". Т.е. при каждой компиляции надо будет преобразовывать код в AST, потом из него получать код для компилятора и тут же его назад среде подпихивать, чтобы было 100% совпадение. Уверен, разработчик будет счастлив, когда у него постоянно код будет переформатироваться.
Короче, я на 100% уверен, что эта затея дурацкая и в целом мертворожденная.
По всему глобальному 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# приложения, исходники которых не сохранились или не были доступны по той или иной причине. Но это совсем-совсем другая история.
текст удобнее, с текстом тоже работать удобнее, а вот как это реализовано в иде не хочу знать ), там еще как я понял от языка зависит, на С++ например можно подумать, а вот с java так не выйдет вроде
Вот не надо им подсказывать, а то начнутся патентованые форматы, это открывается в этой 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 строк". Мне ужасно жаль ревьювера.
Так это претензии к Гиту, а не к способу хранения кода. Я Гитом не пользуюсь просто по причине его сложности во всём. Казалось бы, простая идея - контроль кода и организация доступа, а наворочено столько, что за деревьями леса не видно...
То есть "не парятся" имелось в виду не простота использования, а м-м... наличие какого-то решения. Может быть для вашего случая подошёл бы какой-то другой способ.
Потому что код пишется для человека, а не для компьютера.
Сколько бы у вас не было ядер и планок памяти - они закончатся, когда вы откроете достаточно большой проект.
Ни разу такой проблемы не возникало, работаю с достаточно большими проектами.
Все становится намного хуже, когда вы работаете в команде. Мы используем специальное программное обеспечение для слияния изменений, но оно работает ужасно
Вы точно не пытаетесь решать несуществуюшую проблему? Современные системы контроля версий работают приемлимо.
А скажите, пожалуйста, на каком Вы языке пишете и сколько сейчас оперативной памяти?
Свежий пример решаемой проблемы: сегодня разбирался в чужом коде, и нужно было понять, зачем добавили кусок кода. Залез в историю - 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.
Есть визуальное программирование, но что-то те, кто пытались на нём создавать большие проекты без единой строчки кода в текстовых файлах, не особо довольны таким экспириенсом)
хранит 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 размером сколько-то мегабайт. Сами можете оценить полезность этого наследия в современных условиях.
Хотя в моменте это было довольно удобно.
Старожжилы припоминают концепцию Фантом ОС. Это было про другое, но по факту там код жил, распространялся и сапортился в формате байткода.
Не знаю, я застал времена токенизированных исходников (бейсик, ассемблер), и вот совершенно не стремлюсь к этому возвращаться. В данный момент такие исходники тех лет превратились в полутыкву, современными программами их так просто не открыть.
Почему мы все еще храним код в текстовых файлах?