LINUX.ORG.RU

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

 , , ,


7

7

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

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

Графическое программирование намного проще и понятнее. Если в качестве бэкенда брать Си и манипулировать функциями из сишной стандартной библиотеки, это не будет создавать никаких лишних абстракций, зато серьезно упростит жизнь программистам и особенно людям, имеющим дело с чужим кодом. Код любого уровня и любой сложности, представленный в виде графических блоков, станет открытым не только для узких специалистов, но и вообще любому продвинутому пользователю. Простота программирования и эффективность, не меньшая, чем у Си, убьет C++, Python, Java, Javascript и прочую ерунду с раздутыми и полными багов абстракциями (которые Линус не раз крыл матом).

Я уже делаю некое подобие LabVIEW на самом LabVIEW, назовем его Metaprog. Так же, как в 1991 Линус Торвальдс делал линукс, пользуясь пропиетарным Minix. И так же жаловался на кучу недостатков в Minix, желая устранить их в своей системе.

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

Примеры

Примеры с кодом на Си генерируются автоматически. Они тут же скармливаются компилятору и не предназначены для чтения эстетами, не любящими «абракадабру». Здесь они приведены лишь как пример работы транслятора и для возможности самостоятельно скомпилировать графические диаграммы со скринов. Так сказать, приобщиться к прекрасному.

Самое простое - Hello World. Скомпилируйте (gcc -o ./test ./code.c).

https://i.postimg.cc/YCywWbSh/fwrite.png

#include <stdio.h>

int main(){
char metaprog_array_pointer_10156130170823954432[] = {72,101,108,108,111,32,87,111,114,108,100};
unsigned long int metaprog_variable_13830126042312755200 = 1;
unsigned long int metaprog_array_size_10156130170823954432 = 11;
fwrite(metaprog_array_pointer_10156130170823954432,metaprog_variable_13830126042312755200,metaprog_array_size_10156130170823954432,stdout);

}

Я подписываю терминалы на украинском (сам оттуда), с таким же успехом их можно подписывать на русском, а не только на английском. Можно будет перевести все, кроме, разве что, вызываемых сишных функций, а gcc этого и не заметит (посмотрите код). При работе международной командой можно к каждой подписи/надписи прилагать словарь с нужными языками. Игры ж локализируют, чем визуальное программирование хуже?

Массив декларируется не как строка в кавычках, а как последовательность байтов, а байт - это цифра. Строки редактируются отдельным редактором (пока что средствами LabVIEW, но это временно). Больше никаких проблем и глюков с управляющими символами, кавычками итп (очень серьезная проблема при программировании на Си, Shell scripting и вообще всех текстовых языках).

Константа-массив имеет отдельные терминалы для указателя на массив и длины массива (известной редактору кода). Если терминал длины подключен - декларируется отдельная переменная. Не подключен - незачем и декларировать.

Пример посложнее: запись и в stdout, и в файл ./fwrite-test.txt

https://i.postimg.cc/v8KvKKmQ/fwrite2.png

#include <stdio.h>

int main(){
char metaprog_array_pointer_10156130170823954432[] = {72,101,108,108,111,32,87,111,114,108,100};
unsigned long int metaprog_variable_13830126042312755200 = 1;
unsigned long int metaprog_array_size_10156130170823954432 = 11;
fwrite(metaprog_array_pointer_10156130170823954432,metaprog_variable_13830126042312755200,metaprog_array_size_10156130170823954432,stdout);
char metaprog_array_pointer_12385851444566411264[] = {46,47,102,119,114,105,116,101,45,116,101,115,116,46,116,120,116,0};
char metaprog_array_pointer_16510743873862514688[] = {119,43,0};
fwrite(metaprog_array_pointer_10156130170823954432,metaprog_variable_13830126042312755200,metaprog_array_size_10156130170823954432,fopen(metaprog_array_pointer_12385851444566411264,metaprog_array_pointer_16510743873862514688));

}

В данном примере используется функция fwrite, а не printf. То есть, символ «0» не влияет на запись массива в файл или stdout. Сколько символов писать функция и так знает из длины массива.

Заявки

Принимаю заявки на новые фичи. Пишите в комментариях. Уже приняты заявки:

1. Пример с простым HTTP-сервером.

2. Пример с сортировкой Хоара (quicksort).

3. Простой в пользовании функционал работы со строками (больная тема для Си и С++).

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

Сейчас нужно научить Metaprog «компилировать» блок-схемы прямо в Си и скармливать этот код gcc, получая бинарники. После чего перенести сам Metaprog на Си, чтоб перестать нуждаться в пропиетарном LabVIEW и выложить результаты в опенсорс. И получить за это донат, хотя желательно уже сейчас (для ускорения работы). Bitcoin:1AYoK2TScSpD5bhf67mv9AxHDJ2RidRvjD

Ответ на: комментарий от metaprog

A GVariant cannot contain a pointer. Отметается.

