Метапрог-прототип, версия 6 + будильник на Метапроге

Гуй можно и без ООП делать.

Вообще все можно сделать на основе машины Тьюринга. Однако почему то так не делают…

Отрисовка кнопок, блоков, линий, взаимодействие с пользователем - все это делается без ООП.

Видишь суслика? Нет? А он там есть!

Каждый твой неответ еще больше втаптывают твою репутацию в грязь

Там уже все втоптано до центра земли, дальше топтать некуда…

Опередил) я тоже хотел написать такой комментарий.

На самом деле, у меня его даже слишком мало.

Если бы Ваше ЧСВ хотя бы на 1% отвечало Вашим навыкам, метапрог бы уже давно захватил мир.

Я опускаюсь до конструктивных ответов на неконструктивную критику.

С точностью до наоборот, но ща счёт раздутого ЧСВ Вы этого не видите. Вы живёте в какой то альтернативной реальности…

на 1%

Не тролль его. Он ещё таблицу умножения не осилил, откуда ему знать, что такое проценты?

Тормознутый интерпретатор и сверховерхедный транслятор, умноженные на раздутый пузырь из абстракций ради абстракций. Ляпота.

Лепота что вы до сих пор теплое от мягкого отличить не можете :)

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

В С++ все тоже самое, только с оглядкой на то, что это один большой костыль поверх С. Современные образчики ПО на С++ бывают ничем не уступают ПО на Python. Тут дело как и всегда не в том что язык не очень, они все более или менее приличные в умелых руках и здравых головах, а в прокладке между креслом и компьютером, и тем что эта прокладка знает и умеет. А так же все остальные причины которые уже были сказаны ранее, все это именно то почему современный софт такой какой он есть.

Гуй можно и без ООП делать. На доске для схем прототипа Метапрога все отрисовывается своими функциями, собирающими 2-мерные массивы из пикселей. Отрисовка кнопок, блоков, линий, взаимодействие с пользователем - все это делается без ООП. Лабвьюшные элементы интерфейса используются, но как вспомогательные для диалогов (как основные - только в Метапрог онлайн).

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

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

Вы не понимаете сути глобальности, могу признаться лишь в этом.

В процессе. Хочешь ускорить - присоединяйся:)

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

то на питоне могу вспомнить только глючную унылую скриптуху

Это ты так Царю пытаешься нелепо подражать?

Гуй можно и без ООП делать

Только почему-то никто этого не делает, даже гномеры используют Glib (а в последнее время перешли на свой Vala и gtkmm).

У тебя очень странная риторика. Ты высказываешь против высокоуровневых абстракций, навроде ООП, дженериков/шаблонов в пользу костыльного СУВТ, но при этом твоя основная идея – абстрагироваться от текста. На уровне абстракции, какой ты задумал не место низкоуровневому перекладыванию байтиков, и в качестве бекенда должен стоять язык высокоуровневый, такой как хотя бы C++, только ты прекрасно понимаешь, что ты его просто не осилишь своим «методом тыка», поэтому продолжаешь травить байки про «ненужность абстракций», тем самым просто скрывая своё нежелание учиться.

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

Это в какой это украине копейки в ходу?

Вы не понимаете сути глобальности, могу признаться лишь в этом.

Опять же: у переменных есть имена. Назови имена глобальных переменных в коде сишных трансляций Метапрога.

поприкалывать хочется, детский сад ей богу :) А что самое забавное, что никому ни весело ни грустно от этого.

Вообще-то страны пишутся с большой буквы.

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

Опять же вот эти ваши рандомные числа в именовании каждой переменной, давайте обсудим их, расскажите нам для чего они вам нужны, как они генерируются и почему их по два? (Я уже об этом тоже говорил, но хотелось бы послушать и вас)

Только почему-то никто этого не делает, даже гномеры используют Glib

Я попытался - и отбросил. Не столько из-за ООПнутости, сколько из-за засилия костылей. Там даже CSS было, а непосредственно структуры, через которые можно было бы управлять отрисовкой в обход CSS - скрыты инкапсуляцией. Вот тогда-то я и понял, что ну его в баню и лучше помучиться с нуклеаром, чем костылить поверх костылей, к тому же глючноватых (у меня на XFCE заметно).

Ты высказываешь против высокоуровневых абстракций, навроде ООП, дженериков/шаблонов в пользу костыльного СУВТ

Чем СУВТ костыльный? Что там не так? То что юнион по размеру в памяти как самый большой его элемент? Ну так можно использовать СУВТ из указателей.

На уровне абстракции, какой ты задумал не место низкоуровневому перекладыванию байтиков, и в качестве бекенда должен стоять язык высокоуровневый, такой как хотя бы C++

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

