LINUX.ORG.RU

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

 , , ,


10

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



Последнее исправление: CYB3R (всего исправлений: 9)

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

Тебе надо багрепорты им писать, может, статус платинового тестера получишь. :)

И ещё. Тебе тут анонимус уже писал про IBM/Rational Rhapsody - так вот, на неё в качестве прототипа было бы полезно посмотреть. Поскольку она основана на трудах троицы Буч - Рамбо - Якобсон и она-то, в отличие от LabVIEW, как раз заявлялась средством разработки общего назначения. Один мужик из дружественной фирмы писал и нахваливал...

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

После лабвью смотрю на скрины IBM/Rational Rhapsody - вижу фигу.

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

Rhapsody похоже на Дракон, если бегло посмотреть. Текст полностью не отметается. Лабвью реально уникально в своем классе.

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

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

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

Текст полностью не отметается.

Так может, это не недостаток, а достоинство? Я вот, например, сторонник решений, которые не выкидывают, а дополняют существующие подходы.

Например, строчка y = 2*x-15 в виде текста куда лаконичнее и понятнее, чем если её треугольниками разрисовывать.

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

Выше была идея блока с формулой.

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

metaprog
() автор топика

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

orm-i-auga ★★★★★
()
Ответ на: комментарий от orm-i-auga

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

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

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

я уже имею наглядное меню всех возможных функций и структур

Для этого придумали IDE и auto-completion плагины к редакторам. Ну и вообще-то от чтения мануалов ещё никому хуже не становилось.

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

Линус не сравнивал себя ни с кем, не апеллировал к авторитетам, и считал, что делает систему для себя. К тому же, он сразу выложил рабочий прототип, а не какие-то примеры работы. А этот поциент уверен, что умнее 95% программистов и при этом сам не знает ничего, кроме C. Удачи ему, будем надеяться, что это пройдет с возрастом.

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

Я тоже делаю Метапрог, чтоб расширить свои возможности, ограничения Лабвью мне мешают.

metaprog
() автор топика

неужели ты реально думаешь что эта картинка https://i.postimg.cc/YCywWbSh/fwrite.png состоящая из нагромождения линий, непонятных циферок и подписей на украинском языке проще чем элементарная строчка кода printf(«Hello, world»);

а если программа будет слегка посложнее чем hello world тому кому придётся разбираться с нагромождением этих линий не позавидуешь проще застрелиться.

iluha16
()

Когда я кодил на Unreal Blueprint понял, что не все так хорошо с графическим программированием. Хотя там вроде бы сказывались проблемы конкретно платформы, а не принципа как такового. Но всеравно написать удобную среду графической разработки - очень непростое дело. Особенно если не забывать про diff и VCS. А да, еще надо бы иметь алгоритм визуально красивой планаризации графа кода, который я даже не представляю себе как надо писать (народ обычно оставляет этот процесс на совести кодера, что для него лишняя головная боль, особенно при рефакторинге).

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

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

q0tw4 ★★★★
()

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

Потому что Си это номинально синтаксический сахар над ассемблером. И пока нужны будут сети, драйвера и bare-metal по, Си никуда не денется. А учитывая как сейчас развивается сфера малых встраиваемых систем, он только укрепляет свои позиции. Я слабо себе представляю операцию чтения буфера DMA по прерыванию в многопоточной среде или разбор бинарного пакета на потоки выраженные в виде некоего графического представления. Ни никак вообще!

Простота программирования и эффективность, не меньшая, чем у Си, убьет C++, Python, Java, Javascript и прочую ерунду с раздутыми и полными багов абстракциями.

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

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

Ну как не дает? Написал я вот тут на нем пробный микросервис. Слизал с того что писал на scala/akka. Jvm в idle режиме = 130мб, rust = 6кб. После удара гатлингом в 1000 соединений jvm 480мб, rust 7мб. Касаемо сложности, ну он попроще чем scala и посложнее чем c++. Поэтому для меня он оказался довольно прост, согласен. Но вот для питониста например который никогда не видел ML языки и не в курсе что такое poll-based event loop и futures chain он покажется дьяволов воплоти.

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

