Комментарии 99
Это просто не нужно.
Если у вас есть инструмент в IDE, который преобразует вводимый программистом текст в какое-то "расширенное представление", то пусть IDE где-нибудь это расширенное представление и хранит, а исходники не трогает.
Тогда и IDE хранит какие-то свои необходимые данные и быстро работает с проектом, и программист может работать в nano, отслеживать изменения при помощи git, и т.д.
Это просто не нужно.
Это слегка нужно когда приходит время сравнить изменения в исходниках не посимвольно а с учетом семантики. Ну то есть зашел какой-то Вася и заменил все табы на пробелы. С точки зрения обычного diff в исходнике изменилось чуть менее, чем всё. Если сравнивать такой вот байт-код, то не поменялось ничего. Ситуация с табами и пробелами, конечно, предельно надуманная - её можно митигировать линтерами, а Васе можно дать по рукам. Но в реальности всплывают всякие штуки, когда посимвольное сравнение только отвлекает от важных дел.
Обычно diff инструменты имеют настройку для игнорирования таблв и пробелов. Во всяком случае графические надстройки.
Почти в любом достаточно большом проекте с нетривиальным количеством участников огромное количество времени тратится на чтение кода. Намерение кода гораздо важнее того, как код выглядит в виде дерева. Поэтому, как ниже уже отметили, удобство человека гораздо важнее удобства компилятора.
Так что линтеры, которые сразу бьют по рукам 🙂
Я вот чо-то не могу читать код на C-подобных языках, когда фигурная скобка не переносится на новую строку, типа чего-то такого
if(true.toStr().length == 4){
blah_blah();
}else{
вжух_вжух_магия();
}Ну, не то чтобы прям физически, технически не могу, скорее в смысле "не могу аш трисет". Когда последние крайние последние разы приходилось работать с подобным гов..., года уже были не те, чтобы в припадке благородной ярости переформатировать всё "под себя", искал авто-форматтеры, чтобы можно было отформатировать в удобный для меня формат, а перед коммитом переделать как было - "туда" было легко, а "обратно" - нет, ни один из распространённых стилей не совпадал с этой хернёй, которую нагородили дорогие коллеги (а надо ж чтоб символ в символ совпадало, чтоб файл не коммитился как изменённый и дифф не ругался). Написать своё было недолго, дольше было тестировать, что действительно конвертация туда-сюда нигде ничего не меняет. Возможно, внутреннее представление исходника в некотором универсальном формате тут могло бы помочь - мне отображай код вот так, а Васе вот эдак, а внутри всё до байта идентично.
Была у меня похожая ситуация с trailing commas в питоне. Техдиру они не нравятся категорически, а с форматтерами (особенно настраиваемыми) в питоне все довольно грустно, во всяком случае после js/ts. После долгих исканий, модифицировал библиотеку которая эти запятые наоборот добавляет. По итогу форматтер сначала вызывает black, а потом модифицированную либу. Заодно разобрался с расширениями под vscode, чтобы свой форматтер туда прикрутить.
просто дело привычки
В таких случаях помогает упражнение с рукой: поднимаете правую руку вверх, потом резко опускаете, и синхронно говорите "ну и ... с ним".
Забейте, короче, оно того не стоит. Но вообще, если не ошибаюсь, по-умолчанию Шланг-формат так делает.
Уж проще сесть и написать для IDE плагин с умным автоформатом, который будет исходники переводить под корпоративный стиль перед мержом в мастер.
Вы изобрели байт-код, который делается в некоторых языках (например PHP).
Только при чем тут код исходный? Само слово "исходный" намекает на первоначальность.
Это для рекламы ТГ канала вы этот бред написали?
Простите, а вы не знаете, почему тг сейчас так часто рекламируют? Я просто реально не могу это понять, что за "хайп" сейчас такой, это ведь ничего вроде как не дает оО
Чтобы набрать аудиторию, на которую потом транслировать булшит от рекламодателей и получать за это деньги
У каналов в Телеге довольно высокая и при этом простая монетизируемость.
Иван Иванович работает. Вот как он всегда работал. И за это ему платят зарплату. А с 1 января он может дополнительно получать деньги, если всем своим коллегам будет во время разговоров показывать рекламу.
По дороге с работы Иван Иванович едет на автобусе. Вот как он всегда ездит. А с 1 января он может за отдельные деньги всем людям в этом автобусе показывать рекламу.
Потом Иван Иванович приезжает домой, а летом ещё и по выходным ездит на дачу. А с 1 января он может за дополнительную оплату и своей семье, и соседям по даче, и гостям показывать рекламу.
— Дополнительные!!! Деньги!!! За обычную жизнь!!!
Разве это не делает телеграм лучшей программой, которую создали люди?
Это для рекламы ТГ канала вы этот бред написали?
Рак, сэр. Рак пускает метастазы.
99% статей что-то рекламируют. Или свои телеграм-каналы, или продукты компаний, или сами эти компании.
Это всё четко разрешено правилами: можно вставлять рекламную ссылку на свой блог. Хабр специально это разрешил пару лет назад.
Да что там говорить, сам Хабр существует только для того, чтобы получать деньги с рекламодателей и с платных блогов компаний! Без рекламы не будет вообще никаких статей и Хабра тоже.
Но нет, каждый раз находится человек, отрицающий объективную реальность, и пишет "разгромные" статьи про "рак".
Вопрос табов или пробелов решается форматированием кода перед коммитом и после чекаута. Вы можете настроить хук и весь код в репозитории будет причесан по вашему вкусу.
Хранить индексы и внутреннюю информацию о коде, которую понимает о нем компилятор в репозитории смысла нет. Потому что и информация и формат может меняться по мере обновления компилятора или других компонентов среды. Да еще и избыточность высокая.
Отличная идея!
Но она уже была реализована в компьютерах Sinclair ZX Spectrum там ввод программы с клавиатуры осуществлялся сразу токенами , или ключевыми словами языка Basic. Для этого использовалась комбинация спец клавиши и названия функции на клавиатуре. Если вводить название функции символами клавиатуры - то не работало.
Это был интерпретатор , но он работал гораздо быстрее других.
Тоже первая мысль была - "миллениалы придумали ZX Spectrum". :-)
Чуть круче делали компиляторы с Ассемблера: парсили ручками написанные мнемоники сразу после ввода / редактирования строки. Всякие там TASM, MASM, MARASM (могу путать названия).
ввод еще ладно, в спектруме хранение бейсик программы в памяти хранилось в таком виде.
Как и в БК-010-01, там тоже частично.
А, да, пробовали. LISP называется:)
1) При совместной разработке задача управления версиями важнее чуть более быстрой компиляции. Для этого формата надо писать свой git.
2) Синтаксически абсурдный текст (скажем, вставленный не туда copy-paste) может сильно напрячь эту систему. Вообще понятие "вставки" в терминах текста превращается в сложное преобразование дерева. Я начал набирать `int foo(char, ` и весь последующий текст в смысле подлежащего дерева превратился в тарабарщину.
3) Хранение любой служебной информации IDE упирается в требования обратной совместимости.
4) Если у меня почему-то сломалась IDE сейчас, или мне надо что-то поправить, а под рукой только планшет, или мне нужно править исходники через ssh, я могу открыть файл кода одним из 100500 редакторов. В дивном новом мире это ква, разработки без IDE не бывает.
0) Комментарии!!!
Комментарии в этой схеме изящно превращаются в метаданные, выкидываемые при сборке. Что только пойдёт им на пользу. Потому что кому нужны упоротые сценарии «вставим ровно 137 пробелов в конце 17-й строки и напишем комментарий там», когда есть привязка комментария к оператору, группе операторов или скоупу? На уровне UI это можно оформить как bubble boxes.
Возражение №2 обойти труднее. По классике оно формулируется так: когда из одного правильного состояния можно попасть в другое правильное состояние только через неправильное, невозможна система, требующая постоянного нахождения в правильном состоянии. В «Спектруме» такую систему построили за счёт тотального урезания редактирования (по принципу «нет поддержки буфера — нет проблемы»). Мало кто согласится сейчас так программировать.
Шутки ради... 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-код
SVG?
А их нельзя хранить текстом. Хотя, с развитием нейросетей, наверное, можно будет... Равки же занимают очень много места.
Да можно, просто нужно подобрать подходящий архиватор, которые зархивирует их до адекватного размера (повторяющиеся куски текста это вообще идеально для большинства архиваторов). Но получится тот же JPG просто с другого бока. Ну ладно - почти тот же, так как там не будет потерь, а значит архив будет большого размера.
Ну, графику тяжело хранить в виде текста. И да, это проблема - даже сейчас половина реализаций так и не научились правильно читать заголовок JPEG и показывают картинки не "лёжа на боку".
Ну, графику тяжело хранить в виде текста.
"На фотографии изобажена девушка с третьим размером в белом платье на фоне моря, задумчиво глядящая на плывущий вдалеке корабль с алыми парусами".
IDE, которые работают с текстовыми исходниками, но не умеют не то что рефакторинг, а и более прозаические вещи. я тоже встречал.
Ну, графику тяжело хранить в виде текста.
SVG с вами не согласен :D
Ну, графику тяжело хранить в виде текста.
Формат XPM.
Имейте в виду, что в формате JPEG хранятся только те фотографии, которые больше никогда не надо менять.
А если автор предполагает, что надо будет менять, он хранит в формате без потерь.
Конечно, без потерь тоже бинарный формат, однако это он только на первый взгляд бинарный. Если смотреть внимательнее, там вполне себе текстовые символы, просто они немножко другие, потому что записывать надо не 26 знаков латинского алфавита, а 255 знаков яркостного алфавита.
Фотографии прекрасно хранятся в бинарном формате JPEG и никого не беспокоит что этот формат потеряет доступность
Потому что это просто формат архивирования. Примерно такой же как zip. Никто не мешает брать исходные коды и архивировать их каким-нибудь быстрым архиватором для того чтобы быстрее считывать в память.
фотографии да, а текст не очень. И разрешение когда-то крутых эротических фоточек 640x480 сейчас выглядит унылой порнографией.
Вы сравниваете теплое с мягким сейчас.
И у разработчиков как правила нет особого выбора
В этом месте играет 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. Она вообще не хранит код как текст. Вы его не нацдёте в памяти процесса. Даже в виде отдельных строк. И у неё вообще нет проблем с представлением синтаксически некорректных данных — просто путём введения отдельной сущности для представления некорректных стейтментов.
А что если исходные коды программ хранить в бинарном формате?
Все же зависит только от ваших умений быстро ориентироваться в машинных кодах, но тогда уж и писать лучше в машинных кодах (но тут свои проблемы и ньюансы).
Всё задумывалось только ради того, чтобы перевести язык, который понимает человек в язык, который понимает машина.
Вы можете гибко управлять так называемой "трансляцией кода" - гуглить "единица трансляции". Несколько языков объединить тоже не проблема. Можно всё, вопрос только конкретно в ваших умениях и желаниях.
Да, Лисп без скобок будет прекрасен, если работать с ним визуально в форме дерева. Особенно там, где нужно осложнить использование 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 – вещь абсолютно очевидная и все давно её обдумали, но что-то никто не торопится делать.
Очень давно была IDE Gupta SQLWindows со своим языком программирования. Код программы выглядел как дерево и редактировался только в IDE. Не помню, как там хранился код – в текстовом или бинарном виде, но даже если формат был текстовым, он не был предназначен для редактирования в текстовом редакторе.
Лет 20 назад, я писал на Visual FoxPro, вот там весь код лежал не простым текстом, а именно в бинарном формате. И хотелось мне сделать систему анализа, чтобы и искало быстро и говорила, откуда какая функция вызывается и давало подсказки где что реализовано и с какими аргументами. Там ведь еще фишка была, что функции были связаны и с интерфесом и с базой данных.
В общем, все то что сейчас делается современными IDE, но чего в Visual FoxPro не было. По идее это позволило бы сильно упростить наши огромные системы. И мне пришлось искать описание формата, искать как его парсить и т.д. Ужасно много ненужной работы. А было бы все в текстовых файлах - все можно сделать бы намного легче.
Так что нафиг, нафиг. Это способ привязать все под вендер-лок своей IDE, никто не будет переписывать git, bitbuket; svn под этот формат, потом писать десяток IDE и т.д.
Это значит один язык, одна система контроля версий, один IDE, один механизм сборки, если что-то не нравится - старадай или уходи на другой стек/язык. Оно вам надо?
P.S. Как раз IDE именно так и делают индексацию, по-идее именно так и хранят ваш код, только проверяют, что контрольная сумма текстовых файлов совпадает с бинарным индексом. Пока вы работает в той же IDE - никакой индексации не нужно. Зато у вас всегда есть возможность использовать другую IDE или вообще открыть в блокноте.
P.P.S. А как вы планируете подружить ваш бинарный код с github'ом, например? Возможность быстро на github'е что-то найти и сразу посмотреть код - огромная польза, а я очень сомневаюсь, что github будет переписывать свою систему под подобный формат хранения.
Предложенная "технология" называется "прекомпиляцией".
Лет её уже далеко не один десяток, и здесь важно понимать, что исходный код в виде текста (даже разукрашенного) - это для людей, а "прекомпилированные" хидеры это уже другое - это для компилятора (хотя то же для людей, чтоб не ожидали "за зря" пока весь код "рассосется" ко спискам и массивам компилятора).
Эта технология давно используется почти всеми компиляторами С/С++ и Дельфи (и пр. Паскалями).
Единственное что - редакторы исходных кодов её практически не используют, смысла нет - представьте, вы добавили, для улучшения читабельности текста по паре пробелов в паре строк, один комментарий и пару пустых строк...
Для компилятора - это бесполезная информация, а для другого разраба - оч-даже полезная. Вот так...
Ну и на последок, для примера - раньше был такой формат файлов - точка-ДОК (.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, но отсутствовал во всех остальных похожих зарефакторенных».
Среди прочих отмеченных в комментариях реализаций, отмечу компанию Intentional programming. Некий миллионер и космонавт Charles Simonyi развлекался, уйдя из Майкрософт. Ничего полезного, насколько мне известно, не вышло, но на Ютьюбе много видео их демок.
А что если исходные коды программ хранить в бинарном формате?