Нет, это я просто для примера изоморфизма привел изоморфность в определении анонима (т.е. как биекции) друг другу всех гладких многообразий.

• Они уже написанны.
• Они уже отлаженны.
• Там куча функций!!!
• Мне они кажуться простыми и приятными!

Ну да, новый ЯП на старых библиотеках, взлет обеспечен.

А то, плюсцы потому и взлетели!

куда они взлетели?

На 4 место в TIOBE! Твой браузер на C++, разве это не показатель?

Изоморфизм в данном контексте - это возможность получить из диаграммы код и из кода диаграмму.

Так сразу б и сказали по-русски! Повыучивают греко-латинских словес и воображают себя умными а остальных дураками, типа Lingua Latina non penis canina est:)

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

мой браузер на Kotlin

Движок на С++ же!

Не про то шла речь. Речь шла про то, что при преобразовании кода на C в вашу диаграмму при условии возможности обратного преобразования кода и диаграммы количество информации в них будет одинаковым, а следовательно и сложность написания/рисования будет тоже одинаковой. (Надоедает общаться с первоклассником, правда!)

Java, Kotlin

https://github.com/hazuki0x0/YuzuBrowser

при преобразовании кода на C в вашу диаграмму при условии возможности обратного преобразования кода и диаграммы количество информации в них будет одинаковым, а следовательно и сложность написания/рисования будет тоже одинаковой

Ну и проФФесор же вы (как Виктор Федорович Ростовский).

Вот есть архивация и деархивация текстового файла. Операция обратимая. Вам одинаково легко написать и текстовый файл, и архив, пользуясь текстовым редактором?

И сколько раз в день ловите Java Exception?

Хотя на самом деле все современные браузеры и веб - говно, просто в разной степени. Чище всего Firefox без плагинов и Tor Browser.

Скоро третью часть открывать надо будет. Пожалуй, не будем валить с ЛОРа до релиза, тут реально весело:)

Да, ark+kate или встроенный в emacs архиватор/деархиватор. Я же не дурак, чтобы использовать неподходящий инструмент вообще везде.

Ура, вы навсегда застряли на ЛОР! Я очень рад, что вы не будете загаживать остальной (нормальный) интернет, там и так достаточно вам подобных.

Мета по-украински «цель».

Хм, забавно. Но для большинства это будет просто сокращение от «метапрограммирование».

Я всё-таки не понимаю, почему ты упорно не хочешь сделать _внутреннее_ представление диаграмм текстовым и топишь за двоичное (бинарное) представление.

Текстовое внутреннее представление никак не отменяло бы первичность графического представления. Но гигантски упростило бы взаимодействие Метапрога с внешним миром. Не надо было бы (по крайней мере, на первых порах) писать свои аналог гита, гитхаба (ты уже понял, чем они отличаются?), визуального диффа и дофига всего. Способствовало бы появлению внешних утилит, работающих с метапроговской информацией. Вот когда метапрог окрепнет и созреет — можно и графический дифф писать, и всё остальное.

Складывается впечатление, что ты специально строишь среду, всю состоящую из новейших велосипедов и ни с чем не совместимую. А ведь Линус, куски которого ты тут неоднократно цитировал, указывал, что у него всё получилось в том числе потому, что он стоял, подобно Ньютону, на плечах гигантов. Он написал ядро и прикрутил к нему программы GNU (на тот момент уже достаточно сильно развитые). А если бы он начал писать свой юзерспейс, ни с чем не совместимый? Да ещё бы и от поддержки POSIX гордо отказался? Чтобы POSIX реализовать, это же ведь надо что-то читать, изучать, фи... Увидели ли бы мы тогда Linux в работе?

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

Нет. До Си не будет доходить такая информация как расположение элементов диаграммы или названия функций, типов, терминалов задаваемые человеком (кроме явно заданных именно для Си, но этого я б не советовал). Будет именно свой бинарный формат.

