Metaprog: универсальная графическая среда программирования [в разработке] часть 4

У Вас лурчанка. В качестве лечения принимайте классическую литературу.

Люто, бешено принимаю.

Кстати, если луркостатью о ЛОРе ещё не дополнили данным поциентом, то, чувствую, пора бы.

Забыл самые главные вопросы. Как будет рисоваться сама кнопочка? Как будет задаваться алгоритм ее рисования и все такое? Как интерфейсы будешь конструировать? Планируешь раскрутку?

Вот, не поленился нарисовать, как должно выглядеть человеческое визуальное описание

Проще текстом написать, да и нифига не по человечески это, вообще ничего не ясно.

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

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

А что расширять-то? Где хоть какой-нибудь базис? Ноль \times ноль даёт ноль

Я кроме пространных упоминаний о каких-то терминалах и невнятной маниловщины ничего в упор не вижу.

А что расширять-то?

Metaprog же %) Как emacs, только графический.

Metaprog же %) Как emacs, только графический.

Сначала занеси 100, а лучше 500 баксов, а потом расширяй.

Какие баксы? О чем ты?.

Какие баксы? О чем ты?.

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

Автор исходники просто так не отдаст.

Ты просто не читал пост.

Автор исходники просто так не отдаст.

Потому что нету :-)

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

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

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

Вот rebforce хочет выкинуть типы, только динамическая типизация. «Упрощение» для тех, у кого с логикой полный завал. В итоге оно будет означать в итоге только усложнение. Например, если с его подходом (https://i.imgur.com/gW0M4aj.png) по ошибке подключить текстовую переменную к функции чтения файла, что будет? Не будет ли текст восприниматься в качестве пути к файлу? Его «умный» конструктор схем с динамической типизацией (и компилятор) в таком случае и слова не скажет, ведь почему бы текстовой строке не быть путем к файлу?

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

В моем же редакторе схем таких неоднозначностей не может быть в принципе.

Так ведь в С тоже проблемы с типами, float между int свободно конвертируются, всюду юзается void*, NULL.

C++ эту проблему хорошо решает кстати! Вместо void* - шаблоны к примеру, это и производительность повышает, сделать тоже самое на С можно только с помощью внешних инструментов.

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

В моем же редакторе схем таких неоднозначностей не может быть в принципе.

Ну ты же передавал тогда неверные callback'и, значит они есть, неоднозначности эти %) Нужны зависимые типы!

Хммм, расскажи подробнее и доступными словами что такое зависимые типы.

На уровне Метапрога реализуем.

Да, да! Будет прекрасно.

Только запретить бы еще подключение флоатов и указателей одновременно

Ну так запрети на уровне metaprog'a, не понял проблемы.

Полнота по Тьюрингу (или даже https://ru.wikipedia.org/wiki/Теорема_Бёма_—_Якопини которая мне больше нравится) - это сферическая абстракция в вакууме, если нет возможности обращаться к системным вызовам и прочим готовым библиотекам. Си в этом плане - очень хорошая стартовая платформа для Метапрога и я выбрал Си, так как руководствуюсь исключительно практическими соображениями. А к условному Brainfuckу, чтобы он стал полноценным языком с «полнотой по практике» (а не только лишь Тьюрингу), надо с нуля прикручивать кучу функций и системных вызовов, начиная от ассемблера инлайном.

Ну допустим тебе нужен указатель который никогда не будет NULL, и будет меньше 100000. Ты создаешь такой тип.

// [[в скобках типа требования]] 
typedef int *non_null_ptr [[value != NULL && value < 100000]];

// ну и потом можно написать функцию:
void print_intptr_value(non_null_ptr p) {
  // никогда не произойдет segment fault, так как в функцию
  // нельзя будет передать NULL
  printf("%d\n", *p);
}

А если будет попытка присвоить значение «99999»?

Будет segement fault)) Но это простой пример. Можно сделать встроенную функцию ptr_is_valid, для хоть какой то проверки правильности указателя. Главное что автоматические проверки избавляют от копипасты, и нельзя будет пропустить эту проверку! Так же можно генерировать проверки «с умом», metaprog их сам расставит где надо, с учетом оптимизаций, так, как человек в большом проекте просто не сможет.