На а что там сравнивать. Если опираться на бенчмарки, go где-то в 3-5 раз медленнее раста и в два раза более ресурсоемок. Вот и можно прикинуть какие будут результаты у go по данному тесту.

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

Понятное дело что что go во много, много раз меньше ест чем jvm. Но мне как-то ближе функциональные ml языки, поэтому я за него и выступаю)

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

Но самое главное зачем я сюда пришел (консультации по Си, гтк итд) я получаю стабильно. Не от тебя, конечно.

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

Хотя ты по-своему полезен проекту. Показываешь как делать НЕ надо. Для тебя код ядра Линукс - это темный лес, в который ты за менее чем 22000 баксов не сунешься:)

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

Ты не модератор, чтобы меня вот так вот «предупреждать». Я вот тебя не «предупреждаю». Ты забавный, так что пиши, будет весело. Особенно интересно будет взглянуть на твой «антиметапрог». Концепт обещан до 3 мая, я жду.

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

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

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

Любопытно. В очередной раз подтврждает мою правоту в выборе Си.

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

Очень плохой сайт же! Ну а Rust не может быть идентичен C, всегда он будет медленнее, у него не тот уровень, да и транслятор у них фиговый.

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

Очень плохой сайт же!

Мотивируй данное утверждение!

да и транслятор у них фиговый.

LLVM перешел в разряд фиговых трансляторов? Ты можешь предложить альтернативные варианты, явно превосходящие LLVM?

Ну а Rust не может быть идентичен C, всегда он будет медленнее, у него не тот уровень

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

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

А в чем в принципе преимущества Раста перед Си? Кроме досадной необходимости учить новый язык.

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

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

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

Ага, я там первый и написал =). Вангую, что придёт время и ТС таки выкатит пре-пре-пре-фльфа релиз, но что бы его получить надо будет заплатить баррель нефти. Хотя я уже давно интерес потерял ибо ровным счётом нихрена не понятно что происходит. ::)

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

А ваша роль какая? Ну то есть код после матлаба как то верифицируется?

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

Изобретать новые COBOLы?! Почитайте https://habr.com/ru/company/wirex/blog/431558/

Нечто вроде FILE * test_file = fopen(«/tmp/test.txt», «w+»); должно преобразиться в create file /tmp/test.txt for input and output as test_file

На самом деле конец ‘for input and output as test_file’ громоздкий и не нужный, я бы хотел вместо него видеть хорошо узнаваемый символ или слово с чёткими границами. Вообще любой единичный элемент должен легко выделяться из текста глазами и быть удобным для фиксации на нём. И тут вспоминается мне то, что зрительная кора работает на кусочном преобразовании Фурье, а в глазах двумерное изображение подвергается полиноминальной фильтрации. Во вторых, глаза нацеливаются на от одной до четырёх букв и слово читается скачками между такими последовательностями букв.

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

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

А можно пример кода на C++ для Avr? Хотя бы вывод из порта в консоль

LongLiveUbuntu ★★★★★
()
26 июля 2019 г.

я всецело уверен, что за uml будущее.. точнее не за самим uml, а за самой концепцией..

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

и чего C? почему бы не транслировать сразу в ассемблер :) может дико - зато открыты все пути к оптимизации.

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

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

в общем я желаю успехов сабжу

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

и чего C? почему бы не транслировать сразу в ассемблер :) может дико - зато открыты все пути к оптимизации.

ОП не знает ассемблер. Зато я кое как знаю. %) Так что вполне может быть скоро будет ассемблер-версия!

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

Ага. Я вообще про то, чтобы из блок схемы сразу ассемблер генерить. А на чем будет написана сама система - вообще как-то без разницы. Хоть на джаввскрипте. Финальный год, я считаю, чтобы эту систему можно было бы описать самой же этой блок схемой. Иначе какая-то бессмыслица получается. Как с джавой, например :)

none
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.