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

и полная жопа программе, ни она, ни графический редактор не откроют испорченный бинарный конфиг

Ды даже ФС восстановить можно, а тут конфиг %)

Вроде как реестр надёжнее, но это путь винды и гнома.

Ну это путь линукса уже считай, ждем бинарных конфигов у KDE.

Поддержка многих тулкитов нужна только монстрам а-ля libre office, chromium... ТСу уже множество раз рассказывали про преимущества ООП, а он всё стоит на своём. Вот и обратная сторона «не буду жрать то, что дают». В описании каждого паттерна в википедии описано какие проблемы он решает. Чтобы ТС обратился к ООП ему нужно хорошенько попрыгать по граблям и разбить себе лоб. Чтобы нормально обучить паттернам не достаточно «вот это делается так». Нужно «решаешь такую-то задачу, а получается говнокод, а если применить такой-то паттерн вот так, то говнокод превращается в нормальный код». И ещё объективные критерии говнокода (легко ли расширять, нет ли слишком большой связанности и т.п.).

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

И да, для оценки диаграммы её должны понимать все судьи, а не только ТС. Кто знает, сколько раз ТСу писали «на твоих мазюках диаграммах ничего не понятно».

В любом случае, нужно писать wrapper, чтобы был один api для разных тулкитов. Без этой обёртки поддержка кода превратится в ад.

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

Как даже Грязный Билли говорил в своё время,

There’s only really one metric to me for future software development, which is – do you write less code to get the same thing done?

И в этом я совершенно с ним согласен. И неважно в данном контексте, идёт ли речь о количестве строк, лексем или блоков в диаграмме. Чем меньше их будет, тем лучше. Но при упрощении логической структуры о том, что нужно get the same thing done, тоже нельзя забывать. Отсюда и возникли REBOL/Red, Clojure/ClojureScript, ReactJS/React Native и прочие технологии, которые так не любят профессоры кислых Сей вроде ТС с Илюхой. Они в этом видят только пожирание вычислительных ресурсов. На то, что код при этом получается куда компактнее и выразительнее, им по барабану.

Чем меньше их будет, тем лучше

Согласен, весьма объективно. Только надо воспринимать это как ориентир, «путеводную звезду», а не как религиозную догму. Ведь в особых случаях другие приоритеты. В ядрах ОС, real-time... (не надо продолжать «меряться реалтаймами») производительность гораздо важнее короткого кода. Каждый первый охуевает когда впервые видит реализацию стандартных библиотек C и C++ - там специфичные требования к коду. Также динамическая типизация а-ля питон, js... Для мелких проектов ощутимо сокращает объём кода, но при разрастании кодовой базы «стреляет в ногу». Нужен баланс между объёмом кода и надёжностью.

А так - да, меньший объём кода для тех же задач свидетельствует о развитии инструментов. Если программа не падает от малейшего чиха.

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

IDE под хаскель имеются, но они не нужны

нужны

у хескеля нету предсказуемости

есть

а чего там настраивать, есть alsamixer.

в pavucontrol загляни

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

что это? у меня нет такого в системе.

Это обращение к элементу структуры?

node->value = 0;

Битовый сдвиг к нужному элементу структуры?

->

какой битовый сдвиг? это оператор обращения к элементу структуры на которую указывает variable node. ну как ты пишешь такую систему не зная элементарных вещей?

Чем node->value отличается от node.value?

тем что

struct Node *node;
node->value;

struct Node node;
node.value;

facepalm

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

это все уже поняли

То есть, -> это по указателю на структуру?

А можно ли вместо этого сделать так?

struct Node *node;
*(Node).value = 0;

Лабвью открыло мне возможность делать программы и при этом не писать код.

можно (*Node).value = 0;

https://en.cppreference.com/w/c/language/operator_precedence

Почему тогда так не делают и вместо этого занимаются ерундой с node->value?

так короче, не надо городить скобки

Алгоритмических различий никаких? Только лишь синтаксический сахар? И ради этого придумали целый новый оператор?

да

Каких только кракозябр не понапридумывают ради удобства программирования в тексте. Новички в ужасе, зато у «бывалых» ЧСВ от их знания аж зашкаливает.

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

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

Есть в планах. Но не переписать, а пересобрать диаграммы, переделать:)

Си при этом, возможно, все равно останется как один из вариантов бекенда. Да и мой Си ты видел. Как тут не вспомнить цитату Линуса:

It's mostly in C, but most people wouldn't call what I write C

https://groups.google.com/d/msg/comp.os.minix/dlNtH7RRrGA/ru3QgAOM-7UJ

Потому что со стрелочкой короче???

Чуть короче. Но вводит новичков в ступор. Хорошо что есть ЛОР, где можно спросить что это за хреновина, а так было бы тяжело.

Я пока ничего особенного на гтк не сделал, всего лишь пробные примеры и допилка еще лабвьюшного прототипа. Нуклеар решил пощупать, чтобы сравнить с гтк. К тому же, нуклеар с SDL2 обещает быть намного более кросплатформенным.

А мне сразу было понятно, спецом же стрелочку сделали %)

Но вводит новичков в ступор

а почему это должно волновать специалистов которые это используют?

Потому что они тоже были новичками. Но ладно, сишные-то стандарты менять уже ни к чему. Лучше заменить все графикой:)

Очень важные вопросы.

Есть область рисования диаграммы, грубо говоря - окошко. Нужна функция, которая узнает каким виджетом занята точка в нужных координатах (х, у). Есть ли это в готовом виде в нуклеаре? А в гтк? В лабвьюшном прототипе я это дело сам скрутил: выдает номер объекта диаграммы если место занято и «0» если пусто.

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

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

Нужна функция, которая узнает каким виджетом занята точка в нужных координатах (х, у). Есть ли это в готовом виде в нуклеаре? А в гтк? В лабвьюшном прототипе я это дело сам скрутил: выдает номер объекта диаграммы если место занято и «0» если пусто.

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

Плюс нужна функция, узнающая проходит ли в заданной точке линия.

Тоже лучше сам напиши.

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

В примере все есть! https://github.com/vurtun/nuklear/blob/master/demo/node_editor.c#L308

Нужна функция, которая узнает каким виджетом занята точка в нужных координатах (х, у)

Но в примере опять же есть. Просто улучши его, не пиши свое. https://github.com/vurtun/nuklear/blob/master/demo/node_editor.c#L313

Каких только кракозябр не понапридумывают ради удобства программирования в тексте.

Как раз кракозябр в твоих диаграммах побольше будет. Если б ещё документашка по ним хоть какая-нибудь была...

К счастью, Си этим вроде не сильно страдает

Так это сишная стрелочка и есть.

+1 %)

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

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

Но тут вопрос как, например, удалять эти линии?

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

Ок, а как сказать проге в целом, что линию надо удалить?

Как пользователь это будет делать?

Документировать сами концепты, а не всякие текстовые команды и параметры, разумеется.

Убери слово «текстовые» — команды и параметры никуда не денутся. У тебя есть некий набор УГО (условных графических обозначений) - фигурки всякие, разные типы линий между ними. Вот по ним должно быть описание, что конкретный УГО означает, какие типы связей к нему могут подходить, что на входе, что на выходе.

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

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

Однозначно будут вставки сишного кода там, где это будет проще.

И превратится метапрог в дракона %)

Потом заменим на диаграммы, когда руки дойдут.