Из минусов я вижу только необходимость специального редактора для такого кода.

Но это, конечно, пустяки.

Не нужно.

Упрощение процесса компиляции - тоже не пустяки.

ты придумал байткод. Поздравляю.

Нет. Речь об AST в качестве исходного кода, а не о низкоуровневом наборе команд.

это тоже может быть байткодом, внезапно.

Но такое нигде не используется. Речь о том, чтобы хранить вместо исходного текста уже готовое дерево синтаксиса в бинарном виде.

А если я хочу добавить выравнивание или пустую строку?

Пустая строка - специальный байт. Правила выравнивания настраиваются в редакторе.

Пятница в ночь на среду?

храни жава-байткод и пользуйся декомпилятором при получении.

Это могло бы значительно увеличить скорость компиляции (так как не надо парсить текст)

Про «значительно» ты загнул.

веяние времени

В духе бинарных логов системД.

Я думаю, что при текущих оптимизациях компиляторов это не имеет смысла.
К тому же, как ты будешь камменты хранит?

Но такое нигде не используется.

Java, C#. Я частенько достаю код из готового бинаря, часто даже с оригинальными именами переменных и классов. Достаточно добавить туда хранение комментариев, и получится то, что ты хочешь.

Такой подход использовался в интерпретаторе Basic ПК Spectrum. Операторы, кстати, набирались одной кнопкой.

Через hex editor вполне может заработать. Более того, те же программируемые калькуляторы для верификации вводимых данных также отображают вводимое в своих кодах - http://mk.semico.ru/tabl2.htm .

А что, текст изначально не бинарен? Или как по твоему текстовые токены парсятся? Ну да, бывает больше одного чара, и что?

Эмм... оно когда-то так и было и вместо этого придумали ЯП. Сегодня вобщем тоже можно использовать hex команды вместо ассемблерных мнемоник.

при текущих оптимизациях компиляторов

есть мнение, что оптимизации компиляторов, особенно сишки и плюсов, является адовым гогном, способным лишь на общие недалекие случаи

Форт thred/

