Комментарии 240
Это просто не нужно.
Если у вас есть инструмент в IDE, который преобразует вводимый программистом текст в какое-то "расширенное представление", то пусть IDE где-нибудь это расширенное представление и хранит, а исходники не трогает.
Тогда и IDE хранит какие-то свои необходимые данные и быстро работает с проектом, и программист может работать в nano, отслеживать изменения при помощи git, и т.д.
Это просто не нужно.
Это слегка нужно когда приходит время сравнить изменения в исходниках не посимвольно а с учетом семантики. Ну то есть зашел какой-то Вася и заменил все табы на пробелы. С точки зрения обычного diff в исходнике изменилось чуть менее, чем всё. Если сравнивать такой вот байт-код, то не поменялось ничего. Ситуация с табами и пробелами, конечно, предельно надуманная - её можно митигировать линтерами, а Васе можно дать по рукам. Но в реальности всплывают всякие штуки, когда посимвольное сравнение только отвлекает от важных дел.
Обычно diff инструменты имеют настройку для игнорирования таблв и пробелов. Во всяком случае графические надстройки.
Diff-то ладно, а систему контроля версий любую можно настроить, чтобы она игнорировала подобные изменения и файл не коммитился, как изменённый? И если да, то бедняга Вася, обновив код из репозитория, опять должен будет табы на пробелы менять?
Для этого можно использовать precommit и скрипт проверки на пробелы/табы, его же можно запускать на этапе проверки пулреквеста. Вася не сможет закоммиттить даже локально, а если хуки у него вдруг не настроены, то проверки не дадут ему смерджить пулреквест в удаленном репозитории.
ИМХО: васе нужно просто загуглить что такое editorconfig
согласен, легаси проблема исходящая из легаси инструментария и человеческой несовершенности. но решения подобных проблем придуманы сто лет как.
Я почитал описание по вашей ссылке и чо-то, может, не понял из описания, что делает этот editorconfig: 1) он позволяет задать отдельно формат сохранения исходника и формат представления этого же исходника в редакторе? 2) он позволяет определить один формат исходника (типа, сколько пробелов вставлять по нажатию на <таб> и вот это вот всё?
Насколько я понял, второе - но тогда он "решает" какую-то другую проблему, и с какого-то другого конца.
Он решает проблему, не глобально, но в пределах всех кто раюотает с конкретными исходниками в которых он лежит. Это не идеальное решение, но это решение и оно работает.
Васе кровь из носу хочется пробелы, но будут табы, йа сказаль! - вы это называете "решением"?
Да, оно не идеальное, оно устроит не всех, оно грубое.. Но оно решение. И если вася хочет то может тыкать свои пробелы и ide сам заменит их на табы (или наоборот, тут по ситуации).
Возможно решение лучше существует, или скоро появится, но на данный момент я такого не знаю, а это знаю, и знаю что оно работает.
Я вижу как минимум один недостаток (оно может бесить васю) и ни одного преимущества в сравнении с "автоформатом перед коммитом".
Представим что васе пришлось переклонить репозиторий, например у него на рабочей машинке сдох диск, или он случайно цдалил локальную копию, и вот снова все его табы заменены на пробелы и это будет одинаково в обоих случаях.
Но если мы смоделируем ситуацию когда табы/пробелы реально влияют по какой-то причине на работу кода то автоисправление во время написание эту проблему решает, а вот автоформат при коммите нет. Может быть таб/пробел не самый показательный пример, а вот lf/cr/crlf/etc могут вызвать проблемы. Всё же мы тут говорим не про один конкретный кейс а абстрактно про кучу мелочей.
Алсо, про хранение кода в бинарном виде мне вдруг пришёл в голову отличный пример где это работает - конфиг cisco ios. Конфиг хранится в бинарном виде, но если вызвать show run мы увидем его текстовое представление.
Для коммитов в репозиторий принять единый стиль - без вольностей, чотко, строго, один. Не важно, какой - пробелы, так пробелы, табы, так табы - главное, чтобы был автоформаттер, который любой другой стиль мог бы приводить обратно к принятому. После клона/пулла/чекаута/(или как оно там где называется) каждый может запустить какой-то свой автоформаттер и перевести рабочую копию в тот формат, который ему нравится, лично для себя, лично у себя. А перед коммитом - обратно. Всё должно работать, разве что локальные диффы станет чуть геморройнее смотреть. Тут, на мой взгляд, и просматривается некоторый гипотетический юзкейс для какого-то необязательно бинарного, но более обобщённого представления исходного кода: не таб/2 пробела/4 пробела/фигурные скобки, а типа вот у нас абстрактный "вложенный блок"; не lf/cr/crlf, а вот у нас абстрактный "разделитель строк", и т. п., хранится в таком виде, отображается, согласно выбранным визуальным настройкам (типа model/view), хоть в редакторе, хоть в диффе, хоть где. Другой вопрос, выглядит ли это настолько уж большой проблемой, чтобы исключительно ради подобных фишек огород городить и новый формат изобретать, какие-то протоколы взаимодействия определять, по которым оно гоняется в дифф и обратно, и т. п.
Почти в любом достаточно большом проекте с нетривиальным количеством участников огромное количество времени тратится на чтение кода. Намерение кода гораздо важнее того, как код выглядит в виде дерева. Поэтому, как ниже уже отметили, удобство человека гораздо важнее удобства компилятора.
Так что линтеры, которые сразу бьют по рукам 🙂
Я вот чо-то не могу читать код на C-подобных языках, когда фигурная скобка не переносится на новую строку, типа чего-то такого
if(true.toStr().length == 4){
blah_blah();
}else{
вжух_вжух_магия();
}Ну, не то чтобы прям физически, технически не могу, скорее в смысле "не могу аш трисет". Когда последние крайние последние разы приходилось работать с подобным гов..., года уже были не те, чтобы в припадке благородной ярости переформатировать всё "под себя", искал авто-форматтеры, чтобы можно было отформатировать в удобный для меня формат, а перед коммитом переделать как было - "туда" было легко, а "обратно" - нет, ни один из распространённых стилей не совпадал с этой хернёй, которую нагородили дорогие коллеги (а надо ж чтоб символ в символ совпадало, чтоб файл не коммитился как изменённый и дифф не ругался). Написать своё было недолго, дольше было тестировать, что действительно конвертация туда-сюда нигде ничего не меняет. Возможно, внутреннее представление исходника в некотором универсальном формате тут могло бы помочь - мне отображай код вот так, а Васе вот эдак, а внутри всё до байта идентично.
Была у меня похожая ситуация с trailing commas в питоне. Техдиру они не нравятся категорически, а с форматтерами (особенно настраиваемыми) в питоне все довольно грустно, во всяком случае после js/ts. После долгих исканий, модифицировал библиотеку которая эти запятые наоборот добавляет. По итогу форматтер сначала вызывает black, а потом модифицированную либу. Заодно разобрался с расширениями под vscode, чтобы свой форматтер туда прикрутить.
Все в питоне хорошо с форматтерами. Блэка хватает за глаза, как мне кажется он даже избыточно настраиваемый.
А техдир дурачок что-ли местный? Есть вполне разумные доводы почем НАДО использовать трейлинг коммы — это не вопрос преференций, а практика хорошего кода.
Избыточно настраиваемый? Ему нельзя даже сказать использовать одиночные кавычки вместо двойных...
Ну, это же его драгоценное МНЕНИЕ ¯\_(ツ)_/¯
(Поэтому я им и не пользуюсь.)
Такое же, как ненависть сборщиков BunsenLabs Linux к mc.
Переходите на ruff. По умолчанию работает так же как и блек но можно такое поведение настроить.
просто дело привычки
Конечно... Нет. Для trailing commas (как и для табов-vs-пробелы) есть вполне себе объективные аргументы почему одно предпочтительнее другого.
Не просветите что это за аргументы?
Если trailing comma есть, diff с добавлением/удалением строчки меняет только эту самую строчку. А если её нет, ещё приходится менять ту-строчку-которая-была-или-стала-последней. В результате в диффе совершенно никак не относящиеся к задаче изменения.
По поводу табов-vs-пробелов. Табами можно сделать indentation, но нельзя сделать alignment. Поэтому приходится юзать И табы И пробелы. В результате выбор не между "только табы" и "только пробелы", а между "табы+пробелы" и "только пробелы". Пример:
CallFunction(arg1,
arg2, # Ну и как это выровнять табами? Никак
arg3);
Почему же никак? Надо первый аргумент тоже отбить табом.
А зачем вы такой alignment захотели сделать? Сделайте такой
CallFunction
(
arg1,
arg2, # Ну и как это выровнять табами? Вот так
arg3
);Если что, это шутка и я только что сам придумал такое форматирование, но ситуация, когда аргументы функции не влезают в одну строку - уже не очень хорошая в плане чистоты кода, и как форматировать её - вопрос дискуссионный и договорённости в команде
Держите ещё пример, джавадоки в джаве форматируют вот так:
/**
* blabla
*/
public void method() { ... }
Ну никак здесь звёздочки табом не подвинуть докуда надо.
Ещё пример, тернарный оператор:
auto value = condition ? result1
: result2; // чего будем с выравниванием делать, если у нас нет пробелов?
Чисто из интереса, без наезда. А зачем звздочки сдвигать на один пробел? Стиль такой? Ну и в целом, политика получается столько же табов, сколько в методе + пробел (пробелы же между операторами никого не смущают.
А тернарные я предпочитаю писать в таком виде:
auto value = condition
? result1
: result2;Т.е. результаты каждый на своей строчке, чтобы отделять их от условия. Тут визуально не принципиален отступ (хотя хочется, конечно чуть правее condition и с табами может быть нюанс)
А зачем звздочки сдвигать на один пробел?
Ну типа так принято: https://www.oracle.com/java/technologies/javase/codeconventions-comments.html#16838
The first line of doc comment (/**) for classes and interfaces is not indented; subsequent doc comment lines each have 1 space of indentation (to vertically align the asterisks).
Можно конечно этого не делать, технически ничего не сломается, но на вас будут косо смотреть.
А тернарные я предпочитаю писать в таком виде
Да, так можно. Но вы дальше сами признаёте что пробельчиков туда насыпать таки хочется :)
В общем мой посыл в том что с табами жить конечно можно. Но есть конструкции, в которых чтобы сделать красиво, понадобятся именно пробелы.
На моём проекте стейтменты пишутся по табам, а переносы по пробелам.
Срач вокруг табов ещё был связан с тем, что он был разный на разных системах и из-за этого где-то код превращался в символьное месиво. Уже много что унифицировали в целом, но и сейчас довольно интересные кейсы находятся, типа переноса строки unix/win из-за которых кроссплатформенные скрипты ломаются у некоторых, то ещё развлечение
callfunction( arg1,
arg2, # легко выровнять табами
arg3);Все можно сделать табами, все можно сделать пробелами. У обоих свои недостатки, пробелы нужно больше нажимать, табы нужно мириться с лишними отступами и длинными строками.
Ну и плюс не стоит забывать, что сильно зависит от языка (привет питон и ямл)
Не рекомендую. Горизонтальное выравнивание не нужно, ни для запятых, ни для знака равно. Вы говорите про trailing comma, чтобы не портить diff, но при этом используете выравнивание пробелами. Это плохо работает. Например, я через IDE переименовываю функцию, и это сразу нужно во всех файлах ещё проследить чтобы аргументы остались выровненными. Или если само имя функции уже настолько длинное, что аргументы будут уже за границами. Или подряд две похожие функции с разной длиной имени, но одинаковыми аргументами будут иметь разные отступы аргументов. Я пришёл к выводу что простой одинарный отступ (принятый в вашем языке) лучше всего. Почему первому аргументу такое особое отношение? Если уж переносить, то переносить всё, либо ничего.
CallFunc(
arg1,
arg2,
arg3);
Или выравнивание по равно. Это тоже портит будущие дифы. Кроме того не автоматизируется. Этот кусок кода не получится скопировать в другое место без переформатирования. А если они в разных блоках, разделены вызовом функции, то они должны иметь одинаковый или у каждого блока свой? Так же каждый раз смотреть в конец строки чтобы понять какая логика там на самом деле неудобно. Вот было:
a = 3;
bcd = 4;
А потом добавили/удалили новый и придётся все выравнивать по новой.
a = 3;
bcd = 4;
my_new_long_parameter = 5;
О да, самое отвратительное форматирование. Просто бесит при чтении огромными пустыми пространствами справа-слева. Оно особенно начинает бить, когда переименовывается функция (даже не в этом файле - например, в базовом классе или в интерфейсе - и надо бегать по всей программе и переформатировать всё) или когда у функции длинное имя (тогда либо возвращаемся в школьные годы и называем функции "A", "B", "C", либо смотрим, что у нас теперь имена аргументов начинаются с середины экрана или вообще не влезают в экран). Отступ ни в коем случае не должен зависеть от длины слов выше/ниже него. Он - чёткая граница семантических блоков, а не указатель, сколько букв в словах.
В таких случаях помогает упражнение с рукой: поднимаете правую руку вверх, потом резко опускаете, и синхронно говорите "ну и ... с ним".
Забейте, короче, оно того не стоит. Но вообще, если не ошибаюсь, по-умолчанию Шланг-формат так делает.
Что значит "не стоит", когда мне это говно приходится днями напролёт разглядывать, а временами и ковыряться?
Оффтопик
Кто-то явно смотрит Стаса Асафьева =)
Везде где я работал подобные проблемы решались скучным запуском `bla-bla-bla-autoformat` перед коммитом с конфигом, хранящемся в VCS. Где-то даже были проверки стиля, не пропускающие неотформатированный по стандарту код.
И всё. Всем становилось пофигу: табы-или-пробельчики, на какой строчке ставить скобочку, сколькими пробельчиками отбивать скобочки/операторы, размер отступа, выравнивать или нет комментарии, как правильно именовать сущности (CamelCase vs sneak_case) + миллион других потенциальных тем для холивара.
Да я как-то так и решил. Нашёл несколько готовых автоформаттеров, попробовал, лень было раскуривать, как (и можно ли) задать для какого-то из них собственные стайл гайды, проще оказалось написать пару коротких скриптов на простых регекспах, sanity.py обрабатывал код, свежеполученный из репозитория, insanity.py переделывал всё взад перед коммитом. Я ещё люблю, правда, временами упороться в табличное форматирование, типа:
short_var = 5
very_long_variable = 57Иногда пробуешь какой-нибудь новый для себя редактор/IDE, а там встроенный линтер, такой, "ой, божечки, у вас тут больше одного пробела перед операторомъ!!11одинодин" - у себя-то я настрою, чтоб не орало, но если "стандарт" требует и не позволяет коммитить, то, наверное, невозможно будет сделать, чтобы туда оно уходило с одним пробелом, а у меня обратно восстанавливалось.
подобные проблемы решались скучным запуском `bla-bla-bla-autoformat` перед коммитом с конфигом, хранящемся в VCS
Это если код свой. А если приходится писать код на основе, скажем, llvm и при этом постоянно читать основную кодовую базу (там как раз открывающая скобка на той же строке) ?
Нет, ну вы что угораете? Вы на полном серьёзе рассуждаете, что положение открывающей строки влияет на читабельность?
Выше человек писал, что его от такого перекашивает - именно в плане чтения, а не написания кода. Мне то приходилось работать в проекте с разными coding guidelines в разных компонентах (различались и новые строки, и пробел/табуляция, и snake/camel), и для реализации серьёзной фичи коммитить надо было в птяь-десять разных компонент - ничего, отношусь спокойно.
Да. Непривычно отформатированный код читать труднее.
Возможно какому нибудь джуну это непонятно, ему любой код читать трудно, но когда читаешь по диагонали сотни исходников, например ознакамливаясь с новым проектом, это очень сильно влияет
Нет. Для опытного разработчика (не по стажу, а по реальному опыту) существенно не влияет.
Первые полчаса, максимум полдня стиль форматирования ещё заметен. Очень быстро наступает привыкание, и наступает привыкание. Есть намного более существенные факторы: дизайн проекта, хорошие имена идентификаторов (привет STL), декомпозиция кода, цикломатическая сложность, документация, поддержка навигации в IDE, удобство поиска по коду, наличие тестов и т.п. Форматирование плетётся в хвосте и ни на что существенно не влияет.
Этот код выглядит как г..но не потому, что открывающая скобка не перенесена на новую строку, а потому, что вы убрали все пробелы перед/после скобочек.
А вообще, как уже сказали, принятый на проекте единый стиль форматирования + автоформаттер у всех решает проблему.
Ну вот видите, вас волнуют пробелы перед/после скобочек, без них для вас код выглядит как г..но, а меня не волнуют, для меня он выглядит как г..но что с пробелами, что без, а теперь представьте, что насяльник, определяющий стиль форматирования на проекте не вы, а я...
Всегда найдется формат и человек, которого он не устраивает. Представляете, вы продавите под себя эти скобочки, а потом окажется, что остальные 9 программистов не переваривают их в таком виде. Уж проще привыкнуть к тому, что правила форматирования в разных проектах разные.
Ну а вообще инструмент преобразования "туда-обратно" на лету был бы тут удобен. Интересно, есть ли такое в популярных IDE? Не встречал.
Ну а вообще инструмент преобразования "туда-обратно" на лету был бы тут удобен. Интересно, есть ли такое в популярных IDE? Не встречал.
В целом реализуется без проблем. При открытии файлика прогоняем автоформат с одними правилами, перед коммитом с другими.
Дифф локально будет выглядеть ужасно. Проще привыкнуть к корпоративным правилам. И не бояться лезть к тем кто ими заведует чтобы истреблять всякую глупость. Лично истребил на взлете попытку ограничить длину строк в Джава исходниках 80 символами. Плюсовики написавшие это правило для Джавы в принципе не поняли что они сделали.
80 символов не плюсовики придумали.
"Во всём виноват Холлерит" со своими перфокартами? (Не знаю, было ли у него тоже 80.)
Не все форматируют С-подобный код таким образом...
Отформатировать все под себя, коммит, внести полезные правки, коммит, новая ветка от исходной (до форматирования), черепик/полуручной перенос второго комита с полезными изменениями.
Вопрос в количестве изменений, чем больше, тем бесполезнее и больнее алгоритм выше
Уж проще сесть и написать для IDE плагин с умным автоформатом, который будет исходники переводить под корпоративный стиль перед мержом в мастер.
Это не нужно ровно до того момента как кто-нибудь это не сделает. А авто-форматеры не решение проблемы, есть приличное количество кейсов когда форматер съедает код и делает его нечитаемым.
Да и в целом идея то здравая, тебе ide будет держать прекомпиленное древо, которое будет компилится в разы быстрее чем с 0 весь проект перемалывать. Грубо говоря, те же модули из С++ так работают, когда весь код попилен на модули он вместо 1 минуты собирается 1 секунду.
есть приличное количество кейсов когда форматер съедает код и делает его нечитаемым.
Я ещё ни разу не видел, чтобы форматер ломал корректный код.
Вот некорректный ломал. И обычно на этом этапе вопли и заканчивались, потому что следом ломался CI, и человек бежал чинить что он там пытался замёржить, а там и форматирование чинилось само.
Я ещё ни разу не видел, чтобы форматер ломал корректный код.
Попробуйте любым форматтером отформатировать код Slate-виждетов из UnrealEngine. Получится полная бяка. Рандомный пример из интернетов: https://gist.github.com/yateam/d85bcc25c032190396376cff2fa14bc5#file-sgreetings-cpp-L24-L85
Не понятно что вы хотели сказать. Это уже отформатированный код? Он нерабочий?
Этот код отформатирован руками. Код рабочий. Тулы типа clang-format его превратят в месиво.
Вопрос простой: они превратят его в нерабочий код?
Сейчас меня заминусуют, но он и так выглядит как месиво :-)
А вообще - в тех проектах, где это было у нас - на такие файлы (единичные), мы ставили просто исключение для clang-format.
Кроме того, clang-format умеет исключать кусок кода из форматирования:
https://clang.llvm.org/docs/ClangFormatStyleOptions.html#disabling-formatting-on-a-piece-of-code
Используя комментарии перед и после этого куска:
// clang-format off
int non_formatted;
// clang-format on
Вы изобрели байт-код, который делается в некоторых языках (например PHP).
Только при чем тут код исходный? Само слово "исходный" намекает на первоначальность.
Это для рекламы ТГ канала вы этот бред написали?
Простите, а вы не знаете, почему тг сейчас так часто рекламируют? Я просто реально не могу это понять, что за "хайп" сейчас такой, это ведь ничего вроде как не дает оО
Чтобы набрать аудиторию, на которую потом транслировать булшит от рекламодателей и получать за это деньги
У каналов в Телеге довольно высокая и при этом простая монетизируемость.
Иван Иванович работает. Вот как он всегда работал. И за это ему платят зарплату. А с 1 января он может дополнительно получать деньги, если всем своим коллегам будет во время разговоров показывать рекламу.
По дороге с работы Иван Иванович едет на автобусе. Вот как он всегда ездит. А с 1 января он может за отдельные деньги всем людям в этом автобусе показывать рекламу.
Потом Иван Иванович приезжает домой, а летом ещё и по выходным ездит на дачу. А с 1 января он может за дополнительную оплату и своей семье, и соседям по даче, и гостям показывать рекламу.
— Дополнительные!!! Деньги!!! За обычную жизнь!!!
Разве это не делает телеграм лучшей программой, которую создали люди?
По дороге с работы Иван Иванович едет на автобусе. Вот как он всегда ездит. А с 1 января он может за отдельные деньги всем людям в этом автобусе показывать рекламу.
А это идея! И главное людям некуда деться - хочешь не хочешь, придется смотреть рекламу.
Почему так ещё не делают?
Хотелось бы узнать, где все остальные отписавшиеся берут деньги за содержание телеги. Кладу в конце своих статей телегу от себя лично, чисто на случай, если людям будет интересно и остальное про мою жизнь, а денег кроме как за саму статью и не видел ни разу :-) Пару раз писали рекламодатели с каким-то сомнительным предложением, но даже на вопрос «а пост вы напишете или мне придумывать?» не ответили.
Я думал уже изобрели рекламных ботов, которые автоматом рекламу у тебя в канале показывают...
Рекламодатели приходят когда подписчиков минимум 1000-1500 (настоящих). Причем как-то сразу много. Думаю, они фильтруют в tgstat или какой-то другой системе, и после какого-то порога начинают замечать ваш канал
Вообще говоря, иногда возникает подозрение, что недовольство ссылкой на телеграм-канал - это такой маркетинговый ход, позволяющий указать людям, что в тексте есть такая ссылка. Мы же привыкли игнорировать разные ссылки, если они прямо нам не нужны, а комментарии вроде "Спасибо за ссылку, хороший канал!" конечно не сработают, а вот негативный комментарий не заподозришь в продвижении ссылки, при этом информацию о ней он донесёт, ну и, если статья интересная, по ссылке можно и кликнуть...
Просто такие комментарии уже не первый раз встречаются, и не только на этом сайте, как-то вдруг массово невзлюбили ссылки на Телеграм-каналы, может просто придумали такой ход и активно его используют?
Это для рекламы ТГ канала вы этот бред написали?
Рак, сэр. Рак пускает метастазы.
99% статей что-то рекламируют. Или свои телеграм-каналы, или продукты компаний, или сами эти компании.
Это всё четко разрешено правилами: можно вставлять рекламную ссылку на свой блог. Хабр специально это разрешил пару лет назад.
Да что там говорить, сам Хабр существует только для того, чтобы получать деньги с рекламодателей и с платных блогов компаний! Без рекламы не будет вообще никаких статей и Хабра тоже.
Но нет, каждый раз находится человек, отрицающий объективную реальность, и пишет "разгромные" статьи про "рак".
Но объясните, в чём смысл? Ваш пост каким-то образом попал в мою ленту, значит, вы уже до меня достучались, и если напишете ещё чего-нибудь, то достучитесь снова. Ну так и дальше пишите туда же, куда пишете, нет? Если какие-то другие пользователи читают другую ленту, потому что для них удобнее другой источник -- дублируйте и туда, и всем будет хорошо.
Вопрос табов или пробелов решается форматированием кода перед коммитом и после чекаута. Вы можете настроить хук и весь код в репозитории будет причесан по вашему вкусу.
Хранить индексы и внутреннюю информацию о коде, которую понимает о нем компилятор в репозитории смысла нет. Потому что и информация и формат может меняться по мере обновления компилятора или других компонентов среды. Да еще и избыточность высокая.
Отличная идея!
Но она уже была реализована в компьютерах Sinclair ZX Spectrum там ввод программы с клавиатуры осуществлялся сразу токенами , или ключевыми словами языка Basic. Для этого использовалась комбинация спец клавиши и названия функции на клавиатуре. Если вводить название функции символами клавиатуры - то не работало.
Это был интерпретатор , но он работал гораздо быстрее других.
Тоже первая мысль была - "миллениалы придумали ZX Spectrum". :-)
Чуть круче делали компиляторы с Ассемблера: парсили ручками написанные мнемоники сразу после ввода / редактирования строки. Всякие там TASM, MASM, MARASM (могу путать названия).
Компиляторы с ассемблера. Какая статья, такие и комментарии, мда..
Почему нельзя называть программу, переводящую тест на ассемблере в машинные коды, компилятором?
Потому что такая программа уже названа ассемблером.
Ассемблер - это программа, транслирующая исходный код на языке ассемблера в машинный код. Словосочетание "текст на ассемблере" также некорректно. Правильно говорить - язык ассемблера. По аналогии - есть птицы, а есть птичий язык.
Язык ассемблера - штука крайне непереносимая. Он зависит как от архитектуры процессора, для которого пишется программа, так и от самого оссемблера. К примеру, для архитектуры x86 во времена dos было несколько популярных ассемблеров, на слуху были TASM и MASM, оба работают с одними и теми же мнемониками x86-команд, но синтаксис немного разный, и более-менее сложную программу для одного из этих ассемблеров нельзя было так просто собрать другим, без доработок.
Компилятор же - это транслятор с языка высокого уровня (коим язык ассемблера не является). Программы на языках высокого уровня более переносимы.
Мысль понятна. Боюсь, правда, что слово "ассемблер" уже переняло на себя дополнительное значение "язык ассемблера".
Точнее дело не в этом, а в том, что это значение стало практически основным. Поэтому фразу "так делали ассемблеры" сходу расшифруют не только лишь все.
Трансляцию ассемблерных программ иногда также называют компиляцией.
Словосочетание "текст на ассемблере" также некорректно. Правильно говорить - язык ассемблера.
Этот комментарий - текст на русском, т.к. написан на русском. На русском языке, если угодно.
Ладно, больше не буду строить из себя грамар-наци. Неблагодарное это дело)
Вообще конечно да, язык (человеческий, не ассемблера) - штука живая, постоянно меняется под его носителей.
Какие носители, такой и язык..
ввод еще ладно, в спектруме хранение бейсик программы в памяти хранилось в таком виде.
Как и в БК-010-01, там тоже частично.
Ещё из Спектрума можно взять экономию на концах строк за счёт установки старшего бита?
(Ну и что, что во многих языках можно использовать Юникод в идентификаторах -- это обычно запрещено в код-стайле ¯\_(ツ)_/¯ )
Кажется, оно там хранилось сразу в двух видах (текстом и кодами), потому что был такой прикол - записать в текстовое представление не то, что в кодовом, и тем самым ввести неопытного хакера в замешательство.
Как архитектура процессора связана с представлением исходного кода в среде программирования?
Отчасти, возможно, для экономии ресурсов (хотя сам по себе Z80 достаточно мощный для парсинга текста - но тут ещё и память экономится); возможно, дизайнеры решили, что вводить инструкции BASIC одной кнопкой проще (хотя разные виды курсора на Спектруме, конечно, так себе удобство). У меня был калькулятор на Z80 (TI 85) c экранчиком, позволяющим вводить текст и рисовать графику - там программа представлялась текстом, но можно было через менюшку быстро вставлять имена инструкций.
А, да, пробовали. LISP называется:)
1) При совместной разработке задача управления версиями важнее чуть более быстрой компиляции. Для этого формата надо писать свой git.
2) Синтаксически абсурдный текст (скажем, вставленный не туда copy-paste) может сильно напрячь эту систему. Вообще понятие "вставки" в терминах текста превращается в сложное преобразование дерева. Я начал набирать `int foo(char, ` и весь последующий текст в смысле подлежащего дерева превратился в тарабарщину.
3) Хранение любой служебной информации IDE упирается в требования обратной совместимости.
4) Если у меня почему-то сломалась IDE сейчас, или мне надо что-то поправить, а под рукой только планшет, или мне нужно править исходники через ssh, я могу открыть файл кода одним из 100500 редакторов. В дивном новом мире это ква, разработки без IDE не бывает.
0) Комментарии!!!
Комментарии в этой схеме изящно превращаются в метаданные, выкидываемые при сборке. Что только пойдёт им на пользу. Потому что кому нужны упоротые сценарии «вставим ровно 137 пробелов в конце 17-й строки и напишем комментарий там», когда есть привязка комментария к оператору, группе операторов или скоупу? На уровне UI это можно оформить как bubble boxes.
Возражение №2 обойти труднее. По классике оно формулируется так: когда из одного правильного состояния можно попасть в другое правильное состояние только через неправильное, невозможна система, требующая постоянного нахождения в правильном состоянии. В «Спектруме» такую систему построили за счёт тотального урезания редактирования (по принципу «нет поддержки буфера — нет проблемы»). Мало кто согласится сейчас так программировать.
В treesitter как-то решили эту проблему. У них в описании:
"Достаточно надежен , чтобы обеспечивать полезные результаты даже при наличии синтаксических ошибок."
Дв и jetbrains ide умеют строить неполноценное дерево и осуществлять рефакторинг даже в несовсем правильном коде
Я очень люблю концептуальный юмор. Когда-то Хайт писал по поводу паспортной реформы: конечно хорошо, что мы убрали графу «Национальность», потому что она способствовала расизму, но и игнорировать духовные потребности народа (право знать знать, с кем именно общаешься) тоже нельзя. Поэтому давайте уберём графу «Национальность» и введём графу «Какая национальность была раньше».
Часто вспоминаю, когда вижу, как сначала в ЯП добавляют статическую типизацию, а потом пишут всё на Object/any/whatever.
В данном случае безусловно можно ввести узел типа Invalid, для которого вернуть текстовое представление, и при рефакторинге с остальными узлами обходиться как с валидными, а для невалидных — по старинке, но тогда в чём смысл всей махинации?
P.S. На практике описанный выше приём — хороший способ, когда нужно саботировать смену парадигмы. Не знаю, писало ли про это ЦРУ в своих полевых мануалах.
Шутки ради... dot .Net так и делает, спасибо всем разработчикам .Net, ваши исходники (коммерческие в том числе) бывает и пригождаются.
я конечно не сварщик, но похоже вы переизобрели лисп
У plaintext форматов есть одно большое преимущество - они не теряют свою доступность со временем.
Представьте, что ведёте вы личную базу знаний или личную бухгалтерию в программе на foxpro, написанной каким-то энтузиастом. Ну а что, удобно. И хранит эта програмка данные в бинарном формате придуманном под свои нужды.
Проходит 25 лет.
И вот у вас нет ни кода, ни живого разработчика, ни инструментария для разработки и реверса, ни-че-го, чтобы до этих данных доступиться. Даже компьютера с операционной системой, под которую была написана эта программа может уже не быть в продаже.
А теперь представьте, что база знаний у вас - в obdisian или orgmod'е емакса, а личная бухгалтерия - в любом формате любого plaintext ledger'а.
Такой проблемы просто не будет. Данные в плейнтексте можно анализировать в любое время любыми инструментами и конвертировать куда угодно как угодно.
---
Как пример чуть более приближенный к коду - вот 1c, afaik, хранит свои конфигурации в своём формате. И у разработчиков как правила нет особого выбора, кроме как использовать свой какой-есть встроенный в платформу инструментарий для того, чтобы "заблокировать" файл для редактирования, подправить и загрузить обратно. Какие-то возможности прикрутить git, насколько я знаю, появились относительно недавно.
Теперь давйте возьмём любой язык программирования, исходники которого хранятся текстом.
Я могу работать с кодом языка программирования, который появился "вот буквально вчера" используя инстурментарий (svn, diff, vim) бородатых годов.
И в другую сторону - я могу работать с кодом написанным до моего рождения, используя свежую версию VSCode'а, гит, инструменты для CI/CD, написанными через много-много лет от того момента, как был написан код.
---
К тому же - бОльшая часть плюсов - ненастоящая
Компиляция будет происходить значительно быстрее.
Точно ли?Не будет споров а-ля "табы vs пробелы", в файл попадет лишь дерево.
Не спорить просто - просто не спорьте)
Если совсем упороться, то, наверно, можно даже настроить IDE так, чтобы писать на другом языке.
Если языки позволяют это (условно говоря, вы транслируете ограниченное подмножество языка C в ограниченное подмножество pascal, и, по факту вам надо только синтаксис основных конструкций переписать и begin / end вместо фигурных скобочек расставить) - вам и текстовое представление для этого преградой не будет, это пишется за вечер. (Это буквально типичная домашка соответствующего университетского курса)
Проблема в том, что языки отличаются не только этим. Разные системы типов, разные модели исполнения. Разница в синтаксисе базовых конструкций - самая малозначительная часть языка, если вы прикидываете, сколько времени вам нужно на изучение нового языка - можете считать, что разницы в синтаксисе практически не существует.Что если дать возможность менять шрифты, чтобы выделять какие-то отдельные важные функции жирным красным цветом?
Поставьте в функции комментарий // #color:red и напишите плагин к своей IDE, вы прекрасны. Более того, поскольку эту информацию вы спрятали в плейнтексте, теперь поддержать эту подсветку сможет кто угодно на какой угодно IDE, в какой угодно системе показывающей или анализирующей ваш код, написанной на каком угодно языке, через сколько угодно лет в сколь угодно далёкомт будущем.IDE может хранить в этих бинарях свои данные для ускорения каких-то процессов отображения и автокомплита. Правда, файлы могут сильно разрастись.
IDE уже хранит своё хозяйство в файликах рядом.
У plaintext форматов есть одно большое преимущество - они не теряют свою доступность со временем
Фотографии прекрасно хранятся в бинарном формате JPEG и никого не беспокоит что этот формат потеряет доступность
А их нельзя хранить текстом. Хотя, с развитием нейросетей, наверное, можно будет... Равки же занимают очень много места.
Почему нельзя, XML с тегами, в которых координаты пикселя и цвет, только это не очень эффективно, зато можно править в любом блокноте\nano
Осспаде, ну почему XML-то, люди, что с вами не так???! Если уж вы взялись хранить, по-сути, битмап без сжатия, так и храните битмап как битмап: ширина-высота и длинная строка RGB-триплетов, хоть бинарно, хоть текстово. В XML у вас будет на 1 байт данных 10 байт тегов, а плюсы каковы? Сможете в блокноте\nano менять значение пикселя по заданным координатам? Очень нужная операция, да и для неё можно взять более вменяемый текстовый формат.
А как вы найдете нужный пиксел? Будете высчитывать смещение? Легко ошибиться. Вообще я не про то, что давайте хранить изображения в тексте, а про то, что есть бинарные форматы которые вполне успешно хранят информацию, позволяют её редактировать, поддерживаются на разных платформах и операционных системах.
Всё уже изобретено. https://ru.wikipedia.org/wiki/Portable_anymap
лучше даже https://ru.wikipedia.org/wiki/X_Pixmap
это вообще валидный C-код
Если уж вы взялись хранить, по-сути, битмап без сжатия, так и храните битмап как битмап: ширина-высота и длинная строка RGB-триплетов, хоть бинарно, хоть текстово.
Это называется PBM (portable bitmap format)
SVG?
А их нельзя хранить текстом. Хотя, с развитием нейросетей, наверное, можно будет... Равки же занимают очень много места.
Да можно, просто нужно подобрать подходящий архиватор, которые зархивирует их до адекватного размера (повторяющиеся куски текста это вообще идеально для большинства архиваторов). Но получится тот же JPG просто с другого бока. Ну ладно - почти тот же, так как там не будет потерь, а значит архив будет большого размера.
Ну, графику тяжело хранить в виде текста. И да, это проблема - даже сейчас половина реализаций так и не научились правильно читать заголовок JPEG и показывают картинки не "лёжа на боку".
Ну, графику тяжело хранить в виде текста.
"На фотографии изобажена девушка с третьим размером в белом платье на фоне моря, задумчиво глядящая на плывущий вдалеке корабль с алыми парусами".
IDE, которые работают с текстовыми исходниками, но не умеют не то что рефакторинг, а и более прозаические вещи. я тоже встречал.
Ну, графику тяжело хранить в виде текста.
SVG с вами не согласен :D
Ну, графику тяжело хранить в виде текста.
Формат XPM.
Имейте в виду, что в формате JPEG хранятся только те фотографии, которые больше никогда не надо менять.
А если автор предполагает, что надо будет менять, он хранит в формате без потерь.
Конечно, без потерь тоже бинарный формат, однако это он только на первый взгляд бинарный. Если смотреть внимательнее, там вполне себе текстовые символы, просто они немножко другие, потому что записывать надо не 26 знаков латинского алфавита, а 255 знаков яркостного алфавита.
Фотографии прекрасно хранятся в бинарном формате JPEG и никого не беспокоит что этот формат потеряет доступность
Потому что это просто формат архивирования. Примерно такой же как zip. Никто не мешает брать исходные коды и архивировать их каким-нибудь быстрым архиватором для того чтобы быстрее считывать в память.
фотографии да, а текст не очень. И разрешение когда-то крутых эротических фоточек 640x480 сейчас выглядит унылой порнографией.
Вы сравниваете теплое с мягким сейчас.
А вы про который JPEG? Исходный или там JPEG 2000 / JPEG XL? :)
И - ничего что некоторые типы фотографий в нем хранить - не особо получается. Ну например те картинки что обычно в FITS хранят (обычно черно-белые, с чудовищным динамическим диапазоном, с кучей не нужных для других целей метаданных).
Или то что хранят в RAW.
Ну и JPEG - lossy.
И у разработчиков как правила нет особого выбора
В этом месте играет theme song:
ни-че-го, чтобы до этих данных доступиться
Мне кажется, единственная проблема с чтением DBF — отсутствие самодокументирующей структуры базы.
Интересно было бы посмотреть с какой периодичностью эта идея озвучивается на хабре. Я вот помню, что я уже участвовал как минимум в одном обсуждении, а скорее в двух.
Посмотрите как программы на Бейсике хранились на ZX-Spectrum. Это уже изобрели давно до вас. Но там это делалось ввиду маленького количества оперативной памяти. Хранить там текстом весь код было расточительством. Сейчас с этим проблем нет, а «Компиляция будет происходить значительно быстрее» вообще почти роли не играет. Если это компиляция, то это только один раз при сборке программы. Да и при интерпретации тоже не особо ускорит. К тому же часто исходный код преобразуется в некоторый промежуточный код. Хранение кода в таком виде скорее больше проблем создаст. Те же системы контроля версий. Вы такой идеей полностью нарушаете работу команд.
Компиляция будет происходить значительно быстрее.
Нет. Разбивка текста на лексему или разбор на AST - это даже не вершина айсберга компиляции, это подтаявший лёд на этой самой вершине.
IDE не будет долго "индексировать" проект, подсветка синтаксиса и большая часть информации для автокомплита будут доступны сразу.
Нет. См. пункт 1.
Не будет споров а-ля "табы vs пробелы", в файл попадет лишь дерево.
А так же исчезнет куча полезного форматирования, применимого в конкретном случае, которое позволяет сделать код более понимаемым.
Если совсем упороться, то, наверно, можно даже настроить IDE так, чтобы писать на другом языке. Например, код был на Java, а ты себе показываешь его на котлине. Просто где-то в IDE пометить, чтобы в файл сохранялось джавовое AST. Здесь я не уверен, просто как мысль, что можно ещё сделать, если отказаться от оков текста.
Языки отличаются друг от друга гораздо больше, чем просто "набором символов, входящих в лексему". И даже больше, чем типами узлов в AST. Задача перевести программу с одного языка на другой практически невыполнима в общем случае.
IDE может хранить в этих бинарях свои данные для ускорения каких-то процессов отображения и автокомплита. Правда, файлы могут сильно разрастись.
А зачем? IDE и так хранит эти данные в индексах.
Синдром Поттеринга (ЕВПОЧЯ)
Прочитав пост, я поймал себя на мысли, но тексто-генераторы на базе современных моделей такого не напишут :)
Вообще, это мнение - классический пример того, как вместе с водой из корыта выкинули и ребенка. Исходный код нужен чтобы человек мог его править и делать это эффективно. Соответственно все приоритеты IDE в первую очередь должны быть направлены на человека и его удобство и эффективность. Как эти цели позволяет достичь предложение - никак от слова совсем кроме того, что мешает
Компиляция будет происходить значительно быстрее.
IDE не будет долго "индексировать" проект, подсветка синтаксиса и большая часть информации для автокомплита будут доступны сразу.
Не будет споров а-ля "табы vs пробелы", в файл попадет лишь дерево.
Если совсем упороться, то, наверно, можно даже настроить IDE так, чтобы писать на другом языке. Например, код был на Java, а ты себе показываешь его на котлине. Просто где-то в IDE пометить, чтобы в файл сохранялось джавовое AST. Здесь я не уверен, просто как мысль, что можно ещё сделать, если отказаться от оков текста.
Что если дать возможность менять шрифты, чтобы выделять какие-то отдельные важные функции жирным красным цветом?
IDE может хранить в этих бинарях свои данные для ускорения каких-то процессов отображения и автокомплита. Правда, файлы могут сильно разрастись.
Скорее всего, появится много чего интересного, что сейчас и в голову не приходит. Подход совершенно иной.
Да по фиг, в реальности она занимает немного, да и программирование - хоккей, можно и расслабиться на 15 секунд без риска оказаться размазанным по борту
Вроде уже сейчас все быстро, не?
Да вообще по фиг, так как форматирование происходит само по себе
Ну это если совсем упороться, главное - зачем?
Интересная мысль, продайте кому-то из авторов IDEшек
Оптимизировать надо то, что медленно. А то что быстро - не надо.
------------------
Можно еще конечно вспомнить, что компиляция может оказаться малой частью процесса и все такое - но это уже лишнее
Как будет идти процесс редактирования? Вот уже есть текст программы. Он рабочий, все ок. Вы добавили несколько команд. С ошибками, либо специально, неважно. Текст, который на экране, уже не компилируется. Как сохранять на завтра недоделанный проект? Как вообще будет редактирование? Как ide будет работать с неверным кодом (впрочем, это и для обычных ide касается).
Такая система была бы нормальна для языков програмирования, которые набираются полностью мышкой - драг-дропом, типа систем для детей, где полоски и диаграммы (забыл как он называется). Либо для uml-диаграмм или программ в виде диаграммок. Для программ для квантовых компьютеров, как у Интел на сайте.
Вполне возможно, но не для нынешних языков типа java или C++.
Как, как да как.
Легко — именно так работает IDE классического VB и VBA. Она вообще не хранит код как текст. Вы его не нацдёте в памяти процесса. Даже в виде отдельных строк. И у неё вообще нет проблем с представлением синтаксически некорректных данных — просто путём введения отдельной сущности для представления некорректных стейтментов.
Пруфы в студию
В каком виде вам нужен пруф, чтобы он считался пруфом? Если мой комментарий о том, что вещи устроены так, это не пруф, то будет ли моя статья об этом же самом считаться пруфом?
Я единолично разреверсил VB/VBA (по крайней мере эту его часть), задокументировал все типы узлов синтаксического дерева, организцию структур, типы сущностей RPN-подобного представления кода (дерево вскоре после своего построения конвертируется в линейную RPN-like цепочку из 16-битных сущностей и именно эти линейные структуры долговременно хранятся в памяти IDE, именно они представляют код и именно из них регенерируется текстовое представление кода, когда его нужно отрисовать на экране, скопировать в буфер обмена или сохранить в файл.
Вот вам пруф, к достоверности которого вы явно не прикопаетесь:
Откройте VB/VBA и в IDE напишите какой-нибудь код, например такой:
If Minute(Now) Mod 2 = 0 Then MsgBox "Hello World!" Else MsgBox "Goodbye!"Теперь присоединитесь к процессу IDE отладчиком и попробуйте в памяти процесса найти эту строчку. Вы её там не найдёте. Ни в виде ANSI-строки, ни в виде UCS2-строки, ни в виде UTF8-строки. Ни в каком виде.
Точнее, есть шанс, что вы её случайно найдёте в памяти, но это просто просто мусор — незанулённый и никем более не используемый регион памяти. Можете затереть в таком случае всю найденную строку буквами «Ы», вернуться в IDE и строка с If-ом как была, так и останется.
А, ну окей, скажете вы, наверное IF как структура как-то хитро представляется, но вот условие IF-а, then-clause или else-clause должны храниться как строка.
Нет, тоже мимо.
Подстроку «Minute(Now) Mod 2 = 0», подстроку «MsgBox "Hello World!"» и подстроку «MsgBox "Goodbye!"» вы тоже не найдёте. Их не будет в памяти. А если вдруг и будет, то это мусор, перезатирение которого чем-либо иным ни на что не влияет.
Гораздо больше подробностей о том, как это устроено под капотом, можно прочитать в этом комменте
https://habr.com/ru/articles/582566/comments/#comment_23578554
трёхлетней давности. Там и с примерами того, как те или иные конструкции кодируются и гораздо больше.
И вот тут продолжение того коммента: https://habr.com/ru/articles/582566/comments/#comment_23589108
А что если исходные коды программ хранить в бинарном формате?
Все же зависит только от ваших умений быстро ориентироваться в машинных кодах, но тогда уж и писать лучше в машинных кодах (но тут свои проблемы и ньюансы).
Всё задумывалось только ради того, чтобы перевести язык, который понимает человек в язык, который понимает машина.
Вы можете гибко управлять так называемой "трансляцией кода" - гуглить "единица трансляции". Несколько языков объединить тоже не проблема. Можно всё, вопрос только конкретно в ваших умениях и желаниях.
Да, Лисп без скобок будет прекрасен, если работать с ним визуально в форме дерева. Особенно там, где нужно осложнить использование GPT, т.е. в учебных целях.
и всё равно, непонятно, почему бинарный, а не, наример, получеловекочитаемый xml.
man GIMPLE
Причем гнушники настолько упоролись, что идею автора ЗАПРЕТИЛИ, то есть лицензия на GIMPLE-файлы, которые внутри генерит gcc, и на бинарники на выходе - разная, и GIMPLE распространять какбы нельзя.
В современном мире никто не программирует в .txt файлах без подсветки
Вот тут самая новая интерпретация этой идеи, насколько мне известно: https://www.unison-lang.org/docs/the-big-idea/
В универе где я учился, один студент из прошлых потоков в качестве дипломной работы написал IDE работающую по похожему принципу: каждая программа хранилась в памяти как синтаксическое дерево, сохранялось на диск это дерево в виде XML. Формат программы был кастомный, не привязанный к какому-либо языку программирования, эта IDE являлась одновременно и редактором, и интерпретатором, но зато в редакторе можно было "переключать" язык программирования — как итог, одна и та же программа могла одним челком мыши превратиться из программы на C++ в программу на Java, Python, и т.д., при этом внутреннее представление программы никак не изменялось.
Естественно, проект был сугубо образовательный и о настоящей поддержке всех этих языков речь не идёт, это была просто имитация синтаксиса, а ввод/ввывод происходил через самописную прослойку в интерпретаторе, но этого было достаточно чтобы на нём обучали первокурсников алгоритмам, в том числе и ничего не подозревающего меня, который на тот момент был знаком только с Turbo Pascal.
Заминусованный пост который я написал 13 лет назад https://habr.com/ru/articles/118525/
Там я упоминаю realaxy, вот можно почитать остатки древних текстов https://habr.com/ru/articles/96358/
Я правильно понимаю, что весь пост написан только ради плашки "Задонатить"?
Хранение и обработка AST – вещь абсолютно очевидная и все давно её обдумали, но что-то никто не торопится делать.
Я правильно понимаю, что весь пост написан только ради плашки "Задонатить"?
А как Вы догадались?
Хранение и обработка AST – вещь абсолютно очевидная и все давно её обдумали, но что-то никто не торопится делать.
Ну почему, сделали - precompiled headers.
Я, пожалуй, неточно и недостаточно понятно выразился. Имел в виду именно хранение и обработку как автор в посте предлагает – вместо исходников (когда представление для программиста тоже делается из AST, и с ним работают редактор и vcs).
Ну а так ещё можно назвать lisp и haskel – когда выполнение программы по сути сводится к последовательности преобразований AST.
Ну а так ещё можно назвать lisp и haskel – когда выполнение программы по сути сводится к последовательности преобразований AST.
Graph reduction - это, всё-таки, не последовательность преобразований AST.
Я узнал буквально в этом году, что есть такой стиль написания интерпретаторов как substitutional, в дополнение к обычным стилям "операционной семантики малого шага", "операционной семантики большого шага" и "денотационной". Вот подстановочные интерпретаторы - это действительно переписывание AST.
Очень давно была IDE Gupta SQLWindows со своим языком программирования. Код программы выглядел как дерево и редактировался только в IDE. Не помню, как там хранился код – в текстовом или бинарном виде, но даже если формат был текстовым, он не был предназначен для редактирования в текстовом редакторе.
Внезапно...XIB-файлы используемые при разработке под iOS/macOS, в теории это нечто XML-подобное но вот править их без Xcode...не очень хорошая идея.
О да! Там было два формата. Бинарный и текстовый.
Бинарный был основным, но вечно глючил и ломался. Текстовый безбожно тормозил (нелинейное замедление от размера файла), но был относительно предсказуем и стабилен (и его можно было положить в систему хранения версий (не то чтобы совсем хорошо, но хоть как-то работало по сравнению с бинарным)).
А внутри там было закодированное дерево, очень похожее даже не на байт-код, а на шитый код. Текстовое представление было соответственно каким-то экспортным форматом.
Как вспомню, так вздрогну. Не надо так.
Лет 20 назад, я писал на Visual FoxPro, вот там весь код лежал не простым текстом, а именно в бинарном формате. И хотелось мне сделать систему анализа, чтобы и искало быстро и говорила, откуда какая функция вызывается и давало подсказки где что реализовано и с какими аргументами. Там ведь еще фишка была, что функции были связаны и с интерфесом и с базой данных.
В общем, все то что сейчас делается современными IDE, но чего в Visual FoxPro не было. По идее это позволило бы сильно упростить наши огромные системы. И мне пришлось искать описание формата, искать как его парсить и т.д. Ужасно много ненужной работы. А было бы все в текстовых файлах - все можно сделать бы намного легче.
Так что нафиг, нафиг. Это способ привязать все под вендер-лок своей IDE, никто не будет переписывать git, bitbuket; svn под этот формат, потом писать десяток IDE и т.д.
Это значит один язык, одна система контроля версий, один IDE, один механизм сборки, если что-то не нравится - старадай или уходи на другой стек/язык. Оно вам надо?
P.S. Как раз IDE именно так и делают индексацию, по-идее именно так и хранят ваш код, только проверяют, что контрольная сумма текстовых файлов совпадает с бинарным индексом. Пока вы работает в той же IDE - никакой индексации не нужно. Зато у вас всегда есть возможность использовать другую IDE или вообще открыть в блокноте.
P.P.S. А как вы планируете подружить ваш бинарный код с github'ом, например? Возможность быстро на github'е что-то найти и сразу посмотреть код - огромная польза, а я очень сомневаюсь, что github будет переписывать свою систему под подобный формат хранения.
Ещё макросы в MS офисных документах.
Для IDE ситуация намного сложнее из-за необходимости обрабатывать программы с ошибками (ну, недописали вы функцию – что ж, лишать вас подсветки?)
Если б редактор оперировал только корректным кодом (ну там, скобки вставляются всегда парами и тому подобное) – тут стало бы проще, но это создаёт кучу других неудобств.
Предложенная "технология" называется "прекомпиляцией".
Лет её уже далеко не один десяток, и здесь важно понимать, что исходный код в виде текста (даже разукрашенного) - это для людей, а "прекомпилированные" хидеры это уже другое - это для компилятора (хотя то же для людей, чтоб не ожидали "за зря" пока весь код "рассосется" ко спискам и массивам компилятора).
Эта технология давно используется почти всеми компиляторами С/С++ и Дельфи (и пр. Паскалями).
Единственное что - редакторы исходных кодов её практически не используют, смысла нет - представьте, вы добавили, для улучшения читабельности текста по паре пробелов в паре строк, один комментарий и пару пустых строк...
Для компилятора - это бесполезная информация, а для другого разраба - оч-даже полезная. Вот так...
Ну и на последок, для примера - раньше был такой формат файлов - точка-ДОК (.doc), мало кто умел его редактировать без потерь в выразительности/дизайне.
А потом появился формат ДОК-Икс (.docx) - и его теперь не умеет редактировать только совсем ленивый.
Все тут объяснили автору, почему так лучше не делать, а разработчики в Egosoft упоролись и сделали это для скриптов в серии игр X. Там конечно не бинарный формат, а XML, но зато это даёт возможность применять XPath для патчинга скриптов в модах.
Для вас, автор, это, возможно будет откровением. Ваша идея не нова. Наверное это грустная новость, но приятная новость в том, что я тоже считаю такой подод классным
Так вот, именно так устроен Visual Basic и VBA. Классический VB, а не дотнет, например VB6. Код перестает быть плейтнекстом в момент загрузки с диска. Дальше IDE работает с бинарными графоподобными и RPN-подобнымм данными. Для отображения кода на экране он воссоздаются на лету — только те строки, которые нужно отрисовать.
Всем злопыхателем, которые в статье написали, что идея неудачная и её не реализовать и она спотыкнётся на синтаксически некорректных данных можете приводить это как пример и как опровержение.
Злопыхатели на VB не пишут, что вполне нормально, а для других языков потребуются титанические усилия для переписывания инструментов под такое представление кода.
Конечно, дизайн языка должен соответствовать такой концепции. Но не нужно писать «этого не может быть, потому что этого не может быть никогда», в то время как подобное десятилетиями работало (и продолжает работать, или в современных Офисах выпилили VBA? — простите, я не слежу). Такие высказывания говорят скорее о малом кругозоре. В мире чего только не бывает.
Так предложение автора - хранить код (любой существующий) в таком виде, а не использовать конкретный язык. Так то за примером далеко ходить не надо - LISP задолго до VB появился.
Полностью согласен с Вами.
Более того, программа, которую программист увидит в IDE для такой концепции, может не иметь вообще ничего общего с теми простынями программного кода, к которым все привыкли. Возможно, программа в окне IDE будет вообще состоять из нетекстовых элементов: виджеты и разные элементы графического интерфейса, иконки, вложенные блоки, сниппеты, карточки, вкладки, слои, таблицы, списки выбора и меню, экранные формы, разнообразные диаграммы, конструкторы запросов, диалоги с ИИ-ассистентом, гиперссылки, средства обеспечения версионности и форков, средства документации и планирования разработки и т.д. Какие-то данные тоже могут быть частью программы: логи, записи макросов, тест-кейсы, таблицы решений, словари и справочники и т.д. Текст вовсе не обязателен не только для хранения программного кода, но и для взаимодействия с программистом. А те модели, которые архитекторы сейчас рисуют в отрыве от программного кода (гексагональная архитектура и т.п.), станут просто частью программы.
Конечно, дизайн языка должен соответствовать такой концепции.
Начиная с того, что классические блочные комментарии типа
if( true/* Hello world! */ )
будет очень больно запихивать в Parsetree.
У Эппла раньше AppleScript так же работал, хранил код в своем представлении, мог каждому пользователю показать одну и ту же программу на его языке (не в смысле языка программирования, а в смысле китайского / греческого).
Когда только начинал прогать, мне пришла в голову мысль, что plain text- это как-то куце. В программе есть структура, логика, и хочется к этой логике обращаться как-то напрямую, минуя костыль в виде языка. Правда это может слишком философски звучит). Вот взять Word и Latex - современное программирование это Latex. Но есть же WYSIWYG! Взять продукты Борланда - это кажется ближе к тому, что могло бы быть в идеальном мире. У National Instrments есть Lab View - среда которая не язык программирования, но в которой можно создавать программы и работать с их девайсами - рисуя картинки, стрелочки, перетаскивая пиктограммки, и т.п... Правда есть и LabWindows - всё то же самое, но в виде языка. Возможно, мы слишком сильно привыкли к языкам как к промежуточному (увы, костыльному!) визуально-смысловому слою.
В 2024 году кто-то ещё спорит про табы и пробелы. facepalm
Просто храните папку с исходниками на сжатом диске. Например встроенный в windows механизм сжатия, очень хорошо уменьшает размер исходников на диске. В разы.
Вы только что заново изобрели MCIL
В движке Unreal Engine есть blueprints – нечто похожее
Здравая мысль в этой идее есть. Но, возможно, не там, где думает автор.
В исходном виде эта идея проблематична... в момент попытки оторвать AST-дерево от синтаксиса. «А что, Go и Python, это ж примерно одно и то же, только синтаксис разный – так что давайте переключалку между синтаксисами сделаем».
Да вот нет. Сотни языков программирования придуманы не потому, что «одним нравится писать BEGIN / END, другим фигурные скобочки, а третьим круглые».
А, например, потому, что одним нравится воспринимать весь код как данные, и писать функции, способные работать с последовательностью statement-ов точно так же, как с последовательностью целых чисел. Другим – писать математику изначально, на уровне языка, векторизованно. Третьим – иметь строжайшую и надёжнейшую типизацию на уровне языка (при этом автоматически выводимую), четвёртым – не иметь никакой строгости в типизации и не париться по ней до момента запуска, когда в одной переменной может оказаться и строка, и число, и свиной хрящик. Пятым – иметь на уровне языка контроль над AST и возможность написать макросы, работающие прямо с деревом кода, шестым – на уровне языка иметь возможность написать макросы, работающие исключительно с исходным кодом.
Попытка сделать «универсальный AST для всех языков» была бы, мягко скажем, сложна. Jack of all trades, master of none.
... зато как только мы осознаём, что «AST – это вообще специфика конкретного языка, и AST для Rust-а будет заметно отличаться от AST для SQL»,... мы видим, что идея работает значительно лучше. Н
Любая качественная современная IDE всё равно строит такое дерево внутри себя. Позволяет делать крутые операции, работающие именно с семантикой кода, а не с текстом; самое простое – это, например, переименовать функцию, так, что при этом изменятся и все её вызовы (а вот упоминания её в текстах, комментариях, документационных строках – изменятся или нет только по твоему выбору), а более сложное, например – это рефакторить целый метод, вытаскивая его в функцию или поднимая в иерархии классов.
А вот что многие такие IDE не делают до сих пор, кажется – это не делают синтаксически-специфичные diff-ы. Как-то как пошла десятки лет назад идея делать «diff-ы на уровне текста» – так до сих пор и тянется; и массово используемый git со своими патчами только поддерживает её.
Было бы очень удобно, если бы появился и вошёл в массы инструментария для дифф-патчинга, понимающий именно синтаксис кода (и да, разумеется, его пришлось бы научить AST-ам всех языков отдельно – а без этого он бы работал по старинке, «с исходником»).
Не «в файле удалено 60 строк, добавлено 60 строк», а «перетащил метод replaceItem и поставил перед методом deleteItem, а не после, как было раньше; но не изменил ни буковки».
Не «20 строк модифицировано где-то внутри себя», а «переименовал переменную цикла i в index».
Не «в 30 файлах удалено по 30 строк, добавилось по 20, в одном появилось 50 строк», а «в TreeModel, HouseModel, GunModel, WolfModel, HumanModel, PlayerModel был выпилен метод render, который у всех имел почти одинаковую реализацию (AST которой во многом был похож во всех моделях), и различался только логикой создания в мире, зато появился классо-специфичный метод instantiate; зато у BaseModel появился тот самый новый метод render, общий для всех, и абстрактный метод instantiate (вызываемый render-ом); и кстати, при массовом рефакторинге ты лажанулся и забыл, что PlayerModel::render вызывал ещё predictMovement – и ты удалил его –, вызов которого был только в его AST, но отсутствовал во всех остальных похожих зарефакторенных».
Недавно возникало как раз такое желание в ходе ревью, да - написать какой-нибудь такой diff, который показал бы, что да, вот этот кусок кода действительно переехал из функции в функцию без изменений, сравнивать глазами построчно не требуется. Приятно видеть, что я такой не один.
Было бы очень удобно, если бы появился и вошёл в массы инструментария для дифф-патчинга, понимающий именно синтаксис кода (и да, разумеется, его пришлось бы научить AST-ам всех языков отдельно – а без этого он бы работал по старинке, «с исходником»).
Мне кажется, что оно ломается об алгоритмическую сложность (сравнение деревьев и графов). Плюс - большие сложности с отображение такого диффа. Построчный - более-менее все научилиь понимать, а вот это
"Не «в 30 файлах удалено по 30 строк, добавилось по 20, в одном появилось 50 строк»
...
но отсутствовал во всех остальных похожих зарефакторенных»
показать невозможно. Или отображение вырождается в тот же построчный "тут добавилось/тут убралось/тут изменилось"
Кроме того, diff для хранения изменений в общем случае - не тот же самый, что для отображения. "diff-ы на уровне текста" - это про более-менее про хранение, которое в случае чего и прочитать можно. А восстановить по ним две версии файла(ов) и показать их различия так как хочется, включая "тут сделали рефакторинг" - это уже немного другая задача.
показать невозможно.
Возможно, получится, если (в двадцатых годах двадцать первого века) изначально быть готовым визуализировать это не «средствами TTY-консоли с ASCII-символами», а ну хотя бы с 2D-анимацией.
Но да, вы правы, я в первую очередь про «diff-инструментарий для отображения», а не про «diff для патчинга файлов».
показать невозможно
Это - мелкие изменения. И, как я понимаю, просто при отображении игнорирует несущественное для семантики форматирование. Такое - полезно и возможно. Хотя тот пример, что они показывают - сработает и без всякого сравнения бинарного представления, а просто <как было> и <как стало> нужно сначала форматнуть под один стиль и потом уже diff-ать.
В том же сообщении, на которое я отвечал, предлагалось как-то отображать здоровенный такой рефакторинг, который знает, что мы вот эти функции заменили на эту, по дороге применив небольшую кучку шаблонов кодирования.
Среди прочих отмеченных в комментариях реализаций, отмечу компанию Intentional programming. Некий миллионер и космонавт Charles Simonyi развлекался, уйдя из Майкрософт. Ничего полезного, насколько мне известно, не вышло, но на Ютьюбе много видео их демок.
т.е., бинарный формат предполагает особый формат - типы/метки, особый вид кодирования. Обратная совместимость, вот это вот всё.
А ПО это что такое? Программное обеспечение. Т.е., предполагает, что будет меняться, улучшаться.
Вот надо изменить дерево (например, сделать дерево не деревом), как-то по другому перекодировать, ускорить. Чо делать со старыми IDE? еще и с таким разнообразием разных производителей. Чо делать с новыми - тащить поддержку старых форматов с самых первых версий?
А обратно как в текст? Разработка это не про машины, а про людей. 10 строчек читаем, 1 пишем.
IDE и так оптимизируют и хранят промежуточные состояния, которые изменяют инкрементально и только при изменении исходного текста. Всё уже давно придумано за нас и до нас.
Я бы накрутил функций IDE. Можно до неузнаваемости все преобразить. Не голый текст, а полноценный многослойный мультимедийный документ. Разные цветные шрифты, в коментах рисунки, графики, таблицы. Можно диаграммы с стрелочками рисовать. Автоматом генерируется документация. А для компилятора может отдельно голый текст лежать.
Похожее уже есть в математических пакетах.
Не голый текст, а полноценный многослойный мультимедийный документ.
literate programming давно изобретено. Именно у программистов - не взлетело. Потому что программисты, судя по всему именно тексты (а не программы) писать не обучены. Смотри любое обсуждение про (не)нужность документации и комментариев.
Это про другое совсем. Это предлагается другой язык изобрести. Я говорю о добавлении возможностей редактора.
Ну например так:
Мне казалось, как раз почти про это. Literate programming было как раз, практически, про код, сопровождаемый текстом. Максимум, нужен препроцессор и они есть.
Но у просто программистов - не работает. Мы даже про комментарии постоянно говорим что 'не надо'. Потому что код с текстом разъезжаются и так далее. А там, где имеет смысл - то успешно делают. Все эти workbook в питоне, математике и прочем (это что на картинке было?) - народ пользуется.
Вот только - теперь попробуем мерж изменений от двух человек сделать. И сразу выясняется, что нужно отдельный инструмент визуализации делать, а git или другая стандартная VC по текстовым файлам - универсальные.
Это уже было в GW-BASIC, а в Q-BASIC от этого отказались.
Отличная идея. Была актуальной лет 30 назад. Когда компьютеры были медленные.
Но и тогда уже была реализована (предварительно скомпилированные модуля, как минимум в Pascal/Delphi и C/C++ точно. Наверняка где-то еще)
На сегодня современные IDE на лету, по мере редактирования исходников, выстравивают у оперативной памяти синтаксическое дерево. И результате все эти прекрасные подсказки и автоформатирования мгновенно выполняются IDE как раз с помощью вашей идеи.
Которая уже реализована много лет как.
Но чуть иначе.
Ну вот есть такой код
int a = 2;
Покажите, как он будет выглядеть в бинарном виде?
Да примерно так же и будет. Ну будет вместо 3 символов 'i', 'n', 't' двухбайтовый T_INT = 0x0004. Принципиальной разницы нет, это просто другая форма записи.
Похоже на Smalltalk.
Дизассемблер
Хранение AST - идея далеко не новая. Собственно, те кто занимался транспиляцией одного языка в другой часто примерно так и делают - сохраняют ast в одном языке и проворачивают фарш в обратно, выплёвывая код программы на уже другом языке. Разные языке имеют разные подводные камни с этим связанные. Так, например, импортирование модулей/юнитов трансляции в C++, python, Java и Rust будет заметно отличаться.
Если вы когда-нибудь копали в сторону языковых серверов, то там опять же часто существует шаг индексации, который обычно генерит некоторую бинарную структуру.
Если ещё не смотрели в сторону tree-sitter, то настоятельно рекомендую. А ещё попробовать поработать с этим в каком-нибудь neovim - там есть плагины, которые позволяют явно работать с ast, позволяя встраивать одни языки в другие: например раскрашивать блоки кода в markdown или sql запросы в строковых литералах произвольного языка.
Идея хранить AST вместо текста где-то полгода назад мелькала на форуме Скалы. Храним AST, представляем в виде удобного для читающего языка программирования. А теперь представьте, что вам нужно заревьюить чужой PR...
Можно и читать справа-налево, вопрос только зачем? Лично мне читать код без пробелов и табуляции представляется сложнее, чем с ними.
Будет ли удобнее читать код в виде дерева? Мы и так видим его как дерево за счёт сворачивания между {...}. А вот может ли выглядеть дерево подругому? С одной стороны с ООП линейность выполнения кода отсутствует, с другой ООП сам по себе делает код логично выстроенным.
Итак что вопрос не столько о пробелах-табуляциях, сколько о более удобном для мозга восприятия, но для этого сейчас пишут новые языки-фреймворки.
ДумаючтовашутеориюможнобылобыпроверитьплагиномдляIDE,которыйпоказываеткодбезпробеловитабуляций-иследуюшимэтапомотказатьсяотзнаковпрепинания.
Книжки надо читать!
Страуструп в книжке Дизайн и эволюция С++ давно уже эту идею описал: IDE должна быть языково-ориентирована.
То есть, Вы считаете что конверсия текстового кода в бинарный это дорого, поэтому хотите чтобы это происходило не один раз при компиляции, а каждый раз при редактировании.
Я правильно понял?
Помимо AST в коде есть много мета-информации. Комментарии те же. Функции, которые я не видеть в виде инлайнов. Много чего.
...то получится что-то как в Basic на ZX-Spectrum (там ключевые слова в виде кодов хранились). И никаких вопросов вроде отступов табами/пробелами или позиций фигурных скобок)
Написал в телеге продолжение, скопирую сюда:
По чесноку, я и сам не уверен, что замена тексту может быть реальной в текущей ситуации, это скорее просто тема на поболтать. Тем не менее, интуиция мне подсказывает, что текст для описания логики работы программы - это скорее неизбежный костыль, чем оптимальный инструмент. Т.е. мысль "так работал бейсик в спектруме, но не зашло" меня не удовлетворяет.
Вот еще пара вещей на подумать:
1) Часто в начале каждого файла пишут огромный комент про лицензию и прочую дичь. IDE не скрывает такой комент, потому что для нее это просто какой-то комментарий. В случае бинарных исходников можно было бы это хранить в мета-информации и показывать только особо жаждущим по отдельной кнопке.
2) мат формулы можно было бы рисовать как матформулы, многоэтажно, если ввести спец конструкцию языка/IDE для этого.
3) тесты часто прогоняют по табличным данным, чтобы проверить разные кейсы. Эти данные зачастую выглядят как массив массивов или типа того. Почему бы не сделать конструкцию "таблица" и не рисовать это юзеру в виде, собственно, таблицы
3) комментарии вида javadoc/phpdoc тоже можно прибивать к самому классу/методу и показывать только при наведении курсора, чтобы не засирать экран хернёй.
4) если упороться, то можно отказаться от файлов совсем, и приложение рисовать как некую miro-диаграмму, кружочки-стрелочки и всё такое
5) вместо пачки ифов, где-то можно было бы рисовать прям таблицу состояний и переходов, это было бы нагляднее
6) картинки можно эмбедить прямо в исходник и там же видеть привьюшку
7) кстати, можно комментарии снабжать рисунками, а не ссылками на доку или псевдографикой
Диаграммы в labview рисуют. Нууу... я бы хотел чтобы свободно конвертировалась диаграмма в текст и наоборот. Некоторые куски лучше текстом набить чем 3 экрана квадратиков в запутанной сети стрелок.
Часто в начале каждого файла пишут огромный комент про лицензию и прочую дичь. IDE не скрывает такой комент
имхуется мне что это фича а не баг. Разве есть ЯП которые требуют такого коммента? Скорее его добавляют туда с другой целью... например мозолить глаза залётным
Реальных преимуществ хранения исходных кодов в бинарном виде не видно. А вот что можно было бы сделать, на мой взгляд, так это добавить в IDE возможность "на лету" применять индивидуальные для разработчика правила форматирования: пусть каждый видит то, что ему удобнее, табы, пробелы, скобки и запятые на нужной строке, комфортное количество пустых строк между методами и так далее. В таком случае исходники остаются легко читаемыми и редактируемыми в любом текстовом редакторе и в то же время в IDE каждый видит код именно с таким форматированием, к которому привык. Изменения сохранять с неким "усредненным" автоматическим форматированием.
Можно сказать что табы изначально служили именно этой идее - показывать на каждой системе индивидуально настроенное представление одного и того же текста путём задания ширины таба.
PS Комментарии типа "забей", "просто привыкни" нахожу неприемлимыми в эпоху избытка доступных вычислительных ресурсов и больших лингвистических моделей, бороздящих просторы Большого театра.
Сколько же внимания такому высеру опусу
в лучшем случае у нас появятся иде с фоновым синтаксическим разбором кода ещё в процессе его написания и грамотным кэшированием этого всего..
Макросы в плюсах: *не поняли прикола*
Вы только что изобрели PowerBuilder. Там всё так и реализовано.
О, это была моя дипломная работа в университете.
Если взять для начала C/C++, где парится и исходный код проекта, и заголовки библиотек. То у C# в библиотеках метаданные в DLL, и не требуется их разбирать. По сути гибридный подход. И меньше файлов читать при вычитывнии всего что там есть. Ведь быстрее будет прочитать меньше по количеству файлов, но больше по содержимому.
Ну делать бинарный формат исходных кодов разрабатываемого проекта - думаю это будет пока ещё не очень удобно.
А вот если взять пример NodeJS, когда там node_modules как тонна файлов. Вот это очень неудобно, там слишком много файлов. Иногда даже итоговый путь не укладывается в 256 символов. Вот там пригодилось бы какое-то контенизированре хотя бы на этом этапе.
При предложенном подходе (я про структурированный не равно бинарный) когда нибудь появятся IDE в которых мы будем выбирать например стиль операторных "скобок" (именно скобки или различные begin-end) как сейчас выбираем стиль и подсветку.
p.s. живу давно. Первая, полезная кому то, моя программа набиралась в 8-х кодах с пульта Урал-11 без подсветки :)
Первая, полезная кому то, моя программа набиралась в 8-х кодах с пульта Урал-11 без подсветки :)
Ви так говорите, как будто на пульте лампочек не было!
Сомневаюсь. Это не rocket science и несложно реализуемо, но никто не захотел тратить на это время
Кроме стиля скобок например объявления переменных var,let,def,dcl, ... перед или после имени и множества обозначений достаточно ограниченного количества типов. Это всё мы тоже сможем выбирать как подсветку сейчас. А комментарии, показывать или нет, все или только перед строкой без хвостовых или с ними и т.д. и т.п.
Так и это не сложно. Но нигде не реализовано, потому что не стоит вложенных усилий
Такие вещи переодически делаются - байт-код Java можно посмотреть на любом JDK языке, можно автоматически преобразовать программу на Java в Kotlin или Scala (обратно тоже можно, но не всегда красиво и с помощью плагинов), вроде в Net можно из любого подерживаемого языка получить исходники на другом. Из TypeScript можно автоматом посмотреть исходники на JS и т.п.
Но все это имеет мало смысла, так как какие кастомные вещи будут мешать читать код в гите или на компе у вашего товарища. Ну вот сейчас можно в веб версии gitlab'a / bitbucket посмотреть изменения, то в вашей версии придется все грузить в IDE или ломать себя, вспоминая как в общей версии все называется.
В книжках, статьях и видео уроках вам придется постоянно переучиваться с вашей стиля на стиль авторов. Мало кто будет делать миллион версий одного кода под каждую кастомную настройку.
Это почему многие предпочитают английскую версию Windows - не нужно пытаться переводить названия из англоязычных статей на русский интерфес и наооброт.
При том что все эти скобки и прочее это на самом деле очень быстро уходит в автоматизм и совершенно все равно как они называются. Через месяц-другой на новом языке вообще почти никакой разницы.
Вы изобрели IBM VisualAge. Только там ещё половина кода исходно рисовалась в виде картинок со стрелочками.
Как думаете, что можно сейчас сделать с огромным файлом dat, представляющим собой базу кодового репозитория?
А что если исходные коды программ хранить в бинарном формате?