Вместо классов у меня прекрасно работают кластера (аналог структуры), сохраненные в typedef (в лабвьюшном понимании этого слова, хотя от сишного не сильно отличается). Чего не хватает - так это полиморфизма. Он есть, например, в стандартных функциях сериализации, но самому его использовать нельзя. Я планирую реализовать полиморфизм через многотиповой тип.

только ты прекрасно понимаешь, что ты его просто не осилишь своим «методом тыка»

А еще, если верить Линусу, он куда хуже и глючнее сишки: http://harmful.cat-v.org/software/c /linus

Ладно если б плюсы были реально лучше, но зачем с трудом осваивать то, что хуже?

тем самым просто скрывая своё нежелание учиться

Я его и не скрываю:)

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

Я попытался - и отбросил.

Не осилили, взбесились.

Не столько из-за ООПнутости, сколько из-за засилия костылей.

Назовите костыли и предложите альтернативные реализации если считаете что это костыль и можно было сделать иначе.

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

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

Вот тогда-то я и понял, что ну его в баню и лучше помучиться с нуклеаром, чем костылить поверх костылей, к тому же глючноватых (у меня на XFCE заметно).

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

Мне доводилось тыкать лабвьюшные диагарммы с ООП - ужас даже на Лабвью

кто бы сомневался, я бы даже сказал особенно на лабвью. А вы продолжаете топить за графподход, на котором ничего сложнее «если то иначе» невозможно состряпать иначе это такой ахтунг…

вы даже не сподобились и вряд ли сподобитесь ввести что-то уровня адт если вы понимаете о чем я

К сожалению (или счастью) не понимаю. Можете при желании объяснить.

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

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

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

Чисел не всегда два. Разберем подробнее. Есть, скажем, переменная

unsigned int metaprog_instance_0_9076949646305863681__6252306587257366529__8260520711340472321__6396423557519280129__variable_1884009650724341761

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

Первые 5 чисел после instance - цепочка номеров блоков метапроговских функций, первое (0) - главная диаграмма, с которой начинается трансляция. variable - один из видов блоков, может также быть junction (разветвление) и еще несколько возможных слов. Последнее число - номер блока, из которого выходит эта переменная. При желании можно по имени переменной однозначно узнать место где она была объявлена транслятором, хотя я такого уровня дебаггингом еще не занимался.

Также отдельно декларируются типы структур. Например вот так:

struct metaprog_instance_0_structure_definition_3192717493246738433_0 {
size_t size;
unsigned char *  pointer;
char dynamic;
};
struct metaprog_instance_0_6634104504735729665__6252306587257366529__structure_definition_495868968597833729_2 {
struct metaprog_instance_0_structure_definition_3192717493246738433_0 element0;
int max;
};
struct metaprog_instance_0_6634104504735729665__6252306587257366529__structure_definition_495868968597833729_0 {
struct nkc *  element0;
struct metaprog_instance_0_6634104504735729665__6252306587257366529__structure_definition_495868968597833729_2 *  element1;
struct metaprog_instance_0_structure_definition_3192717493246738433_0 element2;
};

Здесь тоже instance с номерами блоков-функций и уникальный номер блока, на котором была объявлено это определение структуры. Определения структур нужны чтобы, например, присваивать значения между разными экземплярами структур с одинаковыми типами элементов. В названиях структур видно и нестандартные слова типа size, pointer, dynamic - это декларируется тип массива. Так будет если задать имя элемента структуры на языке «C» (а не только украинском, русском, английском итд). Кстати, слово max в имя элемента структуры перекочевало из интерфейса функции: константа с таким именем на языке «C» была вытащена из входа блока вызова сишной функции и вставлена в структуру (кстати, процесс быстрый).

Надеюсь, тут все понятно? Умею я писать скучную документацию?))

Боже какой говкодище… У Вас феерический талант делать сложно тривиальные вещи.

liksys, ТСа нельзя допускать к укладке шпал, если конечно нет цели пускать поезда под откос. Только подметание территории - это хотя бы безопасно для окружающих…

Я знаю что такое область видимости переменной. Это в Метапроге вообще по барабану, потому что «переменных» как таковых на диаграммах нет.

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

К сожалению (или счастью) не понимаю. Можете при желании объяснить.

Есть гугл, хотя бы его не отвергайте.

Я знаю что такое область видимости переменной

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

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

Тут мы и подходим к самому интересному, т.к. то что наваяли вы стопроцентно поломается именно из-за «коллизии» хотя не совсем конечно корректно это называть так, но для того чтобы говорить с вами вашими терминами - сойдет.

Начем с того, что в Метапроге на диаграмме у каждого элемента есть числовой идентификатор (беззнаковое 64-битное). Задается он случайно при построении диаграммы