:(

Забыл добавить, это потребуется внедрить во все редакторы. И пока не понятно как это отразится на скорости открытия/сохранения проекта с тучей файлов/кода.

+1

Поздравляю, ты изобрёл Spectrum BASIC. Так что звиняй друг, но лет на 40 ты с таким предложением опоздал.

https://ru.wikipedia.org/wiki/Форт_(язык_программирования)

в части как устроены слова.

а заход через редакторо-создание в творение своего языка: https://ru.wikipedia.org/wiki/Factor_(язык_программирования)

Но такое нигде не используется.

facepalm.jpg
Ну собственно тебе уже тут сказали как ты не прав.

Отступы пускай настраиваются, а выравнивание не сделать.

$examleObject->methodOne()
             ->methodTwo()
             ->methodThree()
             ->methodFour();

И как это grepать?

Вообще, есть языки, страдающие подобным идиотизмом. Smalltalk, например.

Интересно, что думают ЛОРовцы по этому поводу?

В 2015-м экономить на размерах текстового файла никому не интересно. С производительностью тоже спорный вопрос. За счёт чего будет выигрыш, за счёт большего времени на сохранение и открытие файлов? Будет ли он вообще заметен? Без пруф оф концепт с бенчмарками идея сама по себе плохая.

Ну, из недостатков - необходимость редактора для просмотра/редактирования кода.

А если у нас специализированный редактор, то можно пойти еще дальше. И вообще не работать с текстовым представлением программы, а модифицировать сам аст.

И diff файлов в таком случае тоже был-бы читаемее. Т.к. он определял бы только реально изменненные конструкции, а не изменение форматирования, например.

Проблема в том, что сложно реализовать удобный для ввода/редактирования редактор.

Но такая мысль посетила не только тебя одного и я знаю людей, которые даже пытаются все это дело реализовать.

Лет 16 назад будучи школотой баловался QBasic. Там исходники, если я правильно помню, хранились в бинарном виде.

Парсинг из текста в AST это очень малая доля времени компиляции.

хранить можно, возьми любую крайне закрытую поделку с возможностью написания скриптов - они часто будут храниться закрыто дабы никто не видел что за шлак там на самом деле используется. А если как ты описал, то чем это так сильно отличается от стандартных опкодов?

2015. Большинство по прежнему думают, что у СистемД бинарные логи, когда они открываются любым текстовым редактором и единственное, что при этом теряется - продвинутая навигация journald по ним

Вот же блин.

Я вот тоже раньше так думал. Но потом решил проверить. Для сишечки легко можно получить 75% времени, потраченного на парсинг. Правда, здесь, конечно, можно съехать на то, что хедеры и темплейты — говно, надо использовать правильный язык™, PCH, и прочую лабудень.

Это могло бы значительно увеличить скорость компиляции

Нет. Лексический разбор исходников времени почти не занимает.

У программистов на таком языке не было бы споров по поводу стиля кода

Споры по поводу стиля кода произрастают из потребности, чтобы код легко читался человеками и легко понимался человеками. Твой язык ничего для решения этой проблемы не предлагает.

2015. Большинство по прежнему думают, что у СистемД бинарные логи, когда они открываются любым текстовым редактором

2015. Некоторые до сих пор думают, что текстовые редакторы не умеют открывать бинарные файлы.

sizeof(SOME_INTEGER_CONSTANT) != sizeof("some textual source code")

Текстовые потоки данных и бинарные - это совсем разные вещи. Как гласит философия Unix, «Пишите программы, которые бы поддерживали текстовые потоки, поскольку это универсальный интерфейс.» Однако, такой подход тормознее бинарных потоков.

AST или что-то подобное в качестве исходного кода - это совсем не байткод (в контексте, например, JVM) или тем более не текст.

Кроме возможности поддержки различных текстовых редакторов, нет причины (ИМХО) хранить код в тексте, так как он подчиняется особым строгим правилам и не использует все комбинации, которые можно записать в тексте.

Редактор такого гипотетического формата мог бы представлять код программисту в зависимости от настроек. Это нечто похожее на gofmt, только работает с представлением на экране, а не с текстом.

Не, я (тоже образно) про типа такое:

strncmp(IF_TOKEN, "if", 2)

Если прогнешься под конпелятор, то получишь очередной брейнфак, если прогнешься под человека, то вернешься к обычному текстовому синтаксису. А железка — она не устанет анализировать и конпелять. Тогда смысл?

Компиляция быстрее не будет, природу не обманешь. Просто ты зачем-то пытаешься переложить часть функций компилятора на редактор. На редактор! Ты бы ещё на файловую систему попробовал!

А как грепать и дифф снимать ты подумал?

Редактор не транслирует туда-сюда. То, что видит программист - это не текст, а элементы графического интерфейса, расставленные после интерпретации бинарника.

Поиск и дифф нужны тоже специальные, об этом я не забыл.

Редактор не транслирует туда-сюда.

Подумай ещё раз. Природу не обманешь. Что бы он ни делал - это будет трансляцией туда-сюда на каком-нибудь из этапов.

То, что видит программист - это не текст, а элементы графического интерфейса

Лицопальма.

Лицопальма.

Почему?
Допустим, программист создаёт новый файл. Перед ним лишь одно поле, в которое он вводит, например, «import». Редактор подхватывает это ключевое слово, записывает соответствующий опкод. Программист же тем временем пишет во второе поле, которое расставлено в расположении, заданном в настройках стиля кода. Редактор предлагает имена пакетов для импорта. На следующей строке (которая на самом деле лишь продолжение бинарного потока, представленное новой строкой в пространстве редактирования) разработчик записывает: «whl» - в данный момент ввод идентификатора не применим, а ключевого слова такого нет, редактор ничего не делает.

То, что видит программист - это не текст, а элементы графического интерфейса

Лицопальма.

Я имел в виду, что не происходит трансляции туда-сюда, программист бы редактировал поля, а не гибкий текст.

Но такое нигде не используется.

В питоне разве не оно?