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)
Ответ на: комментарий от vladimir_vist

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

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

Точно не скажу, но вроде должен через видеокарту. Но с этим справляется и SDL2, он тоже позволяет использовать видеокарту, и поддерживает множество платформ.

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

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

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

да нахрен нужно, я не согласен уже с этим предложением

Графическое программирование намного проще и понятнее.

но вам мышевозам гуйным не понять. посмотрим чего вы там нарисуете.

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

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

А Wayland системы? Haiku? Под виндой сидит 99% юзеров, что ты хочешь делать на блок-схемах?

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

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

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

Исходник системы будет после релиза. Или у вас есть Labview, чтоб его прочитать, пока он еще не перенесен на открытую платформу?

Вы не ответили на вопрос на чем программируете.

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

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

Xlib существует с 1980х годов. Сегодняшние ПК по тогдашним меркам - суперкомпьютеры. Если даже в тех условиях Xlib работал, то сегодня он буде просто летать.

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

Владимир

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

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

Было б хорошо, если б на них можно было кодить что-то типа ядра ОС.

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

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

Код ядра часто и густо изменяется

Графические диаграммы радикально упростят этот процесс.

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

Я поддерживаю легаси код на 120 тыс строк, он написан на STL, если там был FBD или CFC, то поиск и отслеживание был бы визуально невыносим из-за размеров и количества переходов.

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

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

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

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

Владимир

Тогда уж лучше реализовать несколько стилей дизайна.

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

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

C++ leads to really really bad design choices

Голословное утверждение.

You invariably start using the «nice» library features of the language like STL and Boost ... but causes:
infinite amounts of pain when they don't work (and anybody who tells me that STL and especially Boost are stable and portable is just so full of BS that it's not even funny)

You inevitably start reinventing wheels that are available in other languages since ages, either as features or as stardard libraries. That causes infinite amounts of pain when your wheels on C do not work. На счёт переносимости, чья бы корова мычала. Можно ли Линукс собрать любым компилятором С?

inefficient abstracted programming models where two years down the road you notice that some abstraction wasn't very efficient, but now all your code depends on all the nice object models around it, and you cannot fix it without rewriting your app.

Inefficient abstracted programming models where two years down the road you notice, that your home-made abstraction wheels on C were not very efficient, but now all your code depends on all the nice would-be object models around it, and you cannot fix it without rewriting your app.

for something like git, where efficiency was a primary objective, the «advantages» of C++ is just a huge mistake

Если в этом предложении «С++», заменить на «C», оно станет более осмысленным.

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

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

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

Это издержки Labview, может Xlib рисует буквы получше. Хотя по мне и так красиво))))

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

Планирую сделать. Скорее всего, через функции из исходников gcc.

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

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

В письме, на которое отвечал Линус, написано:

When I first looked at Git source code

И в письме уже самого Линуса:

So I'm sorry, but for something like git, where efficiency was a primary objective, the «advantages» of C++ is just a huge mistake.

Письмо посвящено эффективности Си в прикладных программах тоже, не только в ядре. И заканчивается советом поиграть с Monotone - аналогом git, написанном на С++.

Можно ли Линукс собрать любым компилятором С?

Зачем другие компиляторы когда есть gcc?

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

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

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

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

но даже написанные людьми тексты читаете по диагонали.

Я привёл голословные обобщения от Торвальдса, они самодостаточны.

И заканчивается советом поиграть с Monotone - аналогом git, написанном на С++.

Какое это отношение имеет к аргументации за или против какого-либо языка?

Зачем другие компиляторы когда есть gcc?

T.e., переносимость С - миф?

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

Очень смахивает на фантазии второкурсника, начавшего изучать Си. Насмотрелся на таких. Почитали Торвальдса, Кнута, и думают весь мир перевернуть. Остынь. Не ты первый, кто придумал это. Лучше подумай почему у других не получилось.

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

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

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

Какое это отношение имеет к аргументации за или против какого-либо языка?

Сравнение аналогичных проектов на Си и плюсах. Я сам, кстати, не пользуюсь ни Git, ни Monotone, так как программирую в графике, а не тексте. А чем пользуетесь вы? Git или Monotone?

Зачем другие компиляторы когда есть gcc?

T.e., переносимость С - миф?

gcc с открытым кодом и компилирует почти на все известные архитектуры и платформы. Чем не переносимость?

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

https://sites.google.com/site/purebuilder/
Такое например. Я давно пытался въехать, но у меня взорвался мозг еще на подступах. Может скилла не хватило, я все же не программист. В любом случае, даже на мой не профессиональный взгляд, это смахивает на какую-то переусложненную дичь, трудную к восприятию.

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