Так почему именно бинарный-то? (См. мой предыдущий комментарий.)

На плечах гигантов - это Си, который у меня бэкендом и вместе с ним огромное количество готовых сишных библиотек, которые можно будет включать и использовать в Метапроге. Это как у Линуса были готовые утилиты GNU для его новой системы.

Текстовые форматы я делать не хочу чтоб их потом не парсить. Лучше пускай будут структуры с версионированием форматов.

С внешним миром взаимодействовать при большущем желании можно будет, сделав свои утилиты. Код-то ведь открытый будет.

названия функций, типов, терминалов задаваемые человеком

Тогда невозможно преобразование C -> metaprog, ибо откуда брать названия всех этих элементов в диаграмме?

Вот есть архивация и деархивация текстового файла. Операция обратимая. Вам одинаково легко написать и текстовый файл, и архив, пользуясь текстовым редактором?

Автор, уважаемый, чуть шире смотрите. Или не придуривайтесь. Вы же не собираетесь свой граф в текстовом редакторе в ascii-art рисовать. Речь же про изоморфизм представлений для редактирования, которые каждая из сторон считает удобным и полным. Можно и архив читать и править научиться, и даже, я более чем уверен, такие гении существуют. Но, в том-то и дело, что построение графического языка изоморфного СИ (т.е. не привносящего никаких новых концепций, но в тоже время поддерживающего все возможные используемые на практике трюки и макросы — там вообще могут быть бои без правил) либо невозможно, либо бессмысленно, поскольку наглядность гарантированно ухудшится — это как на плоскости представить гиперкуб или гиперсферу. Т.е. алгебраически эти объекты есть, у них можно посчитать «объем», расстояния и сделать прочие построения и вычисления, которые уже графически не представить.

Либо вам придется смириться с тем, что ваш метапрог Си не изоморфен, обратным отображением вы жертвуете ради простоты, но, рискуете потерять полноту языка. Т.е. это уже получается не графический Си, а что-то другое. И полноту вам придется доказывать, а также как-то оценивать скорость программирования и стоимость поддержки/модификации, доказательства корректности программ по сравнению с другими языками.

Я подозреваю, что LabView — Тьюринг полный, но это не значит, что он обладает всеми нужными характеристиками для языка программирования общего назначения. BrainF**k и Befunge Тоже тьюринг-полны. Но на них никто не программирует (разве только для размягчения мозгов перед реальной учебой).

Смотри примеры в первой части.

Текстовые форматы я делать не хочу чтоб их потом не парсить

Отправляется в цитаты сегодняшнего дня. Т.е. бинарные форматы уже не нужно парсить, да?

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

Это что же, придется документацию по каждой библиотеке читать? Непорядок.

Текстовые форматы я делать не хочу чтоб их потом не парсить.

И только-то? Парсер пишется один раз, далее используется как библиотека. (Или идеология LabVIEW такого не позволяет? Да нет, не может такого быть.)

С внешним миром взаимодействовать при большущем желании можно будет, сделав свои утилиты.

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

import android.webkit.WebView

BrainF**k и Befunge Тоже тьюринг-полны. Но на них никто не программирует (разве только для размягчения мозгов перед реальной учебой).

Или для развлечения. Ещё unlambda очень хороша.

В остальном - очень хорошо передали мысль.

Но для большинства это будет просто сокращение от «метапрограммирование».

А мне нравится скрытый смысл))

Не надо было бы (по крайней мере, на первых порах) писать свои аналог гита

Так вроде художники используют какую то систему контроля версия, не git, но что то популярное тоже. Кто вспомнит?

среду, всю состоящую из новейших велосипедов и ни с чем не совместимую

Так библиотеки берутся готовые, а редактор и так будет лучше всех!

это уже получается не графический Си, а что-то другое

Новая среда программирования, для которой Си - всего лишь как ассемблер.

