LINUX.ORG.RU

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

 , , ,


6

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

Ух, как толсто.

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

Всего лишь скопировать между массивами? Почему не memcpy?

Например, чтобы не вкомпилировать libc. А вообще это просто пример кода.

Я к тому, что либо просто будет текст внутри квадратиков (например, «ptr > path + 1 && *(ptr - 1) == '/'» в качестве содержимого условия), либо если одна операция = один квадратик, то придётся это условие разбивать на кучу промежуточных значений.

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

Владимир

Блок схема в конечном итоге преобразуется в обычный C код.
В чем профит такого подхода и что он упрощает?

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

Си тоже процедурный язык. Зачем вам что-то кроме процедурного? ООП и прочие «высокоуровневые» концепты раздувают программы до неприличия и порождают туеву хучу багов https://habr.com/ru/post/423889/ давая взамен лишь некое «упрощение» программирования. Которое можно упростить, просто переведя Си в графику.

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

Для получения меню из сишных типов, структур, юнионов и функций из #include

https://i.postimg.cc/vBjg3Dn4/menu2.png

https://i.postimg.cc/xdndRMFx/menu.png

я использую castxml, переводящий сишный код в XML-список элементов. Приведу кусок LabVIEW-диаграммы с парсингом фундаментальных типов (таких, как int, char, short, float)

https://i.postimg.cc/26rqvSzd/image.png

Ничто не мешает так же парсить JSON. Ничто, кроме пропиетарности LabVIEW, которому я разрабатываю опенсорсный аналог.

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

Блоки текста - это ДРАКОН. ИМХО - тупость.

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

https://i.postimg.cc/kgkrcm1T/socket.png

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

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

https://i.postimg.cc/vBjg3Dn4/menu2.png

https://i.postimg.cc/xdndRMFx/menu.png

И работает только с графическим кодом.

https://i.postimg.cc/kgkrcm1T/socket.png

Текстовый код скармливается gcc для получения бинарников. Си тут - всего лишь «кроссплатформенный ассемблер».

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

Владимир

Когда ждать бету?
Проект не будет зависеть от LabVIEW?

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

Это же питон, и то там от текста полностью не избавились, лишь организовали его в блоки.

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

Я разрабатываю графическую оболочку для Си, чтобы упростить нормлаьное программирование и избавиться от ерунды типа C++, Python, Java, Javascript и тому подобных «объектных моделей» и «интерпретируемых» языков.

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

Бету? Надеюсь к середине-концу лета выкатить. Если будет донат - смогу поменьше работать и побольше заниматься Metaprog, это поможет ускорить проект.

К релизу проект будет опираться ТОЛЬКО на стандартную библиотеку Си (glibc), Xlib (по графической части) и системные вызовы Linux. Никакой зависимости от LabVIEW и прочей пропиетарщины (сейчас это всего лишь временный костыль).

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

Владимир

Желаю вам повторить успех Сысоева.

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

Владимир

Да ни какой иронии.
Вы меня не правильно поняли.

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

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

Shadow ★★★★★ ()
Последнее исправление: Shadow (всего исправлений: 2)

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

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

async это параллелизация выполнения? Стандартными сишными средствами через pthreads.

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

Эти пара строчек с bind это конечно хорошо, но хотелось бы увидеть эквивалент рабочей программы хотя бы на 1000 строчек :P

Harald ★★★★★ ()

https://en.wikipedia.org/wiki/Rational_Rhapsody

Вот самое тру:

http://www-01.ibm.com/support/docview.wss?uid=swg21380566

http://www-01.ibm.com/support/docview.wss?uid=swg27016563

«К сожалению», все это подохло. Было прикольно! А сколько энтузиазма у сотрудников, и довольное начальство, купившее за $150,000 лицензию

2019

Актуальность не ослабела, можно найти и качнуть, сейчас, кажется вполне легально.

Суть: на входе диаграммы мышкой, на выходе генеренный С-код.

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

Так тут и толкуем, что такую диаграмму легче на PlantUML закодить, чем нарисовать.

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

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

Shadow ★★★★★ ()

Как ты будешь это хранить и организовывать параллельную НЕЗАВИСИМУЮ работу над кодом, мерджить? Как будешь искать что-то в коде?

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

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

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

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

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

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

Я к тому, что оно вряд ли влезет даже в три спуфингомонитора мелким шрифтом

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

А меня даже большие деньги едва ли соблазнят программировать на текстовой ООП-ерунде типа Java.

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

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

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

Пацаны пилят фичу А, другие фичу Б, часть общего кода содержит противоречивые изменения, как их разрешать? Как выглядит работа с базками (RDBMS)? Как генерируются (?) запросы, как выполняется маппинг результатов зарросов?

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

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

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

Тысячи программистов в 1970 году писали в тексте на ассемблере. Миллионы программистов в 2019 году пишут в тексте, в основном на таком ужасе (с точки зрения оптимизации и сложности) как Java, Javascript, Python, PHP, C++.

metaprog ()

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

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

Как люди играют в стратегические онлайн-игры реального времени? Игроки СРАЗУ получают результаты чужих действий и так подстраиваются под обстановку.

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

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

Тупиковый не путь, а сами те попытки. ДРАКОН с текстовыми блоками, детский Scratch и пропиетарное по-своему-ограниченное LabVIEW. Это как если б вместо Си Керниган и Ритчи выкатили Python (с соответствующими глюками и скоростью, особенно на тогдашнем железе) и после этого «умники» говорили, что ничего лучше ассемблера не может быть в природе.

Ни один из известных мне примеров графического программирования не манипулирует непосредственно с сишным stdlib и системными вызовами Unix. Только какая-то «прикладная» ерунда.

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

Помимо stdlib есть куча других сторонних библиотек, которые активно используются в реальных сишных проектах. Их как добавлять?

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

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

metaprog ()

Мне вот только одно интересно - сколько же лоровцев купятся на ЭТО и задонатят?.. ))

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

А вот в openssl куча функций, которые на самом деле макросы, вызыввающие одну и ту же функцию с разными аргументами. Что с макросами?

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

Можно немного. Главное чтобы полностью уже сторчался.

anonymous ()

Началась весна. Время революций в программировании.

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

Макросы препроцессора?

1. Сначала по списку из #include проходит gcc -E

2. Его выход переводится castxml в XML-список типов и функций

3. XML парсится и отображается список функций и типов (пока что на LabVIEW, но это временно)

https://i.postimg.cc/vBjg3Dn4/menu2.png

https://i.postimg.cc/xdndRMFx/menu.png

4. Из этих готовых блоков можно делать блоковую диаграмму

https://i.postimg.cc/kgkrcm1T/socket.png

5. Готовая диаграмма переводится в код на Си и скармливается gcc для получения бинарника. Простые примеры уже успешно компилиюруются.

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

не вижу на этих одних и тех же картинках ни одного примера макроса с аргументами

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

Макросы среды программирования? Пока нет. Спасибо за подсказку, будут.

metaprog ()

Фатальный недостаток идеи визуального программирования заключается в том, что большую часть жизненного цикла код не пишется, а дорабатывается и отлаживается. С активным применением систем контроля версий. Если в сабже не намерено решить проблему хотя бы банальную задачу поиска ломающего изменения в истории правок — не стоит и пытаться. Очередная среда визуального «программирования», являющаяся на деле системой протипирования и порождающая на выходе несопровождабельного монстра — никому не нужна.

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