Перечитайте главное сообщение.

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

PureBuilder за эти рамки не выходит и результат закономерный.

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

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

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

Весьма сложный проект, сотни функций и десятки типов.

окончишь школу увидишь проекты посложнее может быть

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

Я сам работаю в Labview с графическим кодом и сам Метапрог пилю пока на нем. Весьма сложный проект...

Т.е. «мне удобнее»? Но зачем тогда обобщать?

gcc с открытым кодом и компилирует почти на все известные архитектуры и платформы. Чем не переносимость?

Вот именно, и компилятор C++ входит в gcc (GNU compiler collection). C++ используется для разработки самого gcc. LLVM плотно на C++. А это тоже системщина, просто не ядерная.

Сравнение аналогичных проектов на Си и плюсах.

Где сравнение то? Для сравнения надо либо брать репрезентативную выборку, либо указывать, почему принципиально А нельзя использовать для Б.

Я сам, кстати, не пользуюсь ни Git, ни Monotone, так как программирую в графике, а не тексте.

И что с того?

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

Xlib все делает через видеокарту, верно

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

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

Вот ещё перл:

You invariably start using the «nice» library features of the language like STL and Boost

4.2. Нет никакого «invariably» в использовании STL и/или boost.

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

В один коммент (а не 370 страниц) не поместится аргументация зачем усложнять себе жизнь классами вместо типов и функций?

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

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

Почему проигнорировал мое замечание по поводу мнения Дениса Ритчи?

Может Линус и читал Страуструпа, но вряд ли он его убедил. Ядро как писалось на чистом Си, так и пишется, и даже прикладной Git Линус делал на чистом Си

ты думаешь, что от десятикратного повторения аргумента он убедительнее звучит? КАПСОМ напиши, тогда все сразу услышат

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

а не 370 страниц

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

перед тем как делать революции, неплохо бы получить образование, чтоб не выглядеть дураком

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

можно было кодить что-то типа ядра ОС. Что и является целью Метапрога.

Жги еще. Не маловато ли амбиций?

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

Владимир

Конечно у ТС планы очень большие ...
ТС планирует предоставить /в частности/ tools для автоматического перевода кода в C диаграммы - круто.

PS: «Смелость - города берет».

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

Я сам работаю в Labview с графическим кодом и сам Метапрог пилю пока на нем. Весьма сложный проект...

Т.е. «мне удобнее»? Но зачем тогда обобщать?

Да, графическое программирование именно мне удобнее всего. Более того: мне даже с LORCODE париться неудобно, постоянно переключаясь на английский для проставления тэгов, копипастить проще. Графические инструменты форматирования для слабаков?))

Где сравнение то? Для сравнения надо либо брать репрезентативную выборку, либо указывать, почему принципиально А нельзя использовать для Б.

На кой черт? Это ж не академическая статья для научного журнала? Это всего лишь частное мнение. Мнение хорошего программиста-практика.

Я сам, кстати, не пользуюсь ни Git, ни Monotone, так как программирую в графике, а не тексте.

И что с того?

Был вопрос чем ты сам пользуешься.

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

Почему проигнорировал мое замечание по поводу мнения Дениса Ритчи?

Потому что не знаком с его мнением о С++.

Поместится.

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

Для чего вообще существует концепция ООП? Для простоты? Тогда какого черта она плодит толстенные талмуды? Посмотрел соседнюю тему - ужаснулся. Что почитать по ООП? И это ПРОЩЕ и лучше?!

Причины популярности ООП расписаны тут:

http://harmful.cat-v.org/software/OO_programming/why_oo_sucks

Reason 1 - It was thought to be easy to learn.

Reason 2 - It was thought to make code reuse easier.

Reason 3 - It was hyped.

Reason 4 - It created a new software industry.

I see no evidence of 1 and 2. Reasons 3 and 4 seem to be the driving force behind the technology. If a language technology is so bad that it creates a new industry to solve problems of its own making then it must be a good idea for the guys who want to make money.

This is is the real driving force behind OOPs.

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

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

Владимир

ООП в C++ - одна из архитектур работы с объектами.
Лучше не хулить ее, а создавать новые архитектуры /конечно не из-за фанатизма/.
В разных языках программирования представлены разные виды архитектур объектов.
Тема очень емкая.
Но отрицать полезность объектов - не правильно.

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

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

https://ru.wikipedia.org/wiki/Наука_самолётопоклонников

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

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