https://developer.gnome.org/glib/stable/glib-GVariant.html

Надо уметь и указатели вмещать, и структуры с указателями. При сериализации/десериализации будут читаться/писаться данные из указателя/в указатель. Кстати, в Метапроге массив - это структура из указателя и длины массива.

metaprog ()
Ответ на: комментарий от metaprog

Владимир

Погуглите типа «создание блок схем» /найдете много проектов с исходными текстами/.

anonymous ()
Ответ на: комментарий от anonymous

Там же электрон, джаваскрипт? Догадайтесь на чем я его вертел:)

metaprog ()
Ответ на: комментарий от metaprog

Владимир

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

anonymous ()
Ответ на: комментарий от metaprog

Владимир

Ну где-то так /как по мне - баловство/, но иногда использую JavaScript и PHP /кстати Perl очень хорош/.
Многие поступают так:
- базовый API пишут на C;
- интерфейс /что под руку попадется: Python, .../.

И пожалуй во многом они правы.

anonymous ()
Ответ на: комментарий от metaprog

Тогда клацаешь кнопку «компилировать» - и компилирует.

Я немного не про то. Кнопка такая в любой IDE есть и прекрасно работает. Я про то, что у этой кнопки под капотом. Система должна понимать, что и как компилировать.

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

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

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

hobbit ★★★★★ ()
Ответ на: комментарий от hobbit

Владимир

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

В Visual Studio интерфейс делал Петя с 3-го курса машколледжа.

anonymous ()
Ответ на: комментарий от hobbit

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

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

особенности сборки под разные платформы и внешние библиотеки и др

Будет реализовываться в самих диаграммах. Где-то сверху спрашивали про макросы. Так вот, в Метапроге они будут обычными «структурами выбора» или говоря по-сишному что-то типа switch architecture case x86-64... case arm... (на графику я это еще не переложил, скрины будут позже), но на сам Си будет транслироваться лишь нужная часть, соответствующая заданным условиям сборки (архитектура итп).

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

metaprog ()
Ответ на: комментарий от metaprog

Если приходится читать исходники на питоне - матерюсь как гопник.

metaprog ()
Ответ на: комментарий от metaprog

Владимир

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

anonymous ()
Ответ на: комментарий от metaprog

Владимир

Для разработчика это противопоказано.

anonymous ()
Ответ на: комментарий от hobbit

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

Конфиг разрулится на уровне блок-диаграмм. Компиляторы - будет выводиться один большой монофайл «metaprog_build.с» промежуточного кода на Си, или вообще скармливаться gcc через stdin/popen (я вопрос об этом задавал, но он оказался непростым, вернусь к нему уже когда будет хотя бы бета). Если gcc будет мало для полного счастья - можно будет для нужных платформ допилить соответствующий функционал. Сейчас для меня главное чтоб Метапрог сам свой код мог редактировать, не нуждаясь в Лабвью плюс функционал собственного аналога гитхаба - тогда и будет бета. Остальное прикрутит сообщество.

metaprog ()
Ответ на: комментарий от anonymous

Я никогда в играх не открывал консоль (есть в некоторых играх, типа майнкрафта). Не хочу учить команды.

metaprog ()
Ответ на: комментарий от anonymous

Мне без мата трудно выражаться, читая исходники на текстовых языках, и чем сложнее синтаксис - тем труднее воздерживаться от мата:)

metaprog ()
Ответ на: комментарий от metaprog

Владимир

Не об необходимости консоли, а реализации игровой логики речь шла.

anonymous ()
Ответ на: комментарий от metaprog

Владимир

Уравновешенней нужно быть.

anonymous ()
Ответ на: комментарий от anonymous

Объективно говоря, Си непрост, иначе я б не взялся за Метапрог. Но скриптовые языки - это ужас.

Кстати, планирую в Метапроге возможность создавать собственные фреймворки. Не только делать сами программы опираясь на Си, но и, например, «скриптовые» высокоуровневые абстракции на замену вебу, Javascript, игровым скриптам (где нужно менять не код программы, а только поведение персонажей). Словом, графический аналог «высокоуровневых» языков.

metaprog ()
Ответ на: комментарий от metaprog

Владимир

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

anonymous ()
Ответ на: комментарий от anonymous

Владимир, может зарегистрируешься? Это несложно ведь. Или есть причины этого не делать? Ведь кто попадя может от твоего имени писать.

metaprog ()
Ответ на: комментарий от anonymous

Я сам себе не враг, и текстовые исходники читаю лишь в случае крайней необходимости:)

metaprog ()
Ответ на: комментарий от metaprog

Владимир

«Всегда быть в маске, судьба моя».

anonymous ()
Ответ на: комментарий от anonymous

Владимир

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

metaprog ()
Ответ на: комментарий от metaprog

Владимир

Тогда буду использовать UUID.

anonymous ()
Ответ на: комментарий от metaprog

Владимир