Я подозреваю, что LabView — Тьюринг полный, но это не значит, что он обладает всеми нужными характеристиками для языка программирования общего назначения

Я все пытался въехать в понятие «Тьюринг полный» (не сейчас, а давно еще), но так и не въехал. Это типа можно делать все операции?

Я далек от математических абстракций. Мне куда более интересны прикладные аспекты: вызов функций, библиотек, создание блок-диаграмм, трансляция в Си, компиляция... Со сферическим матаном в вакууме я не очень дружу.

Не увидел там примеров преобразования C в метапрог, мимо.

Парсер XML вещь сложная, да и представь, проект, 50000 блоков, в тексте это будет занимать много места, особенно в XML, да и тормозить будет, интерфейс то ZUI будет!

С версионированными бинарными форматами в Метапроге будет куда проще работать, чем с текстовыми.

Мне лень делать транслятор на/с INI/XML.

Эта фича еще в планах, а вам уже все готовенькое подавай.

Вы и от практических аспектов очень далеки.

Новая среда программирования, для которой Си - всего лишь как ассемблер.

В таком случае благодаря наличию ffi можно вообще выкинуть C из цепочки и сразу компилировать из диаграмм в исполняемый код. Меньше компонентов и текста - меньше ошибок, правда?

Я все пытался въехать в понятие «Тьюринг полный» (не сейчас, а давно еще), но так и не въехал. Это типа можно делать все операции?

«Тьюринг-полный» обозначает, что на нем можно эмулировать конечную машину Тьюринга (и, соответственно, любой конечный автомат).

В таком случае благодаря наличию ffi можно вообще выкинуть C из цепочки и сразу компилировать из диаграмм в исполняемый код. Меньше компонентов и текста - меньше ошибок, правда?

Компилятор С это еще и оптимизатор, плюс тут линковщик, скорость...

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

Парсер XML вещь сложная

Да уж, особенно по сравнению с git и другими инструментами, без которых можно было бы обойтись.

в тексте это будет занимать много места, особенно в XML

Я не настаиваю именно на XML, пусть будет JSON. Пусть даже подмножество JSON.

да и тормозить будет, интерфейс то ZUI будет!

Это ты про отрисовку и пр? Каким боком тут файловое представление? XML/JSON зачитывается при открытии проекта и оседает в памяти в виде тех же двоичных структур. При работе в IDE разницы нет.

Но ведь C - это текстовый ЯП, а значит - плохой! Сразу в бинарном формате нужно писать. Ведь гениальность метапрога позволит ему сразу это делать, не так ли?

Да пусть даже будет надмножество dot.

Мне лень делать транслятор на/с INI/XML.

То есть свои git, diff и т.д. не лень, а текстовый парсер лень?

Да уж, особенно по сравнению с git и другими инструментами, без которых можно было бы обойтись.

Я же говорю, git можно заменить на другую систему, главное вспомнить ее название %)

Это ты про отрисовку и пр? Каким боком тут файловое представление? XML/JSON зачитывается при открытии проекта и оседает в памяти в виде тех же двоичных структур. При работе в IDE разницы нет.

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

Он не плохой, он просто очень старый...

Хм, может хранить исходники в базе данных?

Разница в памяти между считыванием бинарника и считыванием XML будет O(n+f(n)), где f(n) - макс. память на преобразование n-символьного XML в бинарник, при правильной реализации может быть линейной. Значит, разница может быть линейной.

Своя база данных, репозиторий для разработки Метапрога и не только. Думаю запустить вместе с релизом.

А ОС (с ядром и юзерспейсом) для разработки метапрога на чистом метапроге тоже с релизом будет?

Окей, дай мне функцию которая будет вычислять структуру блока который находится в правом верхнем «чанке».

Может и будет. Вы этого с нетерпнием ждете? Может донат сделаете?

Для этого нужно читать весь XML файл, а так можно прочитать заголовок мелкий, бинарный, и вычислить offset