Кто бы сомневался, +поломка, продолжайте. За одно можете расписать механику создания этой случайности, сто за двести псевдослучайности.

но так, чтобы не было коллизий с другими идентификаторами в пределах диаграммы.

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

Ну и далее по тексту вы расписываете свой наивный подход превращения условной «картинки» в текст на С. Методом массивов, циклов, и ветвлений, и немножко работы со строками. И вы продолжаете рассказывать что у этого есть будущее.

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

прочитайте хоть пару книг о разработке компиляторов или изучите как это делали другие, сейчас кода полно бери да изучай

Это будет работа с текстом, ТС такого не могет, он только картинки воспринимает - профдеформация работника метлы. Вот ежели кто то на его участке набросает мусора в виде метапроговской диаграммы отвечающей gcc, тады да…

Боже какой говкодище… У Вас феерический талант делать сложно тривиальные вещи.

А можно такой же разбор авторам Cython?

Вот берём простую функцию:

def summer(double[:] mv):
    """Sums its argument's contents."""
    cdef double ss = 0.0
    cdef Py_ssize_t i = 0
    cdef Py_ssize_t size = len(mv)
    for i in range(size):
        ss += mv[i]
    return ss

Принимаем массив даблов и считаем сумму.

Звучит просто.

Набираем:

cython -V
Cython version 0.29.14

 cython .\example.pyx

И получаем файл в 732 килобайта:

https://yadi.sk/d/d2Fm3QnmO9ZKEw

Зачем мне разбирать cython, я им не пользуюсь. Могу разобрать выхлоп SWIG-а - там вполне читаемый код, даже в плане того что касается идентификаторов. Да, его много - дык обвязка биндинга к питону вообще много весит, и для того есть некоторые основания.

Более того, тут разбирается конкретно алгоритм генерации идентификаторов в поделии ТСа, и как уже писал abcq алгоритм кривой как фиг знает что. Завел бы что ли общий счетчик, и то было бы проще…

ЗЫ кстати глянул Ваш выхлоп cython-а - вполне читаемый код, в отличии от обфусцированного по самое не могу метапроговского.

А в чем ваша претензия заключается?

в том что тоже идентификаторы называются фиг знает как, и в том что кода много.

Вот пример из того исходника:

// line 1960
static PyObject *__pyx_int_0;
static PyObject *__pyx_int_1;
static PyObject *__pyx_int_184977713;
static PyObject *__pyx_int_neg_1;
static PyObject *__pyx_tuple_;
static PyObject *__pyx_tuple__2;
static PyObject *__pyx_tuple__3;
static PyObject *__pyx_tuple__4;
static PyObject *__pyx_tuple__5;
static PyObject *__pyx_tuple__6;
static PyObject *__pyx_tuple__7;
static PyObject *__pyx_tuple__8;
static PyObject *__pyx_tuple__9;
static PyObject *__pyx_slice__15;
static PyObject *__pyx_tuple__10;
static PyObject *__pyx_tuple__11;
static PyObject *__pyx_tuple__12;
static PyObject *__pyx_tuple__13;
static PyObject *__pyx_tuple__14;
static PyObject *__pyx_tuple__16;
static PyObject *__pyx_tuple__17;
static PyObject *__pyx_tuple__18;
static PyObject *__pyx_tuple__19;
static PyObject *__pyx_tuple__21;
static PyObject *__pyx_tuple__22;
static PyObject *__pyx_tuple__23;
static PyObject *__pyx_tuple__24;
static PyObject *__pyx_tuple__25;
static PyObject *__pyx_tuple__26;
static PyObject *__pyx_codeobj__20;
static PyObject *__pyx_codeobj__27;

__pyx_int_184977713, явно рука метапрога дотянулась до cython

Вырванный из контекста кусок мало о чем говорит, но даже если тут есть что-то схожее в именовании и предположить что это какой-то сорт говна, наподобие того что делает метапрог, то как это оправдывает метапрога?

У метапрога каша в голове, помноженная на лень и не желание чему-либо учиться и сейчас вы только взращиваете его невежество подобными вырванными из контекста кусками, без какого-либо анализа. А у вас получается что-то типа «Видишь метапрог, тут есть некоторое дерьмо, у тебя тоже некоторое дерьмо, значит ты делаешь все правильно»

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

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

Почему неприязни cython хорош чтобы написать биндинги из С в Python, или даже просто скрипт на питоне ускорить, несмотря на сотни килобайт кода он всё-таки чуток быстрее PyPy и сильно быстрее обычного CPython.

Просто мне непонятно, когда ругают генератор программ, и указывают а вот мы бы переменные называли вот так или ещё что-то.