Вообще вы быстро определите подлог.
Стараюсь быть доброжелательным /и тем более не хамить/.
А если от моего имени кто-то доброжелательно вам будет помогать,
то это будет лишний урок доброжелательности.

anonymous ()
Ответ на: комментарий от metaprog

Твои диаграммы ещё хуже читаются...

anonymous ()
Ответ на: комментарий от metaprog

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

anonymous ()
Ответ на: комментарий от metaprog

Например, добродушного Владимира.

anonymous ()
Ответ на: комментарий от anonymous

Владимир

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

anonymous ()

Владимир

Экспромтом.
Скорее всего большие диаграммы будут не удобны в использовании, а вот
представление в графике алгоритмов может быть и «приживется».

anonymous ()
Ответ на: комментарий от anonymous

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

anonymous ()
Ответ на: комментарий от anonymous

Владимир

Здесь автору нужна помощь.

anonymous ()

Владимир.

Sorry за витиеватость.
Ожидаю от графического языка высокоуровневых «плюшек» записи
алгоритма, которые будут разворачиваться в C код.

anonymous ()
Ответ на: комментарий от metaprog

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

Окей, переформулирую. Кто будет вызывать gcc? Сам Метапрог? Значит, на Метапрог ложатся и функции, традиционно выполняемые системой сборки. Ты можешь не называть это системой сборки, ты можешь не выделять её в отдельную сущность, но её функции никуда не денутся.

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

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

товарищи консольщики

Или ты всё-таки ничего писать не собираешься, а тонко троллишь?

hobbit ★★★★★ ()
Последнее исправление: hobbit (всего исправлений: 1)
Ответ на: комментарий от hobbit

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

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

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

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

metaprog ()
Ответ на: комментарий от metaprog

П. С.: головная боль - только если есть сохраненные на диск файлы. Если нет сохраненных файлов менять типы в Лабвью очень легко.

metaprog ()

Владимир

Чтобы проверить являются ли диаграммы понятными предлагаю привести диаграммы:
- вычисление факториала;
- подсчет вхождения слов в текст;
- сортировка по методу Шелла.

Потому, что трудно судить о том, чего не видел.

anonymous ()
Ответ на: комментарий от metaprog

Я в своих Лабвью-программах почти все храню в бинарных файлах

Кстати говоря, многие средства разработки эволюционировали от двоичных форматов к текстовым. К примеру, в древней Delphi 3 файл описания формы (dfm) был двоичным, это приводило к невозможности эффективной работы с VCS-системами. В итоге его сделали текстовым, с синтаксисом, похожим на Паскаль. Второй пример: в прикладных ДОС-программах обычным делом были двоичные конфиги, потом народ перешёл на INI, а в сложных случаях на XML, а теперь и на JSON. Так проще находить концы.

Поэтому таки настоятельно советую не прыгать по граблям, на которых уже, наверное, СОТНИ ТЫСЯЧ программистов набили шишки, и внутреннее представление делать текстовым. Вот, например, Visual Paradigm. Позволяет делать UML-диаграммы, если ты топишь за визуальное программирование, должен знать, что это такое. Сама среда вся из себя визуальная и интерактивная, а файлы диаграмм сохраняются в XML.

hobbit ★★★★★ ()
Ответ на: комментарий от anonymous

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

metaprog ()
Ответ на: комментарий от hobbit

Владимир

... К примеру, в древней Delphi 3 файл описания формы (dfm) был двоичным, это приводило к невозможности эффективной работы с VCS-системами.

В Delphi 7 по крайней мере он присутствовал /VCL и dfm - родственники/.
Года два назад реализовал конвертацию dfm в текстовый формат c целью проверки того, что понимаю dfm.
Ныне использую этот алгоритм для преобразования dfm в свой формат
хранения метаданных диалоговых форм /не текстовый формат/.

anonymous ()
Ответ на: комментарий от hobbit

Наверное, лучше таки введу версионирование форматов. По крайней мере, попробую.

Выглядеть бинарный файл с версионированием будет, говоря по-сишному:

struct{
unsigned long int format_version;
struct{
unsigned long int data_size;
char data[];
} data_record;
}

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

При десериализации можно будет обработать разные версии формата через switch+case, точнее его графический аналог.

metaprog ()
Ответ на: комментарий от anonymous

В Delphi 7 по крайней мере он присутствовал

Владимир, в Delphi 7 и даже 5 его формат был уже текстовым. Расширение dfm и назначение файла осталось, а формат поменяли, загляните внутрь. Конечно, поддержку старого формата оставили для совместимости, и если у вас были совсем старые формы - их формат мог и не поменяться.

hobbit ★★★★★ ()
Ответ на: комментарий от hobbit

в древней Delphi 3 файл описания формы (dfm) был двоичным, это приводило к невозможности эффективной работы с VCS-системами

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

metaprog ()
Закрыто добавление комментариев для недавно зарегистрированных пользователей (со score < 50)