Еще вот смотри.

typedef struct {
	const char *p = null;
	int len = 0;
} str_t;	

// Строка не должна быть пустой! 
void print_non_empty(str_t [[ value.len > 0 && ptr_is_valid(value.p) ]] str) {
	printf("%.*s\n", str.len, str.p);
}

str_t str;
print(str); // Ошибка при компиляции, а не во время программы
// Таким образом куча багов отсеивается еще на стадии компиляции!!!

При желании инструментарий работы с диаграммами ничем не ограничивается и он может бть куда шире чем с текстом (эту фишку ты просек). Однако зависимые типы на уровне стандарта...

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

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

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

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

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

Да! Вот так и надо!

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

Лурчанка почти у всех на ЛОРе. Это уже не лечится ничем кроме запрета лурки лет так на 50. Да и зачем? Языки эволюционируют, меняются, что в этом ужасного?

Как будет рисоваться сама кнопочка? Как будет задаваться алгоритм ее рисования и все такое?

Зачем?! Я не велосипедостроитель, использую встроенные средства Red, а точнее - диалект Red/View. Но для тебя это всё равно пустые буковки, так ведь?

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

Свои виджеты же рисовать иногда нада.

Это, конечно, хорошо, но будет ли у тебя возможна визуализация алгоритмов работы самого Red/View?

Для рисования графических примитивов используется другая подсистема - Red/Draw. Но и существующие в Red/View уже кастомизируются так, что мама не горюй.

Тут есть. https://www.red-lang.org/2016/03/060-red-gui-system.html

Как с визуализацией Red/Draw у тебя будет-то?

Вполне возможно, как раз за счёт гомоиконности и однозначного соответствия блоков AMP базовым синтаксическим структурам Red.

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

Red имеет View для Linux?

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

Хм, видимо нет. Причем они сделали графику для MacOS, а для линукса ничего не сделали...

Вместо того чтобы просто опереться на Си с его готовыми библиотеками. Лол.

А Rebol вообще в последний раз в 2011 году выпустился)) x86_64 версия только для eglibc... Ну metaprog уже идейно обогнал AMP. Tcl/Tk уж вместо Red, Rebol надо брать, оно хоть живое.

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

Эти библиотеки входят в состав GCC, что ли? Мегалол. Да будет тебе известно, что GCC используется в том числе и там, где никакой графики нет и в помине.

Пользы от тебя всё равно больше нет никакой и не будет.

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

Но если для тебя гуй важнее базовых структур

GUI это важно. Ты же понимаешь brainfuckprog можно сделать очень легко! Но какая польза? Что на этом можно сделать? Да ничего! На твоих недоязычках тоже ничего нельзя сделать, а С дает возможности, С дает мощь. До типов сишки redболам далеко.

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

Тебя ждёт много чудных открытий… Хотел бы я посмотреть на сконвертированные таким образом исходники ядра Linux, ну или хотя бы libmodblug для начала.

Подсказка: в них НИКТО ничего не поймёт. И ты в первую очередь.

Какая разница куда они входят? Половина софта вообще не по стандартам С написана, а с расширениями, никого это не волнует.

Red анонсировался в 2011. Каков их прогресс за 8 лет, какие более-менее крупные и значимые проекты на нем уже готовы?:)

Метапрог был впервые анонсирован публично в 2019, месяц назад. Посмотрим, что будет через 8 лет. Возможно даже выбросим почти все текстовые языки в легаси. По крайней мере, проектов точно будет куча, я вот один (чатик через тор), может, сделаю еще на лабвьюшном прототипе, до релиза альфы самого Метапрога.

*libmodplug

Хотел бы я посмотреть на сконвертированные таким образом исходники ядра Linux

Это, кстати, одна из целей. А реболовская твоя система будет уметь визуализировать исходники ядра Линукс? И во что этот код превратится, будучи обратно переведенным в Си? Динамическая типизация точно ничего не похерит?