То есть сравнивают генератор с ручным программированием.

Cython ещё не худший генератор, он хотя бы генерирует один файл, а вот ,например, Haxe, вообще создаёт проект файлов из 30-50 файлов на С, при генерировании однофайловой программы на Haxe.

А у метапрога хотя бы сгенерированные программы небольшие, которые в состоянии прочитать человек…

Ну почему «только»? Грибы собирать ещё, чтобы грибогенератор запитывать, а то останемся мы без грибоэлектричества.

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

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

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

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

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

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

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

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

В сингулярность)

Да уж. Никаких шпал, только метала. Желательно обтянутая поролоном, чтобы он об нее случайно не убился.

Такое вообще возможно в принципе?

В принципе - возможно, почему нет. Вот только с методом автора «из всех решений всегда выбираем самое геморройное» он появится ХЗ когда и если появится — будет монструозен как Oracle Database, переписанный на джаваскрипте.

Так вот откуда берутся черные дыры, вот почему мы не видим высокоразвитых цивилизаций - в каждой такой цивилизации появляется со временем свой метапрог и кранты…

Кстати, у меня ещё один вопрос, на который я не нашёл ответа.

Предположим у меня большая и сложная программа на metaprog. И мне приходит краш. Там же будет сишный колстек? Или каким-то образом эта ситуация будет решаться, что бы я мог найти, хотя бы приблизительно, в каком месте ошибка?

Ну так как это «транслируется» в С, мы может работать с этим как с С. Правда с тем как оно сейчас «транслируется» можно только пожелать вам удачи.

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

Если что, это пункт три моего списка. Списку уже полгода, но если вычеркнуть п.4 и слегка переформулировать п.5 (автор перешёл с GTK на Nuklear), он по-прежнему актуален, к сожалению.

Так вот я об этом и говорил. Поэтому и интересно, как ТС собирается это решать.

Я попытался несколько по-другом сформулировать как раз этот самый пункт 3. На Ваш пункт 3, я подозреваю, ответ будет стиле: «Не используйте valgrind, я вам напишу специальный инструмент для отладки». Поэтому я и предложил именно репорт.

Ну и я даже не про сам metaprog, а про ошибку в прикладной программе на metaprog. Чтобы нельзя было ответить в стиле: «metaprog будет идеален».

Кстати, интересный вопрос к metaprog, если названия переменных при генерации выбируются случайным образом, значит ли это, что при каждой генерации выхлоп будет разным?

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

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

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

В конце-концов, я бы не отказался от какого-то универсального редактора диаграмм, только без этой кодогенерации в C, а, например, с возможностью через промежуточный язык сделать генерацию более-менее чего угодно. Почему нет? Я могу придумать достаточно много задач, где это могло бы пригодится. Люблю перевешивать максимальное количество задач с программистов, на каких-нибудь UI или UX-дизайнеров, продюсеров и прочая.

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

Хороший вопрос. Я сейчас как раз делаю блок для дебага. Он будет возвращать строку, которая будет хардкодиться в константу при кодогенерации. В ней будет закодированные в base64 координаты блока, по которым в Метапроге будет однозначно указываться место на диагармме (и каждой диагармме, ведущей к ней).

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

Я больше полагаюсь на дебаговые фичи самого Мктапрога, а не дебаггинг на уровне Си. Конечно, сейчас фич маловато, но сделай скидку на то, что это всего ишь прототип.

названия переменных при генерации выбируются случайным образом

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

значит ли это, что при каждой генерации выхлоп будет разным?

Выхлоп кодогенератора не изменится при отсутствии изменений в диаграммах.

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

Си - не единственная возможная целевая платформа транслятора Метапрог-диаграмм, я это много раз писал.

Я вот почитал царя из этой темы Почему ООП стало более популярным и соответствующие языки и технологии программирования чем то же ФП? и с каждой строчкой его комментариев (почти все удаленные) все больше проникаюсь царизмом, убеждаясь в его правоте. И своей, что выбрал Си как целевую платформу транслятора Метапрога. А также в ущербности скриптухи типа питонов, джав и джаваскриптов. Впрочем, я знал про ее ущербность еще год назад, задолго до того как узнал кто такой царь (в контексте ЛОРа).

Такие базовые сишные концепты как указатель, структура, юнион и куча разных числовых типов в базовом варианте Метапрога точно нужны. Уже из них можно собирать разные дополнителньые плюшки типа массивов, строк, СУВТ итд. Можно сделать библиотеку из высокоуровневых блоков, где даже памятью управлять вручную не надо, но при этом всегда можно «спуститься вниз» и оптимизировать узкие места, вплоть до ассемблерных вставок.

Откуда такие выводы?

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

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